MCP · 10 Min.
MCP Server bauen 2026: Tool-Server fuer produktive KI-Agenten
MCP wird spannend, wenn Agenten nicht nur reden, sondern sauber mit internen Tools und Daten arbeiten sollen.
SYSTEMS Grafik zu MCP Server bauen: Context -> Tools -> Control. Fokus: Wann lohnt sich ein eigener MCP Server fuer Unternehmensdaten und Agenten-Tools?
Kurzfassung
MCP verbindet Agenten strukturiert mit Tools, Datenquellen und Kontext. Ein eigener MCP Server lohnt sich, wenn interne Systeme sicher und wiederholbar nutzbar werden sollen. Security, Rechte und Logging muessen von Anfang an Teil des Server-Designs sein.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Update Mai 2026: MCP ist eine Integrationsschicht, kein Plug-in Die aktuellen MCP -Dokumente machen den Punkt klarer als viele Hype-Threads: Ein Server stellt Tools, Ressourcen und Prompts bereit. Das ist eine Architekturentscheidung. Tools sind Aktionen, Ressourcen sind Kontext, Prompts sind wiederverwendbare Arbeitsmuster. Wer diese drei Dinge vermischt, baut schwer pruefbare Agenten.
Fuer Unternehmen ist MCP deshalb interessant, wenn mehrere Agenten dieselben Faehigkeiten brauchen: CRM lesen, Tickets suchen, Dokumente abrufen, Kalenderkontext nutzen oder sichere Schreibaktionen vorbereiten. Der Wert liegt nicht im Protokoll allein, sondern in der kontrollierten Wiederverwendbarkeit.
Die MCP-Spezifikation ist dabei konkret genug fuer Architekturentscheidungen: Tools sollten fuer riskante Aktionen mit Human-in-the-loop gedacht werden, Resources liefern Kontext, Prompts sind user-kontrollierte Vorlagen, und Streamable HTTP bringt eigene Anforderungen an Auth, Origin-Pruefung und Session-Management mit.
Auch der Lifecycle zaehlt: Ein MCP-Client startet nicht einfach mit Tool Calls, sondern initialisiert zuerst die Verbindung, verhandelt Protokollversion und Capabilities und arbeitet danach im normalen Betriebsmodus. Genau diese Capability-Negotiation macht MCP fuer Enterprises spannend, weil Faehigkeiten nicht nur implizit im Prompt stehen.
Warum MCP gerade relevant wird Agenten werden erst richtig nuetzlich, wenn sie mit echten Systemen arbeiten: CRM, Tickets, Dateien, Datenbanken, Kalender, Knowledge Bases oder interne APIs. Genau hier entsteht das Problem: Jeder Agent braucht Tool-Zugriffe, aber niemand will unkontrollierte API-Schluessel und improvisierte Integrationen.
Das Model Context Protocol bietet einen Standardansatz, um Tools und Kontext fuer KI-Systeme bereitzustellen. Fuer Unternehmen kann ein eigener MCP Server zur sauberen Integrationsschicht werden.
Was ein MCP Server macht Ein MCP Server stellt Ressourcen, Tools und Prompts in strukturierter Form bereit. Der Agent muss nicht wissen, wie jedes interne System technisch funktioniert. Er bekommt definierte Faehigkeiten mit klaren Eingaben, Ausgaben und Grenzen.
Das ist wichtig, weil Tool-Zugriff sonst schnell chaotisch wird. Ein Server kann Rechte buendeln, Daten normalisieren und Fehlverhalten sichtbar machen.
Tools, Resources und Prompts nicht vermischen Die wichtigste Designentscheidung ist die Trennung der drei MCP-Bausteine:
Diese Trennung verhindert viele schlechte Architekturen. Ein CRM-Datensatz ist keine Aktion. Ein "Lead bewerten"-Prompt ist kein API-Key. Ein Tool zum Schreiben in ein CRM ist kein allgemeiner Datenzugriff.
Gute MCP-Server machen diese Grenzen sichtbar. Sie geben dem Agenten nicht "alles", sondern genau die Faehigkeiten, die ein Workflow braucht.
Tools sind Aktionen, die das Modell aktiv ausloesen kann. Resources sind lesbare Kontextquellen, die eine Anwendung gezielt in den Kontext gibt. Prompts sind wiederverwendbare Arbeitsmuster, die der Nutzer bewusst auswaehlt. Wann sich ein eigener Server lohnt Ein eigener MCP Server lohnt sich, wenn ein Unternehmen wiederholt dieselben internen Daten oder Tools fuer mehrere Agenten bereitstellen will.
Wenn nur ein einzelner, einfacher Tool Call gebraucht wird, reicht oft eine direkte Integration. Wenn daraus Infrastruktur wird, lohnt sich MCP.
CRM-Leserechte fuer Sales-Agenten. Ticket-Suche fuer Support-Agenten. Dokumentenstatus fuer Operations-Agenten. Angebotsdaten fuer Finance- oder Sales-Workflows. Projektwissen fuer Delivery-Agenten. Stdio, Streamable HTTP oder Remote Server? Lokale MCP-Server laufen oft ueber stdio: Der Client startet den Server als Prozess und kommuniziert ueber Standard-In/Out. Das ist gut fuer lokale Developer-Tools, Dateisysteme oder interne Prototypen.
Fuer Teams und Produkte wird Streamable HTTP interessanter. Der Server laeuft als eigenstaendiger Prozess, kann mehrere Clients bedienen und kann mit Auth, Session-IDs und zentraler Observability betrieben werden. Genau hier steigen aber die Anforderungen: Origin Header validieren, lokal nicht an `0.0.0.0` binden, Auth sauber erzwingen und Sessions kryptografisch robust behandeln.
Kurz: stdio ist einfach. HTTP ist betreibbar. Enterprise braucht meistens eine bewusste Mischung.
Offizielle SDKs machen den Start leichter, aber sie ersetzen kein Server-Design. TypeScript, Python, C#, Go und weitere SDKs helfen beim Protokoll. Die eigentliche Arbeit bleibt: Tool-Grenzen, Auth, Scopes, Fehlerverhalten, Logs und Deployment.
Die Security-Frage Ein MCP Server darf kein Generalschluessel sein. Er braucht Auth, Rollen, Scopes, Rate Limits, Input-Validierung, Output-Filter und Logging.
Besonders wichtig ist, Tools nach Risiko zu trennen: lesen, suchen, vorbereiten, schreiben, loeschen. Ein Agent sollte nicht durch denselben Kanal recherchieren und irreversible Aktionen ausfuehren.
Die aktuelle Authorization-Spezifikation ist fuer HTTP-basierte MCP-Server besonders deutlich: OAuth 2.1, Protected Resource Metadata, Resource Indicators, Bearer Tokens pro Request und Audience Validation sind keine Nebenfragen. Ein MCP-Server darf Tokens nicht einfach an nachgelagerte APIs durchreichen. Token Passthrough und Confused-Deputy-Probleme sind echte Architekturfallen.
Fuer Unternehmen heisst das:
Jeder Server hat eine klare Resource Identity. Tokens werden fuer genau diesen Server ausgestellt. Scopes sind klein und versioniert. Schreibtools haben getrennte Berechtigungen. Downstream-APIs bekommen eigene Tokens, nicht den Client-Token. Logs zeigen Tool-Nutzung, aber leaken keine Secrets. Remote MCP in echten Produkten Remote MCP wird wichtiger, weil Modelle nicht nur lokale Desktop-Tools ansprechen sollen. Anthropic dokumentiert den MCP Connector fuer die Messages API, Cloudflare bietet MCP-Portale als Kontrollschicht fuer mehrere Server hinter einem HTTP-Endpunkt, und Claude Code empfiehlt fuer Remote-Server HTTP statt veraltetem SSE.
Das aendert den Standard fuer Unternehmen: Ein MCP-Server ist nicht mehr nur ein lokaler Helfer fuer Entwickler. Er kann Teil der produktiven Integrationsarchitektur werden.
Aber Remote MCP braucht haertere Regeln:
Server muss oeffentlich oder kontrolliert erreichbar sein. Auth muss vor jedem Toolzugriff greifen. Capabilities muessen regelmaessig synchronisiert und versioniert werden. Drittanbieter-Server gelten als untrusted, bis Security und Datenfluss geprueft sind. ZDR- und Retention-Anforderungen muessen pro Client/Connector geprueft werden. Gute Tool-Designs Ein gutes Tool ist eng, eindeutig und pruefbar. "update_crm" ist zu breit. "add_research_note_to_lead" ist besser, weil Zweck, Datenform und Risiko klarer sind.
Je enger das Tool, desto leichter laesst sich testen, loggen und freigeben.
Ein gutes MCP-Tool hat:
Wenn ein Tool nicht in einem Satz erklaert werden kann, ist es wahrscheinlich zu breit.
einen engen Namen eine klare Beschreibung ein strenges Input-Schema deterministische Fehlercodes idempotentes Verhalten, wo moeglich explizite Risiko-Klasse klare Logging- und Approval-Regeln Fehler, die Unternehmen vermeiden sollten Der haeufigste Fehler ist, MCP als Abkuerzung zu verstehen: schnell Server bauen, viele Tools freigeben, Agent loslassen. Das erzeugt Risiko.
Der bessere Weg ist ein kleiner Server mit wenigen, starken Tools und einem Eval-Set fuer jeden kritischen Zugriff.
Release-Gate fuer MCP Server Bevor ein MCP-Server produktiv genutzt wird, sollte er ein kleines Gate bestehen:
MCP macht Agenten handlungsfaehig. Genau deshalb muss MCP staerker kontrolliert werden als ein normaler Lesekonnektor.
Tool-Liste ist absichtlich klein. Jede Tool-Beschreibung ist eindeutig. Schemas validieren Pflichtfelder hart. Auth und Scopes sind getestet. Schreibaktionen brauchen Approval oder Dry-Run. Prompt-Injection ueber Resources wird getestet. Logs enthalten Tool-Name, Input-Klasse, Ergebnisstatus und Run-ID. Rate Limits greifen pro Nutzer, Kunde oder Agent. Der SYSTEMS-Blick MCP ist kein Selbstzweck. Es wird wertvoll, wenn Agenten wiederholbar und kontrolliert mit Unternehmenssystemen arbeiten sollen.
Die beste MCP-Architektur startet nicht beim Protokoll, sondern bei der Frage: Welche Arbeit soll ein Agent mit welchen Rechten wirklich erledigen?
