MCP (Model Context Protocol) löst ein konkretes Problem, das in fast jedem KI-Projekt irgendwann auftaucht: Wie bekommt ein LLM kontrollierten Zugriff auf echte Unternehmensdaten und -werkzeuge, ohne dass man für jede Anbindung eine Individuallösung bauen muss? Seit Anthropic das Protokoll als Open Standard veröffentlicht hat, wächst das Ökosystem schnell. Es lohnt sich, genauer hinzuschauen.
Was ist MCP und wozu braucht man es?
Wer schon einmal einen KI-Agenten gebaut hat, der auf mehrere Tools zugreift (ein Ticketsystem, eine Datenbank, eine interne API), kennt das Muster: Jede Anbindung ist ein Einzelprojekt. Jede braucht eigene Authentifizierung, eigene Fehlerbehandlung und eigenes Schema. Das skaliert schlecht. Praktische Anwendungsfälle für solche Agenten haben wir in KI-Agenten im Enterprise-Einsatz und KI-Automatisierung im Alltag zusammengefasst. Wer Tool-Zugriffe mit eigenen Wissensquellen verbinden will, findet in RAG-Systemen den ergänzenden Baustein.
MCP schlägt eine einheitliche Client-Server-Architektur vor. LLMs kommunizieren über einen standardisierten Kanal mit sogenannten MCP-Servern. Jeder Server exponiert eine Menge von Tools, Resources und Prompts. Der KI-Client (zum Beispiel ein Anthropic Claude-Modell oder ein eigenes Agentenframework) kann diese Fähigkeiten per JSON-RPC abfragen und aufrufen (statt zehn Ad-hoc-Integrationen).
Wie MCP technisch funktioniert
Die Architektur besteht aus drei Kernkomponenten:
- MCP Host ist die Applikation, die das LLM hostet (z.B. ein Claude Desktop Client, ein eigener Agenten-Server oder ein IDE-Plugin)
- MCP Client ist die Protokollschicht im Host, die Verbindungen zu Servern verwaltet
- MCP Server ist ein leichtgewichtiger Prozess, der konkrete Fähigkeiten bereitstellt
Die Kommunikation läuft über JSON-RPC 2.0, wahlweise über stdio (für lokale Server) oder HTTP mit SSE (für remote Services). Transport-Unabhängigkeit war beim Design bewusst eine Priorität.
Ein minimaler MCP-Server in Python sieht so aus:
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import mcp.types as types
app = Server("jira-connector")
@app.list_tools()
async def list_tools() -> list[Tool]:
return [
Tool(
name="get_issue",
description="Lädt ein Jira-Ticket anhand seiner ID",
inputSchema={
"type": "object",
"properties": {
"issue_id": {"type": "string", "description": "Jira Issue ID, z.B. PROJ-123"}
},
"required": ["issue_id"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
if name == "get_issue":
issue_id = arguments["issue_id"]
# Hier echte Jira-API-Abfrage
issue_data = fetch_jira_issue(issue_id)
return [TextContent(type="text", text=str(issue_data))]
raise ValueError(f"Unbekanntes Tool: {name}")
async def main():
async with stdio_server() as (read_stream, write_stream):
await app.run(read_stream, write_stream, app.create_initialization_options())
if __name__ == "__main__":
import asyncio
asyncio.run(main())Der Server läuft als eigenständiger Prozess. Der MCP-Host startet ihn und kommuniziert über stdin/stdout. Dies hält die Deployment-Komplexität niedrig und die Isolation hoch.
Praxistaugliche Anwendungsfälle
In Kundenprojekten bei EverBright haben sich drei Einsatzszenarien als besonders wertvoll herausgestellt:
Ticket- und Projektsysteme (Jira, Linear, GitHub Issues)
Ein KI-Assistent, der Tickets anlegen, priorisieren und zusammenfassen kann, ist für Entwicklungsteams einer der unmittelbarsten Mehrwerte. Mit MCP lässt sich ein solcher Assistent in wenigen Stunden aufsetzen, ohne direkten Datenbankzugriff und nur über die bestehende REST-API.
Interne Wissensdatenbanken (Confluence, Notion, SharePoint)
Suche in Confluence war immer ein schlechter Witz. Ein MCP-Server, der Seiten semantisch durchsucht und dem LLM relevante Ausschnitte übergibt, hebt den Informationszugriff auf ein anderes Level. Das Wichtigste: Der Server entscheidet, welche Dokumente exponiert werden. So bleibt der Zugriff kontrollierbar.
BI und Reporting (Metabase, Looker, direkter SQL-Zugriff)
Statt Dashboards zu exportieren und manuell zu interpretieren, kann ein Analyst einem KI-Agenten die Frage stellen: “Welche Produktkategorie hat diese Woche die höchste Retourenquote?” Der MCP-Server übersetzt dies in eine SQL-Abfrage, gibt das Ergebnis zurück, und das Modell formuliert die Antwort inklusive Anomalie-Hinweisen.
Sicherheit und Kontrolle im Produktionseinsatz
MCP löst das Integrationsproblem, aber nicht das Sicherheitsproblem. Wie gefährlich unkontrollierte Agenten-Adoption werden kann, zeigt der Blick auf OpenClaw und seine Enterprise-Risiken. Ein paar Leitlinien aus der Praxis:
Least Privilege konsequent umsetzen. Jeder MCP-Server sollte nur die minimal nötigen Berechtigungen haben. Ein Jira-Server für Lesezugriff braucht keine Schreibrechte. Das klingt trivial, wird aber oft zugunsten von Bequemlichkeit ignoriert.
Tool-Descriptions sorgfältig schreiben. Das LLM entscheidet auf Basis der Tool-Beschreibungen, was es aufruft. Unklare oder zu breite Beschreibungen führen zu unerwarteten Calls. Besser spezifisch sein: “Gibt den Inhalt eines einzelnen Confluence-Artikels zurück (kein Suchen, kein Schreiben).”
Sensitive Outputs nicht ungeprüft weitergeben. Wenn ein Tool personenbezogene Daten oder Geschäftsgeheimnisse zurückgeben kann, muss das im Agenten-Layer berücksichtigt werden, entweder durch Output-Filtering im Server oder durch explizite Consent-Steps im Workflow.
Audit-Logging einbauen. Jeder Tool-Call sollte geloggt werden: Wer hat den Agenten gestartet, welche Tools wurden aufgerufen, welche Parameter, welche Ergebnisse? Das ist nicht nur für Debugging relevant, sondern für Compliance-Anforderungen zwingend.
Wann MCP sinnvoll ist und wann nicht
MCP ist kein Allheilmittel. Es macht Sinn, wenn:
- Mehrere Agenten oder Teams dieselben Tools brauchen (Wiederverwendung zahlt sich aus)
- Bestehende APIs bereits vorhanden sind (MCP wird zum Adapter, kein Neubau nötig)
- Standardisierung Priorität hat, zum Beispiel wenn mehrere LLM-Provider oder Frameworks in Frage kommen
Es macht weniger Sinn, wenn:
- Es sich um ein einmaliges, isoliertes Proof-of-Concept handelt. Hier ist direktes Function Calling schneller aufgesetzt.
- Die Tool-Logik hochkomplex ist und bidirektionale State-Haltung erfordert. MCP ist zustandslos per Design.
- Das Team keinerlei Erfahrung mit asynchronen Protokollen hat und eine einfachere Lösung ausreicht
Fazit
MCP ist kein Hype-Protokoll, sondern eine nüchterne Lösung für ein echtes Engineering-Problem: die Fragmentierung von KI-Tool-Integrationen. Wer ernsthaft plant, KI-Agenten in Unternehmenstools zu integrieren, sollte MCP als Standard-Baustein einplanen. Das wachsende Ökosystem vorgefertigter Server (für GitHub, Slack, Postgres und viele mehr) reduziert den Eigenaufwand erheblich.
Für eigene Projekte empfiehlt sich der Einstieg über das offizielle MCP SDK und die Referenzimplementierungen. Dort findet sich genug Material für einen produktiven ersten Tag.
Zum Thema gibt es außerdem ein begleitendes Video auf unserem YouTube-Kanal.
Wer konkrete Anforderungen an KI-Agenten im Unternehmenseinsatz hat, kann sich bei EverBright melden. KI-Beratung und Umsetzung ist einer unserer Kernschwerpunkte. Wer tiefer in die Architektur von Agenten-Systemen einsteigen will, findet im Artikel zu KI-Agenten in der Praxis weitere Einblicke.
Jetzt Beratungsgespräch vereinbaren →
Häufige Fragen
Wann ist MCP sinnvoll und wann nicht?
MCP lohnt sich, wenn mehrere Agenten oder Teams dieselben Tools brauchen, wenn bestehende APIs vorhanden sind oder wenn Standardisierung Priorität hat. Es ist weniger sinnvoll für einmalige Proof-of-Concepts, hochkomplexe Tool-Logik mit State-Haltung oder wenn das Team keine Erfahrung mit asynchronen Protokollen hat.
Kann MCP sensible Unternehmensdaten schützen?
Ja, MCP selbst bietet keine Sicherheit, aber erlaubt es, Sicherheit zu implementieren. Der MCP-Server entscheidet, welche Daten exponiert werden. Least Privilege anwenden, Tool-Beschreibungen sorgfältig schreiben, Outputs filtern und Audit-Logging einbauen sind die Kernmaßnahmen.
Wie unterscheidet sich MCP von direktem Function Calling?
MCP ist ein standardisiertes Protokoll für mehrere Integrationen. Function Calling ist direkter, aber weniger strukturiert. MCP skaliert besser: Einmal implementiert, funktioniert der Server mit verschiedenen LLM-Providern und Frameworks. Das zahlt sich aus, wenn mehrere Agenten oder Tools zusammenkommen.
Welche praktischen Use Cases funktionieren am besten mit MCP?
Ticket-Systeme (Jira, Linear, GitHub Issues), interne Wissensdatenbanken (Confluence, Notion) und BI-Systeme (Metabase, Looker, SQL). Dabei kann ein Agent Tickets analysieren, semantisch in Dokumenten suchen oder Daten abfragen, ohne dass für jedes Tool eine separate Integration nötig ist.
