MCP-Server werden zu Funktionsplattformen und nicht mehr zu Tool-Wrappern.
MCP-Server entwickeln sich zu Funktionsplattformen: Werkzeugumwandlung, Suchfunktionen, Namensräume, Proxys, Fähigkeiten, Aufgaben und Versionsverwaltung – sowie Hinweise darauf, wann man abwarten sollte.
Quellen: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Jeder, der bereits einen MCP-Server in die Produktion gebracht hat, kennt inzwischen die Checkliste: explizite Tool-Verträge, strukturierte Eingaben und Ausgaben, sinnvolle Fehlersemantik, Authentifizierung, Überwachbarkeit, eine klare Trennung zwischen dem, was das Modell steuert, und dem, was die Laufzeit bereitstellt (Benutzer-ID, Tenant, Rollen und Berechtigungenskonzepte), Autorisierung zum Zeitpunkt der Ausführung sowie ein skalierbares Deployment-Modell. Der nächste Schritt besteht nicht darin, einen neuen Transportmechanismus oder ein weiteres Agent-Framework einzuführen – und es gibt auch keinen Grund, die gesamte Technologiebasis umzuschreiben. Vielmehr ähnelt ein MCP-Server zunehmend einer echten Anwendungsplattform für Funktionen statt einem einfachen Endpunkt mit ein paar zusätzlich angehängten Tools.
Der Unterschied wird wichtig, sobald man Dutzende von Tools, mehrere MCP-Server, mehrere Teams, Benutzer mit unterschiedlichen Berechtigungen, verschiedene Clients, langlaufende Workflows, wiederverwendbare Fähigkeiten, Versionen sowie eine immer größer werdende Menge an Kontext hat. Zu diesem Zeitpunkt geht es nicht mehr darum, wie man eine Python-Funktion als Tool bereitstellt – es wird zu einer weitaus größeren Frage:
Wie gestaltet, entdeckt, kombiniert, steuert, ausführt, überwacht, testet und weiterentwickelt man eine ganze Funktionslandschaft, ohne alles auf das Modell zu laden?
Dies ist die Richtung, in die MCP entwickelt wird, und der Rest dieses Artikels geht darauf ein.
Der erste MCP-Server und der heutige MCP-Server sind völlig unterschiedlich
Die frühen MCP-Beispiele waren absichtlich klein – ein Server enthielt nur wenige Tools:
MCP server
├── search_documents
├── create_ticket
└── get_customer
Der Kunde listete die Tools auf, das Modell las die Schemata und wählte eines aus, und der Server führte es aus. Für eine kleine Einrichtung ist dieses mentale Modell immer noch richtig. Bei fünf klar definierten Tools, einem Backend, einem Team und einem Anwendungsfall ist nichts Komplexeres erforderlich.
Nun setzen Sie dasselbe Design in ein echtes Unternehmen um:
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
Das ist nicht mehr ein Tool-Server. Es handelt sich um ein Fähigkeitsökosystem. Wenn man einfach jedes Schema zusammenfügt und alles dem Modell zur Verfügung stellt, treten drei Probleme auf: Der Kontext wird bereits vor Beginn der Aufgabe zerstört, die Auswahl der Tools wird schwieriger, und das Modell sieht Fähigkeiten, die für diesen Benutzer und diesen Workflow möglicherweise irrelevant, riskant oder verwirrend sind.
Der Druck ist aus den Diskussionen zu Sicherheit und Erkundung bekannt, doch er hat eine weitreichendere Konsequenz, die leicht übersehen wird: Das Tool-Katalog ist an sich ein ingenieurtechnisches Artefakt. Man kann darin suchen, es transformieren, filtern und ihm einen Namensraum zuweisen. Er kann aus den Angeboten anderer Server erstellt werden und enthält wiederverwendbare Fähigkeiten sowie Ressourcen. Einige Operationen können pausiert werden, um den Benutzer eine Frage zu stellen, lange Aufgaben können in Hintergrundaufgaben verschoben werden, Verträge können versioniert werden, und die gesamte Oberfläche kann wie jede Produktions-API getestet werden.
Diese Entwicklung wird in den folgenden Abschnitten behandelt.
FastMCP ist eine gute Umsetzung der Idee – nicht die Idee selbst
FastMCP kommt in allen Beispielen vor, weil seine aktuelle Architektur diese Muster besonders deutlich macht. Anbieter liefern Komponenten. Transformationen formen die Oberfläche der Komponenten, bevor ein Client sie sieht. Suchfunktionen können einen riesigen Katalog durch eine kleine Entdeckungsinterface ersetzen. Proxy-Server können andere MCP-Server zusammenführen. Fähigkeiten können zu Ressourcen werden. Langsame Operationen können zu Hintergrundaufgaben werden. Versionen können nebeneinander existieren. Die entstehende MCP-Oberfläche kann außerdem über einen echten Client getestet werden, anstatt die Implementierungsfunktionen direkt aufzurufen.
Das ist nützlich, aber die Botschaft lautet nicht „jeder sollte FastMCP übernehmen“. Es handelt sich dabei um wiederverwendbare Architekturmuster für MCP-Systeme. Die gleichen Konzepte können in Python, TypeScript, Go, C#, Java, Rust oder einer internen Plattform, mit einem anderen Framework, mit handgeschriebenen Komponenten oder mit einem verwalteten Gateway umgesetzt werden. Entscheidend ist, zu erkennen, wohin die Abstraktion abdriftet. Das Protokoll standardisiert, wie Clients mit Funktionen kommunizieren, während Ihre Serverarchitektur bestimmt, wie die Funktionsoberfläche aussieht – und diese Oberfläche kann heute weitaus intelligenter sein als eine statische Liste von dekorierten Funktionen.
1. Umwandlung von Tools: Eine Backend-API sollte nicht automatisch zur Agent-API werden
Eine der praktischsten Ideen hier ist zugleich eine der einfachsten. Ein von einem upstream-Dienst bereitgestelltes Tool kann technisch korrekt sein und dennoch für einen LLM katastrophal sein.
Stellen Sie sich eine interne Salesforce-Integration vor, die diese Funktion bietet:
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
Innerhalb des Dienstes, der es besitzt, mag diese Signatur in Ordnung sein. Soll das Modell genau diesen Vertrag sehen? Wahrscheinlich nicht. Die für das Modell vorgesehene Version würde besser so aussehen:
find_customer_account(
company_name,
include_archived=False,
)
Die zugrunde liegende Operation blieb unverändert. Was sich ändert, ist die dem Modell präsentierte Schnittstelle – das ist die Tool-Transformation.
FastMCP bietet dies über eine spezielle Transformationsschicht an: Umbenennen eines Tools, Überarbeiten seiner Beschreibung, Umbenennen von Argumenten, Ändern der Standardwerte, Verbergen nicht benötigter Argumente, Anpassen von Tags und Anmerkungen sowie Einbettung der Ausführung in benutzerdefinierte Logik. Im Großen und Ganzen verläuft der Ablauf wie folgt:
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
Mehrere Gründe machen dies lohnenswert.
Ein Modell benötigt keine Informationen zu Infrastrukturdetails. Felder wie tenant_uuid, internal_region, api_version oder include_deleted_internal_records gehören zum Aufgabenbereich des Backends. Wenn das Modell keine Wertentscheidung treffen soll, sollte dieser Wert ganz aus seinem Schema entfernt werden. Dies entspricht der Regel des Laufzeitkontexts: Vertrauenswürdige Werte bleiben außerhalb der Funktionsgrenzen und kommen niemals in von Modellen generierten Argumenten vor.
Zweitens können die Namenskonventionen des upstream-Systems völlig unberücksichtigt bleiben. Ein Hersteller oder ein veralteter Dienst kann Operationen bereitstellen, die für menschliche Entwickler konzipiert sind, was für ein LLM, das zwischen 80 Tools wählen muss, kaum geeignet ist. Die Gateway-Plattform kann ein übersichtlicheres Vokabular anbieten, ohne dass das upstream-Team seine API umbenennen muss.
Drittens kann der Agentvertrag stabil bleiben, während sich der Backend-Teil ändert. Das ist wichtiger, als es auf den ersten Blick erscheint. Wenn sich der Backend auf eine neue Salesforce-API-Version verschiebt, einen internen Parameter umbenennt oder eine Operation in mehrere aufteilt, muss das Tool, das vom Modell verwendet wird, überhaupt nicht geändert werden. Die Transformationsschicht fungiert als Schutzschicht zwischen demjenigen, der die Funktionalität nutzt, und demjenigen, der sie implementiert. Es handelt sich dabei um herkömmliche Softwarearchitektur, die lediglich auf agentbasierte Schnittstellen angewandt wird.
Der Vertrag des Backends dient dem System, das die Funktionalität besitzt. Was die MCP-Schicht bereitstellt, sollte dem Agent dienen, der sie aufruft.
2. Tool-Suche: Der Katalog wird zu einem suchbaren Kontext
Dieser Punkt wird wichtig, sobald sich das Ökosystem entwickelt. Eine typische erste Umsetzung sieht so aus:
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
Das funktioniert, solange die Liste kurz ist, wird aber mit jedem hinzugefügten Tool verschwenderischer. Der ausgereiftere Ansatz sieht so aus:
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
Die Tool-Suche von FastMCP macht diese Idee konkret. Anstatt den vollständigen Katalog zurückzugeben, stellt der Server synthetische Entdeckungstools wie search_tools und call_tool zur Verfügung. Die derzeit integrierten Strategien sind die Regex-Übereinstimmung sowie die BM25-Rangliste. BM25 ist eine lexikalische Rangliste, keine semantische Vektorsuche, doch die Architektur hängt nicht von BM25 ab. Auf Ihrer eigenen Plattform könnte die Rangliste von Schlüsselwörtern, Embeddings, einem hybriden Suchmechanismus mit erneuter Rangfolgebestimmung, Metadatenfiltern, Nutzungstatistiken, policiesensibler Bewertung oder einem Index stammen, der speziell für die Fähigkeiten Ihres Bereichs erstellt wurde.
Der entscheidende Punkt ist, dass Tools zu auffindbaren Objekten werden. Anstatt 300 Tool-Definitionen in den Kontext aufzunehmen, könnte das Modell search_tools("find customer opportunities and open deals") aufrufen und beispielsweise drei oder vier Ergebnisse erhalten, wie salesforce_find_account, salesforce_list_opportunities und salesforce_get_pipeline_summary. Nur diese Schemata gelangen in den nächsten Schritt.
Das ist mehr als nur eine Ersparnis an Tokens. Es verbessert die Entscheidungsgrundlage für das Modell. „Eine Fähigkeit aus 300 Schemata auswählen“ und „nach Fähigkeiten suchen, die mit dieser Aufgabe zusammenhängen, und anschließend aus den vier relevanten Ergebnissen wählen“ sind völlig unterschiedliche Denkaufgaben.
Progressive Entdeckung bildet auch die Grundlage für Ansätze zur Ausführung von Code, doch die Suche nach Tools ist nützlich, selbst wenn man den vom Modell erstellten Code niemals ausführt – und sie funktioniert bei ganz gewöhnlichen Toolaufrufen. Eine Sicherheitsregel muss aus der Autorisierungsarbeit übernommen werden: Man sollte im Katalog suchen, den der Benutzer entdecken darf, und nicht im vollständigen Katalog der Plattform. Wenn die Suche die Namen und Schemata von verbotenen Admin-Tools anzeigt, sind bereits Details zu den Berechtigungen durchgesickert, selbst wenn die Ausführung später abgelehnt wird. Der eigentliche Ablauf benötigt daher einen Autorisierungsfilter vor der Suche.
Betrachten Sie dies als Kontextengineering, das auf Berechtigungen angewandt wird.
3. Namespaces: Die Komposition führt zunächst zu einem Identitätsproblem, bevor ein Skalierungsproblem entsteht
Sobald man MCP-Server zusammenführt, taucht sofort ein äußerst lästiges Problem auf: Jeder Server verfügt über generische Namen wie search, get_user, list_files oder create_note. Wenn man einen Salesforce-Server, einen Google Drive-Server, einen Wissensdatenbank-Server und einen GitHub-Server zusammenführt, wobei drei von ihnen search anbieten, häufen sich die Fragen. Welchen search ruft das Modell auf? Welcher erscheint in den Protokollen? Welcher wird von einer Richtlinienregel abgedeckt? Welcher änderte sich, als sich das Schema-Identifikat verschob?
Deshalb sind Namespaces wichtig, sobald MCP nicht mehr als einzelner, isolierter Server fungiert. FastMCP bietet eine Namespace-Transformation, die Komponenten während der Kombination mit Präfixen versehen, sodass search zu salesforce_search, gdrive_search, knowledge_base_search und github_search wird. Auch die URIs von Ressourcen können in ihrem Pfad mit Namespaces versehen werden.
Das Vermeiden von Kollisionen ist der offensichtliche Vorteil. Die Herkunft der Funktionen ist ein subtilerer Vorteil: Ein Präfix dokumentiert den Ursprung einer Fähigkeit, und dieser Ursprung fließt in Richtlinienregeln, Audit-Spuren, Trace-Informationen, Geschwindigkeitsbeschränkungen, Eigentumsverhältnisse, Migrationsprozesse, Debugging-Verfahren sowie in die Beschreibungen ein, die vom Modell gelesen werden.
Übertreiben Sie es jedoch nicht. Ein Name wie enterprise_internal_platform_team_alpha_salesforce_v2_search_customer ist nicht automatisch besser, nur weil er weltweit einzigartig ist. Ein Namespace definiert die Identität, und Transformationen können die endgültige Schnittstelle dennoch für das Modell benutzerfreundlich gestalten. Es handelt sich um zwei miteinander verbundene, aber unterschiedliche Probleme:
Source identity
→ Namespace
Agent usability
→ Transformation
4. Sichtbarkeit: Context Engineering betrifft nicht nur Text
Wenn von Context Engineering die Rede ist, denken die meisten Menschen an Systemanweisungen, abgerufte Dokumente, das Gedächtnis, das Chat-Verlauf sowie möglicherweise Toolbeschreibungen. Doch alle Fähigkeiten, die das Modell wahrnehmen kann, gehören ebenfalls zu seinem Kontext.
Nehmen wir einen Kundenforschungs-Arbeitsablauf. Was würde das Modell mit Tools wie rotate_api_key, terminate_employee, rebuild_search_index, publish_release und admin_delete_tenant anfangen – selbst wenn der Benutzer nur Rechte zu einigen davon hat? Nichts davon dient der Aufgabe. Eine übersichtlichere Struktur könnte aussehen wie folgt:
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
Die Laufzeit-Sichtbarkeit kümmert sich darum. Die Komponentensichtbarkeit von FastMCP ermöglicht es Ihnen, Komponenten über Namen, Schlüssel oder Tags einzuschalten oder auszuschalten; eine deaktivierte Komponente verschwindet aus den Listen und kann nicht über die reguläre Serveroberfläche abgerufen werden. Workflow-spezifische Funktionssets, Feature-Flags, Unterschiede zwischen Umgebungen, Beta-Tools, Wartungsfenster, tenant-spezifische Produkte, Agentenprofile oder einfach ein eingeschränkterer Handlungsspielraum für das Modell nutzen alle denselben Mechanismus:
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
Der Unterschied zur Sicherheitsarbeit bleibt bestehen: Sichtbarkeit ersetzt keine Autorisierung. Sichtbarkeit beantwortet die Frage, ob eine Fähigkeit auf der aktuellen Oberfläche vorhanden sein sollte. Autorisierung beantwortet die Frage, ob dem authentifizierten Benutzer tatsächlich die Nutzung gestattet ist. Eine gute Unternehmens-MCP-Plattform benötigt in der Regel beides – zunächst die Reduzierung der Oberfläche und anschließend die Durchsetzung der Autorisierung.
5. MCP-Proxy: Ein Server als Gateway zu anderen
Jetzt wird das Design wirklich interessant. Ein Server muss nicht über jede Fähigkeit verfügen, die er anbietet; er kann vor anderen MCP-Servern stehen. Der Proxy-Provider von FastMCP holt Tools, Ressourcen und Anfragen von einem entfernten MCP-Server ab und veröffentlicht sie erneut vom aktuellen Server aus.
Es entsteht also eine einfache Kette wie diese:
AI client
↓
Salesforce MCP
Es kann zu einem Gateway heranwachsen, das mehrere upstream-Server verbindet, und dieses Gateway muss keine Geschäftslogik von ihnen kopieren. Es leitet die Funktionen weiter und umhüllt sie mit einer Plattformschicht: Authentifizierung, Richtlinien, Benennung, Sichtbarkeit und Überwachbarkeit.
Das bedeutet eine große Veränderung in der Systemgestaltung: MCP-Server sind nicht mehr isolierte Einheiten, sondern können ein Netzwerk bilden. Ein Team kann für die Salesforce-Integration zuständig sein, ein anderes für das Projektwissen und ein weiteres für die Infrastrukturverwaltung, während das Unternehmensgateway alles zu einer einheitlichen Produktoberfläche zusammenfasst, ohne die Teams in einen gemeinsamen Repository oder Release-Zyklus zwingen zu müssen.
Proxys bringen auch auf weniger spektakuläre Weise Vorteile: Sie verbinden verschiedene Transportwege, bieten eine konstante Endpunkt-Adresse vor den ständig wechselnden Upstream-Servern, zentralisieren die Authentifizierung, verbessern die Überwachbarkeit, wenden einheitliche Richtlinien an, ordnen Namen und halten die interne Topologie vor den Clients verborgen.
Das bedeutet keineswegs, dass jedes Unternehmen ein riesiges zentrales Gateway benötigt. Man kann mehrere davon betreiben, je nach Bereich aufgeteilt: Engineering, Vertrieb, Forschung, Plattformbetrieb. MCP stellt die Protokollgrenzen bereit, die es ermöglichen, diese sauber miteinander zu kombinieren.
Sobald MCP-Server in der Lage sind, voneinander Daten zu verarbeiten und umzuformen, ist die natürliche Design-Einheit nicht mehr ein einzelner Server – sondern ein Graph aus gesteuerten Funktionalitäten.
6. Fähigkeiten als MCP-Ressourcen: Ein Server kann Know-how verteilen, nicht nur Aktionen
Tools beantworten die Frage, was das System leisten kann. Ressourcen beantworten die Frage, welche Informationen ein Kunde abrufen kann. Fähigkeiten stellen eine dritte Frage: Wie sollte ein Agent eine bestimmte Art von Aufgabe ausführen?
Eine Fähigkeit befindet sich in der Regel in einem Verzeichnis: Anweisungen zusammen mit unterstützendem Material wie Beispielen, Schemata, Skripten, Checklisten, Referenzen oder branchenspezifischen Richtlinien. Solche Verzeichnisse befanden sich traditionell innerhalb der Umgebung eines Kunden, an Orten wie ~/.claude/skills/, ~/.cursor/skills/ oder ~/.gemini/skills/. Der Fähigkeitsanbieter von FastMCP veröffentlicht sie hingegen als MCP-Ressourcen, sodass eine Fähigkeit Adressen im Format skill://customer-research/... erhält, die auf ihre Hauptdatei SKILL.md, ein Manifest, eine Beispieldatei sowie ein JSON-Schema verweisen.
Das ist wichtiger, als es auf den ersten Blick scheint, denn der Server kann nun prozedurales Wissen zusammen mit ausführbaren Funktionen bereitstellen. Stellen Sie sich eine interne Kundenumfragen-Plattform vor, deren MCP-Schnittstelle Tools wie search_salesforce, search_knowledge_base und generate_report anbietet, sowie Fähigkeiten, die zeigen, wie das Team qualifizierte Geschäftsmöglichkeiten definiert, die Forschungsmethodik, das erwartete Berichtsformat, die Anforderungen an Belege sowie Beispiele für gute Berichte.
Das Tool teilt dem Agent mit, was es ausführen kann. Die Fähigkeit gibt an, wie Ihre Organisation die Erledigung der Arbeit erwartet. Die Aufteilung ist vorteilhaft: Sie müssen keine einzelnen Arbeitsanleitungen in einen einzigen riesigen Systemprompt einbauen und auch keine gleichen Fähigkeiten manuell in jeden AI-Client kopieren. Ein Client, der MCP-Ressourcen versteht, kann die Fähigkeit über dieselbe Protokolloberfläche entdecken und abrufen, während ein auf Tools beschränkter Client dennoch über eine Anpassungsschicht auf Ressourcen zugreifen kann, die diese in Toolaufrufe umhüllt.
Ein MCP-Server kann Fähigkeiten, Kontext und Betriebswissen als eine wiederverwendbare Produktgrenze zusammenfassen.
7. Elicitation: Eine Fähigkeit lässt den Benutzer eine Frage stellen
Die einfachste Tool-Interaktion ist einseitig: Das Modell ruft ein Tool auf und das Tool gibt ein Ergebnis zurück. Reale Workflows sind komplizierter. Angenommen, der Benutzer bittet darum, eine neue Cloud-Umgebung für das Analyseprojekt zu erstellen, und das Tool findet drei gültige Regionen sowie zwei Bereitstellungsprofile. Oder es stellt sich heraus, dass die gewünschte Umgebung etwa 420 US-Dollar pro Monat kostet. Oder es werden zwei Salesforce-Konten mit nahezu identischen Namen gefunden. Der richtige nächste Schritt ist nicht immer das Raten. Manchmal sollte die Funktion nachfragen.
Das ist die Idee hinter der MCP-Erkundung. FastMCP verfügt über eine praktische API zur Anfrage strukturierter Eingaben vom Benutzer, doch dieses Muster gehört zu MCP und nicht zu einem bestimmten Python-Framework.
Die 2026-07-28-Spezifikation für MCP hat diesen Austausch im Rahmen von Mehrfach-Rundreiseanfragen (MRTR) überarbeitet, sodass er dem neuen stateless-Protokollmodell entspricht, anstatt von einer in beide Richtungen offenen Sitzung abhängig zu sein. Was sich geändert hat, ist der Mechanismus über das Netzwerk. Die Funktionalität selbst blieb bestehen: Eine Serveroperation kann weiterhin mitten in einem Workflow auf Benutzereingaben warten. Typische Anwendungen sind die Auflösung mehrdeutiger Entitäten, das Ausfüllen fehlender Parameter, die Bestätigung kostspieliger Operationen, die Überprüfung des generierten Inhalts vor der Veröffentlichung, die Auswahl einer Zielumgebung sowie die schrittweise Sammlung strukturierter Informationen.
Es gilt hier eine Sicherheitswarnung: Die Anfrage an den Benutzer stellt keine Autorisierung dar. Wenn eine Löschung Genehmigung erfordert, muss der Backend-Teil selbst diesen Zustand speichern und durchsetzen. Eine freundliche Frage wie „Sind Sie sicher?“ in natürlicher Sprache reicht nicht aus, um die Angelegenheit zu klären. Bei sensiblen Operationen muss eine tatsächliche Zustandsänderung durch einen Menschen erfolgen.
8. Protokollierung: nützlich für den Client, doch die Produktionsüberwachung geht tiefer
Die Protokollierung lässt sich in zwei separate Konzepte einteilen. Eines dient dem Client mit Informationen zur Ausführung: „Suche in Salesforce… 18 passende Opportunities gefunden… Bericht erstellen… Bericht erstellt.“ Das andere Konzept betrifft die Produktionsüberwachung: Identifikatoren für den Trace, die Anfrage, den Benutzer sowie den Mieter, zusätzlich zum Toolnamen, Anbieter, Latenzzeit, Wiederholungsversuchen, dem Entscheidungsresultat der Richtlinie, jeder Task-ID und dem Fehlercode. Behandeln Sie sie als unterschiedliche Aufgaben.
FastMCP dokumentiert weiterhin das Client-Logging, bei dem ein Server Debug-, Info-, Warn- oder Fehlermeldungen an einen MCP-Client sendet, der diese unterstützt. Das hilft während der Entwicklung und gibt dem Client einen Einblick darüber, was eine bestimmte Funktionalität tut. Es gibt jedoch eine wichtige Änderung im Protokoll ab 2026: Die eigene Logging-Funktion des Protokolls wurde für neue Implementierungen in MCP ab 2026-07-28 deaktiviert. Daher sollte ein neues Design für die Überwachbarkeit in der Produktion nicht von MCP-Logging-Nachrichten abhängen. Verwenden Sie stattdessen herkömmliche Anwendungsüberwachungsmethoden: strukturierte Logs, OpenTelemetry-Spuren, Metriken, Datadog, Grafana und Tempo, CloudWatch, ELK oder alles, was Ihre Organisation bereits einsetzt.
Eine Möglichkeit, dies zu verstehen: Statusnachrichten ermöglichen es dem Benutzer oder dem Host, mitzubekommen, was vor sich geht, während serverseitige Telemetriedaten es dem Engineering-, Sicherheits- und Betriebspersonal ermöglichen, das System zu verstehen. Bei einer Unternehmensimplementierung ist die zweite Variante unerlässlich. Eine Benutzeranfrage kann von einem AI-Host über ein MCP-Gateway zu einem proxierten Server, weiter zu einer SaaS-API und schließlich zu einem Hintergrundprozess gelangen – eine einzige Trace-Datenstruktur sollte diesen gesamten Weg erklären können. Je einfacher MCP zum Proxieren und Zusammensetzen ist, desto wichtiger wird diese verteilte Sichtweise.
9. Hintergrundaufgaben: Eine Funktionalität kann ein Ausführungslifecycle haben
Der klassische Ablauf einer Toolaufruf besteht aus Anfrage, Ausführung, Ergebnis und setzt voraus, dass die Aufgabe in einer einzigen Anfrage abgeschlossen werden kann. Viele wertvolle Unternehmensfunktionen passen jedoch nicht dazu: ein Kundendokument mit 60 Seiten, das Indexieren von 20.000 Dokumenten, eine Analyse eines großen Repositoriums, eine vollständige Exportierung der Salesforce-Chancen, die Erstellung einer Präsentation mit begleitenden Unterlagen, ein Konformitätscheck oder eine große Menge an Datensätzen. Solche Aufgaben können mehrere Minuten dauern, erfordern Wiederholungsversuche, über einen Unterbrechung des Client-Verbindungsleiters hinaus weiterlaufen, den Fortschritt melden oder auf einem anderen Worker ausgeführt werden als der MCP-Endpunkt.
Die MCP Tasks-Erweiterung bietet für lang andauernde Ausführungen einen im Protokoll festgelegten Lebenszyklus. FastMCPs Hintergrundaufgaben zeigen dies deutlich: Ein Komponent wird als task-fähig markiert, der Client erhält einen Task-Handle, und die Ausführung wird an einen von einem Task-System unterstützten Hintergrundworker weitergeleitet, anstatt den ursprünglichen Aufruf offen zu halten.
Das unterscheidet sich von der Verwendung von asyncio.create_task(...). Die Konkurrenzfähigkeit in Python behält die Arbeit innerhalb des Prozesses, während eine auf Protokollebene definierte Aufgabe einen Vertrag zwischen Server und Client für langlaufende Aufgaben schafft, wodurch diese Funktion eine vom Client verständliche Lebensdauer hat. Ein weiterer Hinweis darauf, dass ein MCP-Server zu einer vollständigen Anwendungsplattform wird und nicht nur ein RPC-Wrapper ist: Seine Aufgabe besteht nicht nur darin, eine Funktion aufzurufen und JSON zurückzugeben. Er muss möglicherweise auch Aufgaben starten, Zustände speichern, Fortschritt anzeigen, Stornierungen berücksichtigen, von Fehlern wiederherstellen und das Ergebnis zu einem späteren Zeitpunkt zurückgeben.
10. Versionierung: Wenn Agenten auf Ihren Tools angewiesen sind, ist das Schema eine API
Jede erfolgreiche interne Plattform erreicht irgendwann den Punkt, an dem jemand das Schema ändert und dadurch einen Nutzer stört, von dessen Existenz niemand wusste. MCP ist dagegen nicht magisch immun.
Nehmen wir an, Version 1 einer Funktionalität ist calculate_risk(project_id), und Version 2 wird zu calculate_risk(project_id, methodology="v2", include_history=True). Wenn man den neuen Vertrag sofort allen Agenten und Kunden bereitstellt, führt das zu einer bruchstiftenden API-Änderung.
FastMCPs Komponenten-Versionierung ermöglicht es, mehrere Implementierungen derselben Tool-, Ressourcen- oder Prompt-Lösung unter einer einzigen logischen Identifikation zu betreiben. Standardmäßig wird die höchste Version bereitgestellt, und Versionsschalter können für bestimmte Kunden oder Migrationsfenster unterschiedliche Schnittstellen erstellen.
Die übergeordnete Architektur ist wichtiger als die spezifische API. Sobald MCP zu einer gemeinsamen Infrastruktur wird, verdient die Weiterentwicklung der Funktionalitäten dieselbe Betrachtungsweise wie jeder Vertrag für öffentliche Dienstleistungen. Welche Änderungen führen zu Problemen? Welche Clients verlassen sich noch auf v1? Können v1 und v2 nebeneinander laufen, und wie lange sollte das Migrationsfenster andauern? Welche Version hat die Freigabe für die Produktion, wer hat Zugriff auf welche Version, und zu welchem Zeitpunkt wird die alte Version zurückgezogen? Ein nützliches Unternehmensregister könnte schließlich den Toolnamen, Anbieter, Version, Schema-Fingerprint, Eigentümer, Risikoklasse, Freigabedatum sowie Freigabeberechtigte und Ablösedatum erfassen.
Für einen Server mit fünf Tools mag das übertrieben klingen. Für eine Plattform, die 20 Teams bedient, ist es das nicht.
Sobald ein weiteres System auf Ihrem MCP-Schema angewiesen ist, handelt es sich um eine API – egal ob sie benannt ist oder nicht.
11. Testing: Überprüfen Sie die MCP-Oberfläche, nicht nur die Python-Funktion
Das Testen ist hier das am wenigsten spektakuläre Element – und vermutlich das Wichtigste. Stellen Sie sich vor, diese Funktion würde fehlerfrei funktionieren:
async def find_customer(company_name: str):
...
Auch dann kann der MCP-Server defekt sein, wobei das Problem überall in dieser Funktionalität liegen kann: ein falsch generiertes Schema, eine irreführende Beschreibung, eine Transformation, die das falsche Argument versteckt, ein Namespace, der das Tool heimlich umbenennt, eine Sichtbarkeit, die eine Admin-Funktion freigibt, eine Autorisierungsfilterung für den falschen Benutzer, ein Proxy, der keine Anmeldeinformationen weiterleitet, eine Suchschicht, die das Tool nicht finden kann, ein Versionsfilter, der v1 anstelle von v2 bereitstellt, eine Ausgabe, die nicht zur Struktur passt, oder eine Hintergrundaufgabe, die niemals einen Endzustand erreicht.
Deshalb ist es besser, die tatsächliche MCP-Oberfläche zu testen. FastMCPs Testanleitung führt einen echten Client im Prozess gegen den Server aus, sodass das Protokollverhalten getestet werden kann, ohne einen separaten Dienst bereitzustellen. Anstatt nur die Implementierung zu testen:
result = await find_customer("Acme")
assert result
Testen Sie also, was der MCP-Verbraucher tatsächlich sieht:
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
Für eine Plattform zur Bereitstellung von Produktionsfähigkeiten sollten mindestens vier Schichten getestet werden.
Vertragsprüfungen überprüfen den Namen des Tools, die Beschreibung, die Eingangs- und Ausgabeschemata, Anmerkungen sowie die Version im Vergleich zu den Erwartungen.
Entdeckungsprüfungen fragen danach, welche Tools ein bestimmter Benutzer und ein bestimmtes Workflow sehen können und welche versteckt bleiben, ob die Suche die richtige Funktionalität findet und ob versehentlich verbotene Funktionen angezeigt werden können.
Ausführungsprüfungen prüfen, ob der Aufruf erfolgreich ist, ob Fehler ordnungsgemäß strukturiert sind, ob Wiederholungsversuche sicher sind, ob Proxy-Server die richtige Identität weiterleiten und ob die Autorisierung zur Ausführungszeit erneut überprüft wird.
Lebenszyklusprüfungen prüfen, ob Hintergrundaufgaben sauber abgeschlossen oder fehlschlagen, ob sie storniert werden können, ob eine Versionsmigration alte Clients weiterhin funktionstüchtig hält und was passiert, wenn ein übergeordneter MCP-Server nicht verfügbar ist.
Keines davon dient dazu, das Framework zu testen. Es geht vielmehr um den Test Ihres Produktvertrags. Sobald MCP die Funktionslage für mehrere Clients und Agenten darstellt, verdient dieser Vertrag dieselbe Sorgfalt wie REST, gRPC oder ereignisgesteuerte Schnittstellen.
Setzen Sie die Komponenten zusammen – der Server sieht völlig anders aus
Wenn man all diese Ideen miteinander verbindet, entsteht eine Lösung, die sich um die Entdeckung, Routenplanung, Anpassung von Schnittstellen, Kontrolle des Kontexts, Richtlinien, interaktive Workflows, asynchrone Ausführung, wiederverwendbares Betriebswissen, Kompatibilität sowie einen ingenieurtechnischen Lebenszyklus kümmert. Das ist schon seit längerer Zeit kein Server mit einigen Tools mehr – es handelt sich dabei um eine Produktoberfläche. Noch besser: Nichts davon erfordert, dass der Modellanbieter die Geschäftslogik besitzt, denn dieselbe Plattform kann hinter jedem MCP-kompatiblen Host stehen, den die Organisation wählt. Das ist der strategisch wichtige Aspekt.
Ein Teil der besten Optimierungen findet bereits statt, bevor das Modell etwas sieht
Viele Debatten über die Leistung künstlicher Intelligenz drehen sich um das Modell selbst: Welches Modell, wie viele Parameter, wie groß das Kontextfenster, wie gut seine Schlussfolgerungskraft. Das ist wichtig, doch in der Produktion kann die um das Modell herumliegende Architektur eine enorme Menge an überflüssiger Arbeit beseitigen.
Nehmen wir an, die Plattform verfügt über 300 Tools. Eine naive Implementierung führt alle 300 Schemata in den Kontext des LLM ein und hofft, dass dieses die richtige Wahl trifft. Eine überlegte Implementierung verringert die Auswahl schrittweise. Richtlinien reduzieren die Anzahl auf 85 zulässige Schemata. Die Sichtbarkeit des Workflows beschränkt diese auf 24 relevante Schemata. Die Suche führt schließlich zu 4 Kandidaten, und nur diese 4 Schemata werden zum endgültigen Entscheidungsprozess des Modells geladen.
Das Modell wurde nicht intelligenter – das System hingegen schon. Das ist ein wichtiger Grund dafür, warum diese Muster in der Produktion von Bedeutung sind. Der Kontext wird eingeschränkt, die Genauigkeit der Auswahl verbessert sich, irrelevante Aktionen gehen zurück, die Autorisierung wird klarer, die Backend-Verträge bleiben außerhalb des Modells, und unabhängige Teams können zusammenarbeiten, ohne Code zu verschmelzen – all das, bevor vom LLM verlangt wird, über seine nächste Aktion nachzudenken.
Eine gute Agent-Architektur beschränkt sich nicht darauf, das Denkvermögen des Modells zu verbessern. Sie prägt auch den Stoff, über den das Modell nachdenken muss.
Von einem MCP-Server zu einem Netzwerk davon
Bei Unternehmenssystemen wird die Entwicklung hier wirklich interessant. Die ursprüngliche Struktur sah so aus:
AI client
↓
MCP server
↓
API
Die nächste Einheit sieht eher wie ein Gateway in der Mitte aus, mit Domain-Servern und Worker-Servern dahinter. Jeder MCP-Server konzentriert sich auf seine Aufgabe, jedes Team ist für sein eigenes Domänenbereich verantwortlich, und jeder Service wird nach seinem eigenen Zeitplan bereitgestellt. Das Gateway erstellt eine geeignete Schnittstelle für jeden Benutzer, das Modell entdeckt nur das, was es benötigt, ein langer Workflow wird in eine Aufgabe umgewandelt, und eine Fähigkeit lehrt den Agenten, wie das Unternehmen den Workflow ablaufen lassen möchte – wobei alles über die MCP-Grenzen hinweg nutzbar bleibt.
Das erinnert viel mehr an eine verteilte Anwendungsplattform als an einen Haufen Funktionsumhüllungen, weshalb die Bezeichnung „nur Tools für LLMs“ für MCP-Server zunehmend unterschätzt, was sie eigentlich darstellen.
Bauen Sie keine Plattform, solange kein Plattformproblem auftritt
Die Gefahr ist offensichtlich. Nach dem Lesen all dessen könnte man zu dem Schluss kommen, dass ein internes Server-System mit fünf Funktionen drei Gateways, ein Funktionsregister, die Einbettung von Suchfunktionen in die Toolschemata, einige Namespace, eine Verhandlung der Laufzeitversion, eine verteilte Warteschlange für Aufgaben, einen Marktplatz für Fähigkeiten sowie ein Dutzend aufeinander aufbauender Transformationen benötigt.
Tun Sie das bitte nicht.
Ein Server mit sechs stabilen Tools, die jeder Benutzer sehen sollte? Schicken Sie einfach diese sechs. Wenn das Backend-Schema bereits sauber ist, fügen Sie keine Transformation hinzu, nur weil ein Framework eine unterstützt. Bei einem einzigen Server gibt es keinen Bedarf an einer Proxy-Topologie. Wenn eine Operation in zwei Sekunden abgeschlossen ist, benötigt sie vermutlich keinen Task. Wenn niemand mehr v1 verwendet, gibt es keinen Grund, zwei Versionen ewig am Leben zu erhalten.
Architektur sollte als Reaktion auf ein Problem entstehen, nicht umgekehrt. Das Ziel besteht nicht darin, die Anzahl der Framework-Funktionen in Ihrem Repository zu maximieren. Vielmehr soll verhindert werden, dass MCP einen dazu zwingt, um dieses Problem herum eine vollständig eigene KI-Plattform zu entwickeln. Das Ökosystem stellt nun wiederverwendbare Bausteine für die gleichen Probleme bereit, mit denen jede ausgereifte Anwendungsplattform konfrontiert ist – und das ist Fortschritt.
Das Framework kann ausgetauscht werden; die Architektur ist das Wichtigste
FastMCP verdient Anerkennung dafür, dass es viele dieser Konzepte an einem Ort sichtbar macht. Seine Dokumentation erläutert Provider, Transformationen, Suchfunktionen, Namensräume, Sichtbarkeit, Proxying, Fähigkeiten, Abfragemethoden, Aufgaben, Versionen und Tests, wodurch leicht zu erkennen ist, wie sich die Komponenten eines MCP-Servers gegenseitig beeinflussen. Mehrere dieser Muster werden bereits in der Praxis eingesetzt, weil sie reale Probleme lösen: Verringerung des Tool-Kontexts, Trennung der modellorientierten Verträge von denen des Backends, Einschränkung der offengelegten Funktionalitäten, Zusammenführung von Integrationen sowie Erleichterung des Betriebs des resultierenden Systems.
Trotzdem sollten Teams die Idee übernehmen und nicht die API der Bibliothek. Fragen Sie sich: Brauchen wir eine auf Anfrage funktionierende Werkzeugerkennung? Eine Transformationsschicht für Modelle? Ein Funktionsgateway? Sichtbarkeit spezifisch für Workflows? Fähigkeiten, die über MCP-Ressourcen verteilt werden? Einen zuverlässigen Lebenszyklus für langwierige Operationen? Versionierte Funktionsverträge? Testen wir, was der Client tatsächlich sieht? Bauen Sie anschließend die Lösungen mit dem Stack auf, der zu Ihrer Organisation passt.
Das Protokoll sorgt für Interoperabilität. Das Framework bietet Bequemlichkeit. Die Architektur bleibt weiterhin Ihre.
Was hat sich geändert
Der wichtigste Wandel bei MCP liegt nicht in einer längeren Funktionsliste. Es geht vielmehr um den zunehmenden Umfang dessen, was von einem MCP-Server erwartet wird. Anfangs war das Konzept einfach: Ein Tool wird veröffentlicht, das Modell ruft es auf, und es kommt ein Ergebnis zurück. Das sich nun entwickelnde Modell beinhaltet nun die Einbeziehung von Funktionalitäten aus mehreren Systemen, die Normalisierung ihrer Schnittstellen, die Zuweisung von Identitäten, das Filtern nach Relevanz, die Autorisierung dessen, was erlaubt ist, das Nachschlagen in großen Katalogen auf Anfrage, die Bereitstellung wiederverwendbarer Fähigkeiten und Kontexte, die Stellung einer Frage an den Benutzer, wenn eine Entscheidung erforderlich ist, den Umwandlung langsamer Arbeitsabläufe in zuverlässige Ausführungen, die Überwachung des gesamten Ablaufs, das Versionieren der Schnittstellen sowie das Testen des Produkts als echtes Produkt.
Das ist eine völlig andere Aufgabe. MCP ist absichtlich weiterhin ein Protokoll und kein Anwendungsframework, doch das um es herum entstehende Ökosystem macht MCP-Server zu einer ernsthaften Anwendungsplattform, auf der Schichten für Routing, Verwaltung, Lebenszyklus, Kompatibilität und Komposition genauso wie in ausgereiften Backend-Systemen erstellt werden können.
Ein gut konstruierter MCP-Server ist nicht länger nur ein Mittel, um einem LLM eine weitere Funktion zu verleihen. Er kann ein wiederverwendbares Funktionsprodukt sein, das Agenten, Modellen, Teams sowie Client-Apps gleichermaßen dient. Ein einzelner Server kann klein bleiben, während ein Netzwerk solcher Server zu einer Unternehmensplattform heranwachsen kann. Das Modell bleibt flexibel, die Funktionslayer bleiben gut verwaltet, und der darüber liegende Client kann ausgetauscht werden, ohne die darunterliegende Geschäftsfunktion neu erstellen zu müssen.
Verwandte Artikel
- MCP 2026-07-28: Wie die stateless Spezifikation das Design von Remote-Servern verändert — Wie die stateless 2026-07-28-Version von MCP Sessions und den Handshake entfernt, MRTR, Tasks sowie Cache-Hinweise hinzufügt und welche Auswirkungen dies auf die Migration hat.
- Cloud Browser: Eine sichere, agentunabhängige Cloud-Browser-Plattform für jeden AI-Agenten — Ein Referenzdesign für einen modellunabhängigen Remote-Browser-Dienst: Gateway, Worker, WebRTC-Live-Ansicht, Genehmigungsmechanismen, SSRF-Schutzmaßnahmen, Wiedergabefunktion sowie alle Konfigurationseinstellungen.