Der eigene MCP-Server: Warum Software jetzt ansprechbar werden muss

Eine Geschäftsführerin fragt ihren KI-Assistenten, wie viele Anmeldungen für die Jahrestagung eingegangen sind und ob der Keynote-Referent sein Honorarformular schon eingereicht hat. Der Assistent, der eben noch souverän einen Fördermittelbescheid zusammengefasst und drei Terminvorschläge formuliert hat, muss passen. Die Antwort steht in der Kongressverwaltung des Verbands, hinter einem Login, in einer Oberfläche, die für Menschen mit Maus und Browser gebaut wurde. Für den Assistenten ist diese Software so unerreichbar wie ein Buch hinter Glas.

Das ist der Normalzustand der meisten Fachsoftware im Jahr 2026, und er wird gerade zum Wettbewerbsnachteil. Denn auf der anderen Seite dieser Glasscheibe hat sich in bemerkenswertem Tempo ein Standard etabliert, der genau diese Verbindung herstellt: das Model Context Protocol, kurz MCP. Die Frage ist nicht mehr, welche KI-Werkzeuge Sie nutzen, sondern ob Ihre eigene Software von KI-Agenten genutzt werden kann.

Wie MCP funktioniert, warum sich ein MCP-Server gegenüber dem Agenten selbst beschreibt und worin er sich von einer klassischen API unterscheidet, haben wir in unserem Artikel zur Agententopologie ausführlich dargelegt; das wiederholen wir hier nicht. Interessanter ist, was seit der Veröffentlichung durch Anthropic im November 2024 geschehen ist, denn es folgt einem Muster, das man aus der Geschichte der Netzwerkstandards kennt: Die Konkurrenz übernahm das Protokoll. OpenAI baute MCP-Unterstützung in seine Produkte ein, Google und Microsoft folgten (1). Konkurrenten adoptieren fremde Protokolle nicht aus Höflichkeit; sie tun es, wenn der Netzwerkeffekt bereits zu groß ist, um dagegen anzubauen.

Im Dezember 2025 übergab Anthropic das Protokoll schließlich an die Agentic AI Foundation unter dem Dach der Linux Foundation, mitgetragen von OpenAI, Block, AWS, Google, Microsoft und anderen. Damit gehört MCP niemandem mehr, so wie HTTP niemandem gehört. Die Zahlen zeichnen die Kurve einer Basistechnologie: Die offiziellen Entwicklungspakete wurden im März 2026 rund 97 Millionen Mal pro Monat heruntergeladen, gegenüber etwa zwei Millionen beim Start; die öffentliche Registry zählt knapp zehntausend Server, interne Installationen konservativ auf das Drei- bis Vierfache geschätzt (2). Zum Vergleich: React, das Fundament des halben modernen Webs, brauchte für vergleichbare Downloadzahlen etwa drei Jahre.

Rohe Zahlen kann man ignorieren, das Verhalten etablierter Anbieter schwerer. In den öffentlichen Verzeichnissen lassen sich zwei Lager unterscheiden (3). Das erste besteht aus Werkzeugen, die von vornherein für Agenten gebaut wurden; dass sie MCP anbieten, ist ihr Geschäftsmodell und insofern wenig aussagekräftig. Das zweite Lager ist das interessante: etablierte Softwareanbieter, die einen offiziellen MCP-Server nachgerüstet haben, damit Agenten in ihren Produkten arbeiten können. Notion, Atlassian, Linear, Stripe, HubSpot, Figma, Shopify und Salesforce gehören dazu; WordPress, das Content-Management-System hinter rund vier von zehn Websites, hat im Februar 2026 einen offiziellen MCP-Adapter veröffentlicht (4). Wenn Plattformen dieser Größenordnung eine Schnittstelle nachrüsten, ist sie kein Experiment mehr. Sie ist Erwartung geworden.

Aufschlussreich ist dabei die Bauform. MCP-Server liefen anfangs überwiegend lokal, als Prozess auf dem Rechner des Nutzers, was für Entwickler praktikabel ist und für alle anderen eine Zumutung. Die Anbieter sind deshalb dazu übergegangen, ihre Server als Dienst im Netz zu betreiben: erreichbar über HTTPS, abgesichert über OAuth, zentral gewartet wie jede andere Webanwendung. Diese Remote-Server haben sich seit Mai 2025 nahezu vervierfacht, und von den zwanzig meistgesuchten MCP-Servern bieten vier von fünf ein solches Deployment an (5). Das ist die Bauform, die für Softwareanbieter zählt, denn sie bedeutet: Der Kunde installiert nichts. Er verbindet seinen Assistenten mit Ihrer Software, so wie er heute eine App mit seinem Kalender verbindet.

Nun betreiben die wenigsten Verbände und Mittelständler eine Software von der Reichweite Notions. Aber gerade Fachsoftware, also Mitgliederverwaltungen, Kongress- und Seminarplattformen, Gutachtenportale, interne Fallverwaltungen, ist der Ort, an dem eine MCP-Schnittstelle den größten Unterschied macht. Denn dort liegen die Antworten auf genau die Fragen, die Menschen ihren Assistenten ohnedies schon stellen.

Kehren wir zur Szene vom Anfang zurück, diesmal mit Schnittstelle. Wie viel organisatorische Prüfung in einem scheinbar simplen Verbandsvorgang steckt, hat der Agententopologie-Artikel am verwandten Beispiel der Teilnahmebescheinigung gezeigt; hier geht es um die Stufe davor: ob der Agent das System überhaupt erreicht. Die Kongressplattform bietet einen MCP-Server an, der eine Handvoll klar definierter Werkzeuge exponiert: Anmeldestand abfragen, Referentenstatus prüfen, Raumbelegung lesen. Die Geschäftsführerin verbindet ihren Assistenten einmalig, autorisiert den Zugriff über den vertrauten Anmeldedialog, und von da an beantwortet der Assistent die Frage nach den Anmeldezahlen selbst: Er ruft das Werkzeug auf, erhält strukturierte Daten und formuliert die Antwort. Kein Export, kein Copy-and-paste, kein zweites Browserfenster. Die Software ist von einem Ort, den man aufsuchen muss, zu einem Gesprächspartner geworden, den man fragen kann.

Bemerkenswert an dieser Architektur ist ihre Genügsamkeit. Ein MCP-Server muss nicht die gesamte Anwendung spiegeln; er exponiert eine kuratierte Auswahl von Fähigkeiten, und genau darin liegt die eigentliche Entwurfsarbeit. Lesende Zugriffe sind der natürliche Anfang, schreibende verlangen mehr Sorgfalt. Die Governance-Fragen dahinter, also wer was darf, wann ein Mensch entscheiden muss und wer die Verantwortung trägt, wenn ein automatisiertes System falsch liegt, haben wir im Agententopologie-Artikel entfaltet; sie gelten für den eigenen Server unverändert.

Wie entsteht ein solcher Server? Ernüchternd unspektakulär, und das ist als Kompliment gemeint. Die offiziellen SDKs, allen voran TypeScript und Python, reduzieren das Protokoll auf wenige Handgriffe (6). Ein Werkzeug ist eine Funktion mit drei Zutaten: einem Namen, einem typisierten Eingabeschema und einer Beschreibung in natürlicher Sprache. Für die Kongressplattform aus unserer Szene sieht das erste Werkzeug so aus:

Das Bemerkenswerte an diesen Zeilen ist die description. Sie ist kein Kommentar für Kollegen, sie ist die Schnittstelle selbst: Der Agent liest diesen Satz, um zu entscheiden, ob und wie er das Werkzeug einsetzt. Wer unklare Beschreibungen schreibt, bekommt einen Agenten, der raten muss. Das Formulieren dieser Sätze ist Interface-Design mit sprachlichen Mitteln, näher an guter Microcopy als an API-Dokumentation. Auch der Zuschnitt folgt dieser Logik: Drei klar benannte Werkzeuge führen zu besseren Ergebnissen als ein Universalwerkzeug mit zwanzig Parametern, weil das Sprachmodell über kleine, präzise beschriebene Einheiten verlässlicher urteilt (7).

Der zweite Baustein ist der Transport. Für den Betrieb im Netz sieht der Standard Streamable HTTP vor: einen einzelnen Endpunkt, üblicherweise /mcp, über den Client und Server JSON-RPC-Nachrichten austauschen. Der pragmatische Rat aus der Praxis lautet, zustandslos zu beginnen. Sitzungsverwaltung ist der Teil, der im Produktivbetrieb am ehesten bricht, und die meisten Server brauchen sie nie. Drittens die Autorisierung: Der Standard schreibt für Remote-Server OAuth 2.1 vor. Der Nutzer durchläuft einmalig den Freigabedialog, der Server prüft fortan bei jedem Aufruf das mitgelieferte Token samt Berechtigungen. Und viertens der Betrieb, der angenehm unglamourös ausfällt: Ein MCP-Server ist eine Webanwendung. Reverse Proxy, TLS, Ratenbegrenzung, Logging, dieselben Routinen, die jede Agentur beherrscht. Wer WordPress-Instanzen und Fachplattformen betreibt, betreibt auch das.

Wer das Codebeispiel aufmerksam liest, stellt die richtige Frage: Was hindert einen Agenten daran, fremde Veranstaltungs-IDs durchzuprobieren? Die ehrliche Antwort lautet: nichts, und genau so muss man planen. Ein Agent ist ein Client wie jeder andere, nur gesprächiger. Seine Werkzeugauswahl ist keine Sicherheitsschicht, und eine Beschreibung wie „bitte nur eigene Veranstaltungen abfragen" wäre eine Bitte, kein Schutz. Die Vertrauensgrenze verläuft hinter dem Agenten: im Handler, auf dem Server, bei jedem einzelnen Aufruf.

Deshalb taucht im Beispiel das authInfo-Objekt auf. Die Identität des Nutzers und seines Mandanten kommt aus dem geprüften OAuth-Token, niemals aus den Parametern des Werkzeugs; die event_id ist eine Angabe des Agenten und damit so vertrauenswürdig wie jede Nutzereingabe in einem Webformular, nämlich gar nicht. Der Handler prüft bei jedem Aufruf, ob das Token die angefragte Veranstaltung sehen darf, und lässt den Zugriff andernfalls scheitern. Dazu kommen die Routinen, die für jede Schnittstelle gelten: Eingaben streng validieren (das Zod-Schema prüft Typen, keine Rechte), Werkzeuge nach dem Prinzip der minimalen Rechte zuschneiden, lesende Zugriffe vor schreibenden freigeben, Ratenbegrenzung gegen durchprobierende Clients. Eine Eigenheit kommt hinzu, die klassische APIs nicht kennen: Alles, was ein Werkzeug zurückgibt, landet im Kontext des Sprachmodells und kann dort weiterwirken. Ein Server sollte deshalb nur die Felder liefern, die zur Beantwortung nötig sind, keine Rohdatensätze mit Spalten, nach denen niemand gefragt hat. Datenminimierung ist hier kein Compliance-Reflex. Sie ist Architektur.

Bleibt eine Frage, die das Bild vervollständigt: Woher weiß ein Agent überhaupt, dass Ihre Software eine solche Schnittstelle anbietet? Heute meist vom Menschen. Der Nutzer trägt die Server-URL in seinem Client ein oder wählt den Anbieter aus dem Connector-Katalog von Claude, ChatGPT und Co., so wie man früher ein Lesezeichen setzte. Für die automatische Entdeckung entsteht die Infrastruktur gerade erst: Seit September 2025 gibt es die offizielle MCP Registry, ein maschinenlesbares Verzeichnis, in dem Anbieter ihren Server einmal publizieren und aus dem Clients und Kataloge dieselben kanonischen Daten beziehen (8). Parallel wird an dezentraler Entdeckung nach dem Vorbild von sitemap.xml und robots.txt gearbeitet: Vorschläge in der Spezifikationsdiskussion und ein IETF-Entwurf sehen vor, dass eine Domain unter einem well-known-Pfad ein Manifest hinterlegt, das Endpunkt, Fähigkeiten und Authentifizierungsanforderungen beschreibt (9). Verbindlich ist davon noch nichts. Aber die Bewegung ist dieselbe, die wir aus der Inhaltswelt kennen und in unserem GEO-Artikel beschrieben haben: Erst wurden Texte für Maschinen lesbar gemacht, jetzt werden Werkzeuge für Agenten auffindbar. Wer heute einen Server baut, trägt ihn morgen in ein Verzeichnis ein.

Zur ehrlichen Beratung gehört, was noch fehlt. Die Autorisierung ist inzwischen solide spezifiziert und hat sich über mehrere Revisionen des Standards deutlich verbessert. Andere Fragen löst das Protokoll bislang nicht: Mandantentrennung, also die saubere Isolation der Daten verschiedener Kunden innerhalb eines Servers, muss der Anbieter selbst konstruieren, ebenso Entscheidungsprotokolle und Kostenzuordnung. Wer einen MCP-Server für eine mandantenfähige Plattform baut, baut diese Schutzschichten mit, und sie sind der aufwendigere Teil des Vorhabens; die vier Bausteine oben sind das Gerüst, nicht das Haus. Die Ernüchterung gehört ins Bild: Nach einer Erhebung unter Softwareunternehmen betreiben bislang gut vier von zehn befragten Organisationen MCP-Server produktiv (10). Das ist viel für ein Protokoll dieses Alters und zugleich weit entfernt von Flächendeckung.

Daraus folgt keine Pflicht zur Eile, wohl aber eine zur Einordnung. Nicht jede Anwendung braucht im nächsten Quartal einen MCP-Server. Aber jede Roadmap für eine Software, die in fünf Jahren noch relevant sein will, braucht eine Antwort auf die Frage, wie Agenten mit ihr arbeiten sollen. Gartner erwartet, dass bis Ende 2026 vier von zehn Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten. Diese Agenten werden mit der Software arbeiten, die sie ansprechen können, und um die andere einen Bogen machen.

Für unsere eigene Plattform atomic ziehen wir daraus eine naheliegende Konsequenz: Systeme, in denen die Arbeitsdaten von Verbänden und Fachgesellschaften liegen, vom Kongressmanagement bis zur Mitgliederverwaltung, gehören zu den ersten, die eine solche Schnittstelle verdienen. Der Wert einer Fachanwendung bemisst sich zunehmend daran, wie gut ihre Daten dort ankommen, wo gearbeitet wird. Und gearbeitet wird immer öfter im Gespräch mit einem Agenten.

Die Website machte Ihr Unternehmen auffindbar.
Die MCP-Schnittstelle macht Ihre Software ansprechbar.