MCP-Server-Entwicklung

Die meisten Anbieter von MCP-Entwicklung haben nie einen Server betrieben. Wir schon. Nordsynk ist unser eigener Model-Context-Protocol-Server für Fortnox — gelistet im Fortnox Marketplace, genutzt von rund achtzig schwedischen Unternehmen, pro Nutzer lizenziert und an jedem Arbeitstag im Einsatz. Alles auf dieser Seite stammt aus dem Betrieb, nicht aus der Lektüre der Spezifikation.

Dieser Unterschied wiegt schwerer, als er klingt. Einen MCP-Server zu bauen, der auf Ihrem Laptop läuft, dauert einen Nachmittag. Einen zu bauen, der echte Nutzer aushält, drei gleichzeitige Protokollversionen, ein OAuth-Token, das mitten im Gespräch abläuft, und einen Client, der Ihre Werkzeugbeschreibungen still umdeutet — das ist eine ganz andere Aufgabe.

Was in der Produktion tatsächlich bricht

Die Spezifikation sagt Ihnen, wie Sie ein Werkzeug bereitstellen. Sie sagt nichts darüber, was danach passiert — und genau daran scheitern die Projekte.

Die Protokollversionen zersplittern sofort. Unsere eigene Telemetrie zeigt derzeit vier verschiedene MCP-Revisionen gleichzeitig im aktiven Einsatz über die Kundenbasis hinweg — Clients auf 2026-07-28, andere noch auf 2025-11-25, ein Ausläufer auf 2025-06-18 und ein Integrator, der bis auf 2024-11-05 zurückhängt. Ein Server, der eine einzige Version voraussetzt, bricht für eine Nutzergruppe, die Sie nicht sehen und von der Sie nie hören.

Clients interpretieren Ihre Werkzeuge unterschiedlich. Derselbe MCP-Server verhält sich in Claude, ChatGPT, Cursor und Microsoft Copilot Studio verschieden. Wir haben einen Kompatibilitäts-Fix dafür ausgeliefert, wie strukturierte Antworten für eine Client-Familie verpackt wurden — entdeckt erst, als ein Kunde berichtete, dass sein Agent in einer Eskalationsschleife hängen blieb. So etwas findet niemand im Test. Sie finden es, wenn ein echter Nutzer verärgert ist.

Die Authentifizierung ist das ganze Spiel. Ein gehosteter MCP-Server braucht OAuth, das die Token-Erneuerung übersteht, Mandantentrennung, die niemals Daten eines Kunden in den Kontext eines anderen durchsickern lässt, und eine Lizenzierung pro Platz, die zum Modell der Plattform passt. In unserem Fall hieß das: Abgleich mit einer lebenden Nutzerliste und Verrechnung mit unserer eigenen Abrechnung bei jedem Aufruf.

Schreibzugriffe brauchen einen Menschen. In dem Moment, in dem Ihr Server Daten ändern statt nur lesen kann, ist der Fehlerfall keine Fehlermeldung mehr, sondern eine falsche Zahl, die richtig aussieht. Unser Ansatz: Jeder Schreibvorgang zeigt zuerst genau, was er ändern wird, und wartet auf eine ausdrückliche Freigabe. Kunden haben in diesem Ablauf über zweihundert solcher Entscheidungen getroffen — deshalb lässt eine Buchhaltung eine KI überhaupt an die Bücher.

Fallstudie: Nordsynk

Nordsynk verbindet die Fortnox-Buchhaltungsdaten eines Unternehmens mit Claude, ChatGPT und anderen MCP-Clients. Der Nutzer fragt in natürlicher Sprache, welche Kunden im Verzug sind, was übers Jahr an einen Lieferanten gezahlt wurde oder wo die Marge verloren geht — und der Server liest die zugrunde liegenden Rechnungen, Belege und Lieferantenrechnungen, bevor er antwortet.

Der Umfang dieses Lesens ist der eigentliche Punkt. Über die zwölf stärksten Kunden hinweg hat der Server mehr als neunzigtausend API-Aufrufe bedient, darunter über achtunddreißigtausend einzelne Rechnungsabfragen. Ein einziger Kunde erzeugte in einem Monat über zehntausend Aufrufe. Kein Mensch öffnet achtunddreißigtausend Rechnungen, um eine Frage zu beantworten — genau deshalb sind die Antworten Geld wert.

Was wir gebaut haben und was wir für Sie bauen würden: einen einzigen Code-Mode-Einstiegspunkt über die gesamte darunterliegende OpenAPI-Fläche statt einer handverlesenen Liste von zwanzig Werkzeugen, die veraltet, sobald sich die API ändert. Darüber benannte Workflows für das, was die rohe API schlecht abbildet — Freigabe und Verbuchung von Lieferantenrechnungen im Stapel, Kundenrechnungsversand, Zahlungserfassung, SIE-Export. Dazu OAuth mit Token-Verwaltung pro Unternehmen, Platzlizenzierung im Abgleich mit der Plattform, Schreibfreigaben mit Vorschau und Stapelentscheidungen sowie Nutzungstelemetrie, die detailliert genug ist, um Monate später zu beantworten, was ein bestimmter Kunde tatsächlich getan hat.

Wie wir ein Projekt zuschneiden

Wir beginnen mit einer bezahlten Scoping-Woche statt mit einem kostenlosen Angebot. Sie bekommen Ihre API-Fläche kartiert, das Werkzeugset spezifiziert, das Authentifizierungsmodell entschieden und einen Festpreis. Das kostet wenig — und sorgt dafür, dass sich keiner von uns auf eine Zahl festlegt, bevor wir die Arbeit verstanden haben.

Ein Pilot ist die richtige Wahl, wenn Sie intern etwas Funktionierendes zeigen müssen, bevor jemand das eigentliche Vorhaben finanziert. Produktion ist richtig, wenn der Server vor Kunden tritt. Marketplace-reif ist das, was Nordsynk selbst ist: ein lizenziertes, abrechenbares Produkt mit eigenem Eintrag.

Jeder Aufbau schließt laufende Wartung ein, und ohne sie verkaufen wir keinen. Das ist kein Upsell. Bei vier gleichzeitig aktiven Protokollversionen und Client-Verhalten, das sich unter Ihnen verschiebt, hört ein ungewarteter MCP-Server innerhalb von Monaten still auf zu funktionieren — und der Kunde macht den Server dafür verantwortlich, nicht den Client, der sich geändert hat.

Für wen sich das eignet

Am meisten profitieren Unternehmen, deren Kunden bereits fragen, ob sie ihre Daten in ChatGPT bekommen — SaaS-Plattformen, Marktplätze, Branchensoftware, alles mit einer API und einem Support-Postfach, das dieselbe Frage immer wieder erhält.

Ebenso Unternehmen, deren Wettbewerber begonnen haben, KI-Zugang auszuliefern, und die diese Schicht lieber selbst besitzen, als einen Kunden einen fragilen Scraper darum herum bauen zu lassen. Wir haben zwei schwedische IT-Unternehmen beobachtet, die lieber eigene MCP-Server gebaut haben, als zu warten. Das ist der Markt, der spricht.