MCP Server Development

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 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

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 we scope an engagement

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.

Who this is for

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.