MCP Server Development

By Assim ElHammouti, founder and lead engineer, NordbeamUpdated 2026-10-07

Most companies selling MCP development have never operated one. We have. Nordsynk is our own Model Context Protocol server for Fortnox — listed on the Fortnox Marketplace, used by around eighty Swedish companies, billed per seat, running in production every working day. Everything on this page comes from running it, not from reading the specification.

That distinction matters more than it sounds. Building an MCP server that works on your laptop takes an afternoon. Building one that survives real users, three concurrent protocol versions, an OAuth token that expires mid-conversation and a client that silently reinterprets your tool descriptions is a different job entirely.

What is an MCP server?

An MCP server is a program that exposes a system's tools, data and prompt templates to AI applications through the open Model Context Protocol. According to modelcontextprotocol.io, an AI application (the host) runs an MCP client that connects to one or more servers. Servers offer three kinds of capability: tools the model can call, resources it can read, and prompts users can invoke.

Local servers talk to the client over stdio. Remote servers use Streamable HTTP, and the specification's authorization section builds on OAuth. Nordbeam builds the remote kind, because that is what customers of a SaaS product can actually connect to.

How do you develop a production MCP server?

You develop one in five steps: map the API, specify the tools, decide the auth model, add write approval, then test against every client you intend to support.

1. Map the API. Decide which domains and operations the model should reach, and which it must not.
2. Specify the tools. Write tool names and descriptions for a model reader, not a human one, or expose the full OpenAPI surface through a single code-mode entry point.
3. Decide the auth model. Remote servers need OAuth with per-tenant tokens that survive refresh.
4. Gate writes. Every change shows what it will do and waits for a person's approval.
5. Test per client. Claude, ChatGPT, Cursor and Copilot Studio each behave differently.

Why build an MCP server at all?

You build one so customers can use your product from the AI tools they already work in, without a custom integration per assistant. One MCP server serves every compliant client. It also keeps you in control of authentication, permissions and logging, instead of a customer building a fragile scraper around your product.

What actually breaks in production

The specification tells you how to expose a tool. It does not tell you what happens next, and what happens next is where projects fail.

Protocol versions fragment immediately. Our own telemetry currently shows four different MCP protocol revisions in active use across our customer base at the same time — clients on 2026-07-28, others still on 2025-11-25, a long tail on 2025-06-18, and one integrator pinned all the way back to 2024-11-05. A server that assumes a single version breaks for a segment of users you cannot see and will not hear from.

Clients interpret your tools differently. The same MCP server behaves differently in Claude, ChatGPT, Cursor and Microsoft Copilot Studio. We have shipped a compatibility fix for how structured responses were packaged for one client family, discovered only because a customer told us their agent kept falling into an escalation loop. Nobody finds this in testing. You find it when a real user is annoyed.

Auth is the whole game. A hosted MCP server needs OAuth that survives token refresh, multi-tenancy that never leaks one customer's data into another's context, and seat enforcement that matches whatever licensing model the upstream platform uses. In our case that meant syncing against a live user roster and reconciling it with our own billing on every call.

Writes need a human. The moment your server can change data rather than read it, the failure mode stops being an error message and becomes a wrong number that looks correct. Our approach is to make every write show exactly what it will change and wait for explicit approval. Customers have made over two hundred approval decisions through that flow; it is the reason a finance team lets an AI near the books at all.

Case study: Nordsynk

Nordbeam built and operates Nordsynk, a hosted Fortnox MCP server and finance-operations platform (read the full case study). Nordsynk connects a company's Fortnox accounting data to Claude, ChatGPT and other MCP clients. A user asks in plain language which customers are late, what was paid to a supplier over the year, or where margin is leaking, and the server reads the underlying invoices, vouchers and supplier invoices before answering.

The scale of that reading is the point. Across the twelve heaviest customers, the server has served over ninety thousand API calls, including more than thirty-eight thousand individual invoice lookups. One customer alone generated over ten thousand calls in a single month. No human opens thirty-eight thousand invoices to answer a question — which is precisely why the answers are worth paying for.

What we built, and what we would build for you:

A single code-mode entry point over the full upstream OpenAPI surface, rather than a hand-curated list of twenty tools that goes stale the moment the API changes. On top of that, named workflows for the operations the raw API models badly — bulk supplier-invoice approval and bookkeeping, customer invoice dispatch, payment registration, SIE export. Then OAuth with per-company token handling, seat licensing synced to the upstream platform, write approvals with previews and batch decisions, and usage telemetry detailed enough to answer "what did this customer actually do" months later.

How long and how much does an MCP server take?

A pilot takes two to three weeks, a production server six to eight, and a marketplace-ready product ten to twelve. Nordbeam starts with a paid scoping week and gives a fixed quote afterwards.

We start with a paid scoping week rather than a free proposal. You get your API surface mapped, the tool set specified, the auth model decided and a fixed quote. It costs little, and it means neither of us commits to a number before we understand the work.

A pilot is the right choice when you need something working to show internally before anyone will fund the real thing. Production is the right choice when the server is going in front of customers. Marketplace-ready is what Nordsynk itself is: a licensed, billable product with its own listing.

Every build includes ongoing maintenance, and we do not sell one without it. That is not an upsell. With four protocol versions live simultaneously and client behaviour shifting underneath you, an unmaintained MCP server quietly stops working within months — and the customer blames the server, not the client that changed.

• TypeScript·
• Model Context Protocol·
• OAuth 2.1·
• Cloudflare Workers·
• OpenAPI·
• Claude·
• ChatGPT·
• Copilot Studio

Who needs an MCP server?

The companies that get the most from an MCP server are those whose customers already ask "can I get this data into ChatGPT?" — SaaS platforms, marketplaces, vertical software, anything with an API and a support inbox that keeps receiving the same question.

It is also for companies whose competitors have started shipping AI access and who would rather own that layer than have a customer build a fragile scraper around it. We have watched two Swedish IT companies build their own MCP servers rather than wait. That is the market speaking.