MCP · 10 Min.
MCP Server bauen 2026: Tool-Server für 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 für 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 müssen von Anfang an Teil des Server-Designs sein.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten 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 prüfbare Agenten.
Für Unternehmen ist MCP deshalb interessant, wenn mehrere Agenten dieselben Fähigkeiten 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 für Architekturentscheidungen: Tools sollten für 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-Prüfung und Session-Management mit.
Auch der Lifecycle zählt: 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 für Enterprises spannend, weil Fähigkeiten nicht nur implizit im Prompt stehen.
Warum MCP gerade relevant wird Agenten werden erst richtig nützlich, 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-Schlüssel und improvisierte Integrationen.
Das Model Context Protocol bietet einen Standardansatz, um Tools und Kontext für KI-Systeme bereitzustellen. Für 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 Fähigkeiten mit klaren Eingaben, Ausgaben und Grenzen.
Das ist wichtig, weil Tool-Zugriff sonst schnell chaotisch wird. Ein Server kann Rechte bündeln, 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 Fähigkeiten, die ein Workflow braucht.
Tools sind Aktionen, die das Modell aktiv auslösen kann. Resources sind lesbare Kontextquellen, die eine Anwendung gezielt in den Kontext gibt. Prompts sind wiederverwendbare Arbeitsmuster, die der Nutzer bewusst auswählt. Wann sich ein eigener Server lohnt Ein eigener MCP Server lohnt sich, wenn ein Unternehmen wiederholt dieselben internen Daten oder Tools für 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 für Sales-Agenten. Ticket-Suche für Support-Agenten. Dokumentenstatus für Operations-Agenten. Angebotsdaten für Finance- oder Sales-Workflows. Projektwissen für Delivery-Agenten. Stdio, Streamable HTTP oder Remote Server? Lokale MCP-Server laufen oft über stdio: Der Client startet den Server als Prozess und kommuniziert über Standard-In/Out. Das ist gut für lokale Developer-Tools, Dateisysteme oder interne Prototypen.
Für Teams und Produkte wird Streamable HTTP interessanter. Der Server läuft als eigenständiger 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 Generalschlüssel 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, löschen. Ein Agent sollte nicht durch denselben Kanal recherchieren und irreversible Aktionen ausführen.
Die aktuelle Authorization-Spezifikation ist für 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.
Für Unternehmen heisst das:
Jeder Server hat eine klare Resource Identity. Tokens werden für 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 für die Messages API, Cloudflare bietet MCP-Portale als Kontrollschicht für mehrere Server hinter einem HTTP-Endpunkt, und Claude Code empfiehlt für Remote-Server HTTP statt veraltetem SSE.
Das ändert den Standard für Unternehmen: Ein MCP-Server ist nicht mehr nur ein lokaler Helfer für Entwickler. Er kann Teil der produktiven Integrationsarchitektur werden.
Aber Remote MCP braucht härtere Regeln:
Server muss öffentlich oder kontrolliert erreichbar sein. Auth muss vor jedem Toolzugriff greifen. Capabilities müssen regelmäßig synchronisiert und versioniert werden. Drittanbieter-Server gelten als untrusted, bis Security und Datenfluss geprüft sind. ZDR- und Retention-Anforderungen müssen pro Client/Connector geprüft werden. Gute Tool-Designs Ein gutes Tool ist eng, eindeutig und prüfbar. "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 lässt sich testen, loggen und freigeben.
Ein gutes MCP-Tool hat:
Wenn ein Tool nicht in einem Satz erklärt werden kann, ist es wahrscheinlich zu breit.
einen engen Namen eine klare Beschreibung ein strenges Input-Schema deterministische Fehlercodes idempotentes Verhalten, wo möglich explizite Risiko-Klasse klare Logging- und Approval-Regeln Fehler, die Unternehmen vermeiden sollten Der häufigste Fehler ist, MCP als Abkürzung 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 für jeden kritischen Zugriff.
Release-Gate für MCP Server Bevor ein MCP-Server produktiv genutzt wird, sollte er ein kleines Gate bestehen:
MCP macht Agenten handlungsfähig. Genau deshalb muss MCP stärker 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 über 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?
