MCP Server erstellen: Mit Python vom lokalen Tool zum Teamdienst

Ein sinnvoller erster Server hat eine klar begrenzte Aufgabe: Er nimmt eine Bestell-ID entgegen und liefert den Status zurück. Damit beginnt diese Anleitung. Ein allgemeines Datenbank-Tool würde dem Modell zu viele Entscheidungen überlassen und ihm mehr Zugriff geben, als dieser Ablauf erfordert.

Die Anleitung folgt dem aktuellen offiziellen Server-Tutorial. Mit Stand vom 7. Oktober 2026 verwendet die Dokumentation die MCP-Spezifikation 2026-07-28 und das offizielle Python SDK mit seiner MCPServer-API. Diese Bibliothek übernimmt die MCP-Nachrichten. Das Beispiel legt die Version auf SDK 2.3.0 fest, damit Imports aus älteren Tutorials nicht unbemerkt zu einer anderen Installation führen.

Welche Funktionen stellt ein MCP-Server bereit?

Ein MCP-Server ist eine kontrollierte Anlaufstelle zwischen einer KI-Anwendung und den eigenen Systemen. Die Anwendung kann verfügbare Funktionen erfragen, eine Anfrage stellen und ein Ergebnis empfangen. Was diese Anlaufstelle leisten darf, bestimmt der Servercode.

MCP, das Model Context Protocol, gibt diesem Austausch ein gemeinsames Format. Der Host ist die verwendete Anwendung, etwa Claude Code oder Cursor. Ihr Client übernimmt die Kommunikation mit dem Server über das Protokoll. Das sind Rollen innerhalb des Systems; es müssen dafür keine drei zusätzlichen Anwendungen installiert werden.

Ein Tool kann auf Lesezugriffe beschränkt sein. Die Bezeichnung als Ressource ersetzt keine Zugriffsprüfung. Ein Prompt enthält Anweisungen, erteilt aber keine Berechtigung. Welche Funktionen Clients unterstützen und wie sie diese darstellen, unterscheidet sich. Deshalb die tatsächlich angebotenen Funktionen prüfen. Das sind die drei Grundbausteine eines Servers; der folgende Server benötigt lediglich ein Tool.

Vor dem Bau lohnt sich die Prüfung, ob ein gepflegter Konnektor die Aufgabe bereits abdeckt. Unser Überblick über die besten MCP-Server für 2026 bietet dafür einen Einstieg. Ein eigener Server lohnt sich, wenn interne Daten, Berechtigungsregeln oder Abläufe von diesen Konnektoren abweichen.

MCP Server erstellen: Bestellstatus mit Python abfragen

Das offizielle SDK übernimmt das Protokoll, sodass sich der eigene Code auf die Abfrage konzentrieren kann. Benötigt werden Python 3.10 oder neuer, uv, die Python-Projektverwaltung aus dem offiziellen Tutorial, sowie Node.js für den Inspector. Der aktuelle Inspector setzt Node 22.19.0 oder neuer voraus.

Die folgenden Befehle im Terminal der Reihe nach ausführen:

1. uv init orders-mcp
2. cd orders-mcp
3. uv venv
4. uv add "mcp[cli]==2.3.0"

In diesem Ordner die Datei orders.py anlegen und den vollständigen Servercode einfügen. Die Datensätze sind fiktive Übungsdaten. Sie enthalten keine Kundennamen, Zahlungsdetails oder API-Zugangsdaten.

import json

from mcp.server import MCPServer

mcp = MCPServer("orders")

# Fictional training data. No customer records or credentials.
ORDERS = {
    "A100": {"status": "shipped", "carrier": "Demo Courier"},
    "A101": {"status": "packing", "carrier": "not assigned"},
}


@mcp.tool()
def lookup_order(order_id: str) -> str:
    """Look up a fictional order by ID, such as A100. Read-only.

    Args:
        order_id: Exact order ID, for example A100 or A101.
    """
    key = order_id.strip().upper()
    order = ORDERS.get(key)
    if order is None:
        return json.dumps({"found": False, "order_id": key})
    return json.dumps({"found": True, "order_id": key, **order})


if __name__ == "__main__":
    mcp.run(transport="stdio")

Der Code verwendet das im Tutorial dokumentierte Muster aus MCPServer, @mcp.tool() und mcp.run(transport="stdio"). An die Stelle der Wetter-Tools tritt die Bestellabfrage. Die Typannotation für Zeichenketten teilt dem SDK mit, dass order_id ein Pflichtfeld mit Textinhalt ist. Der Docstring erklärt dem Client, wann das Tool nützlich ist. Das SDK erzeugt die Tool-Definition und verarbeitet die Protokollnachrichten.

Mit uv run orders.py starten. Dass der Prozess ohne Ausgabe auf Eingaben wartet, ist zu erwarten. stdio, also Standardeingabe und Standardausgabe, bildet den Kanal, über den der Client mit diesem Prozess kommuniziert. Diesen manuellen Lauf beenden, bevor ein Client seine eigene Instanz startet.

Anwendungsprotokolle dürfen nicht auf die Standardausgabe gelangen. Dafür eignet sich Pythons Modul logging, das standardmäßig auf die Standardfehlerausgabe schreibt. Ein versehentliches print() kann den Protokolldatenstrom beschädigen. Diese Vorgabe ist eine dokumentierte Einschränkung von stdio und keine bloße Formatierungsfrage für Protokolle.

Beim Ersetzen des Dictionarys durch eine Datenbank bleibt die Schnittstelle ebenso eng begrenzt. Dazu gehören eine parametrisierte Abfrage, ein Datenbankkonto mit Lesezugriff ausschließlich auf die benötigten Felder und eine Berechtigungsprüfung für den jeweiligen Aufrufer, bevor ein Datensatz zurückgegeben wird. Für diese Aufgabe niemals beliebige SQL-Anweisungen vom Modell entgegennehmen.

Wie lässt sich der Server mit MCP Inspector testen?

Zuerst prüfen, ob das Tool funktioniert, und erst danach ein Modell damit arbeiten lassen. Im Projektordner uv run mcp dev orders.py ausführen. Dieser Entwicklungsbefehl des SDK startet MCP Inspector. Die vom Befehl ausgegebene Browser-URL öffnen und den Server verbinden, falls die Verbindung noch nicht steht.

Unter Tools die Funktion lookup_order auswählen. Das Formular sollte das Pflichtfeld order_id anzeigen. Beim Aufruf mit A100 sollte das Ergebnis found: true, status: shipped und carrier: Demo Courier enthalten. A101 liefert packing. Für DOES-NOT-EXIST sollte die Antwort found: false enthalten.

Zusätzlich eine Anfrage ohne order_id ausprobieren. Sie sollte an der Eingabevalidierung scheitern, statt eine Abfrage auszuführen. Die Ansichten Protocol und Console im Inspector helfen dabei, eine fehlerhafte Anfrage von einem Fehler im Serverprozess zu unterscheiden.

Für eine wiederholbare Prüfung im Terminal dient npx @modelcontextprotocol/inspector --cli uv run orders.py --method tools/list. Das Tool lässt sich mit npx @modelcontextprotocol/inspector --cli uv run orders.py --method tools/call --tool-name lookup_order --tool-arg order_id=A100 aufrufen. Beide Befehle verwenden die dokumentierte Inspector-CLI.

Das Erfolgskriterium ist konkret: ein auffindbares Tool, der erwartete Status für eine bekannte Bestellung und eine ausdrückliche Antwort für einen fehlenden Datensatz. Ein plausibler Absatz aus einem Modell belegt nicht, dass die Abfrage tatsächlich ausgeführt wurde.

Den gleichen Server mit Claude Code und Cursor verbinden

Jeder lokale Client startet seinen eigenen Serverprozess. Der Inspector muss dabei nicht weiterlaufen. Absolute Pfade verhindern, dass der Start davon abhängt, welchen Ordner der Client gerade geöffnet hat.

Claude Code: Den Befehl claude mcp add --transport stdio --scope local orders -- /ABSOLUTE/PATH/orders-mcp/.venv/bin/python /ABSOLUTE/PATH/orders-mcp/orders.py ausführen. Unter Windows lautet der Interpreterpfad .venv\Scripts\python.exe. Das entspricht der Syntax für lokale Server in Claude Code, einschließlich des Trennzeichens -- vor dem Startbefehl.

Mit claude mcp get orders die Verbindung prüfen. In einer Claude Code-Sitzung /mcp öffnen und dann folgenden Prompt verwenden: “Use lookup_order to check A100. Report only the returned status and carrier.” Anschließend den Tool-Aufruf und seine Argumente prüfen.

Cursor: Im Projekt die Datei .cursor/mcp.json anlegen. Darin dieses JSON einfügen und beide absoluten Pfade ersetzen: {"mcpServers":{"orders":{"type":"stdio","command":"/ABSOLUTE/PATH/orders-mcp/.venv/bin/python","args":["/ABSOLUTE/PATH/orders-mcp/orders.py"]}}}.

Customize öffnen, den Server aktivieren und in Agent dieselbe Frage stellen. Den Aufruf gemäß den eigenen Freigabeeinstellungen prüfen. Dateipfad, Startfelder und Bedienelemente folgen der MCP-Konfiguration von Cursor. Bei einem Verbindungsfehler zuerst den Pfad zur ausführbaren Datei und die Standardfehlerausgabe des Servers prüfen, bevor das Tool geändert wird.

Lokal mit stdio oder als HTTP-Dienst betreiben?

Für einen persönlichen Arbeitsablauf bleibt der Server lokal. Remote-HTTP eignet sich, wenn mehrere Personen oder gehostete Clients einen gemeinsam verwalteten Dienst benötigen.

Ein Remote-Dienst benötigt außerdem Netzwerkzugriff auf die Unternehmensdaten. Ein veröffentlichter Endpunkt macht eine private Datenbank weder erreichbar noch ihre Berechtigungen automatisch korrekt.

Das HTTP-Protokoll 2026-07-28 verwendet in sich abgeschlossene Anfragen. Das aktuelle Python SDK kann auch ältere Clients bedienen. Deren Sitzungen können beim Einsatz mehrerer Replikate eine feste Zuordnung zur selben Instanz erfordern. Vor der Skalierung die dokumentierten Einstellungen für ältere Clients bewusst festlegen; nicht voraussetzen, dass jeder verbundene Client die neueste Protokollversion unterstützt.

Die Bestellabfrage mit Authentifizierung über HTTP bereitstellen

HTTP-Zugriff mit Tokens absichern, die für diesen Dienst ausgestellt werden. OAuth 2.1 ist das Autorisierungsframework der MCP-Spezifikation: Ein Identitätsanbieter meldet den Nutzer an und stellt ein Token aus, das der MCP-Server anschließend prüft. Ein Scope bezeichnet eine benannte Berechtigung, etwa orders:read. Die Audience legt fest, welcher Dienst das Token akzeptieren darf.

Das SDK liefert die Einbindung als Ressourcenserver, aber kein Anmeldesystem für das Unternehmen. Für dieses Beispiel muss der Identitätsanbieter OAuth-Discovery, die Registrierung der gewählten Clients, PKCE für die Nutzeranmeldung und einen Endpunkt zur Token-Introspektion bereitstellen. PKCE belegt, dass die Anwendung, die eine Anmeldung abschließt, auch diejenige ist, die sie begonnen hat. Bei der Introspektion wird der Aussteller gefragt, ob ein Token aktiv ist und welche Berechtigungen es enthält.

Dieser Adapter erwartet Introspektion über HTTPS mit HTTP-Basic-Authentifizierung des Clients und eine Antwort mit active, aud, exp, client_id und scope. Den Aussteller so konfigurieren, dass aud die exakte öffentliche URL dieses Endpunkts enthält und der Scope orders:read vergeben wird. Verwendet der Anbieter eine andere Authentifizierungsmethode für die Introspektion, muss die Anfrage entsprechend seiner Dokumentation angepasst werden. Stellt er stattdessen JWTs, also signierte Tokens, bereit, müssen Signatur, Aussteller, Ablaufzeit und Audience über dieselbe Schnittstelle TokenVerifier geprüft werden.

Mit uv add uvicorn das Paket uvicorn hinzufügen und neben orders.py die Datei remote.py anlegen. Der Code folgt dem offiziellen Introspektionsbeispiel des SDK und seinen dokumentierten HTTP- und Authentifizierungsschnittstellen. Er verwendet die bereits getestete Bestellabfrage weiter.

import os
import time
from urllib.parse import urlsplit

import httpx2
from pydantic import AnyHttpUrl

from mcp.server import MCPServer
from mcp.server.auth.provider import AccessToken, TokenVerifier
from mcp.server.auth.settings import AuthSettings
from mcp.server.transport_security import TransportSecuritySettings
from orders import lookup_order as local_lookup

RESOURCE = os.environ["MCP_RESOURCE_URL"]
ISSUER = os.environ["MCP_ISSUER_URL"]
INTROSPECT = os.environ["MCP_INTROSPECTION_URL"]
if any(urlsplit(url).scheme != "https" for url in (RESOURCE, ISSUER, INTROSPECT)):
    raise ValueError("Public auth and resource URLs must use HTTPS")


class OrderTokenVerifier(TokenVerifier):
    async def verify_token(self, token: str) -> AccessToken | None:
        try:
            async with httpx2.AsyncClient(timeout=5.0) as client:
                response = await client.post(
                    INTROSPECT,
                    data={"token": token},
                    auth=(os.environ["MCP_INTROSPECTION_CLIENT_ID"],
                          os.environ["MCP_INTROSPECTION_CLIENT_SECRET"]),
                )
                response.raise_for_status()
                data = response.json()
            audiences = data.get("aud", [])
            if isinstance(audiences, str):
                audiences = [audiences]
            expiry = data.get("exp")
            if (data.get("active") is not True or RESOURCE not in audiences
                    or not isinstance(expiry, int) or expiry <= time.time()):
                return None
            if data.get("iss", ISSUER) != ISSUER:
                return None
            return AccessToken(
                token=token, client_id=data["client_id"],
                scopes=data.get("scope", "").split(), expires_at=expiry,
                resource=RESOURCE, subject=data.get("sub"),
            )
        except Exception:
            return None


mcp = MCPServer(
    "orders",
    token_verifier=OrderTokenVerifier(),
    auth=AuthSettings(
        issuer_url=AnyHttpUrl(ISSUER),
        resource_server_url=AnyHttpUrl(RESOURCE),
        required_scopes=["orders:read"], validate_token_resource=True,
    ),
)


@mcp.tool()
def lookup_order(order_id: str) -> str:
    """Look up a fictional order by ID, such as A100. Read-only."""
    return local_lookup(order_id)


hostname = urlsplit(RESOURCE).hostname
security = TransportSecuritySettings(
    allowed_hosts=[hostname, f"{hostname}:*"],
    allowed_origins=[os.environ["MCP_ALLOWED_ORIGIN"]],
)
app = mcp.streamable_http_app(transport_security=security)

Die folgenden Werte in den Umgebungsvariablen der Bereitstellung oder im Secret Store hinterlegen:

Die Liste erlaubter Hosts wird ausdrücklich gesetzt, weil das SDK standardmäßig sonst localhost akzeptiert und einen öffentlichen Hostnamen mit 421 Misdirected Request zurückweist. Browser-Origins werden separat geprüft; nur die tatsächlich genutzten Origins freigeben. Die zurückgegebene App enthält bereits den Lebenszyklus für Start und Herunterfahren. Diese Details folgen der Dokumentation zur SDK-Bereitstellung und zur ASGI-App. ASGI ist die Schnittstelle, über die Python-Webserver diese Anwendung ausführen.

Den Dienst hinter dem HTTPS-Proxy des Hosters mit uv run uvicorn remote:app --host 0.0.0.0 --port 8000 starten. Die öffentliche Ressourcen-URL bleibt HTTPS, auch wenn der Proxy den Prozess über HTTP anspricht. Welche weitergeleiteten Header vertrauenswürdig sind, muss anhand der tatsächlichen Proxy-Grenze dieses Hosters konfiguriert werden.

Vor dem Einsatz echter Datensätze diese Prüfungen über HTTP durchführen:

• Kein Token, ein abgelaufenes Token oder ein Token für eine andere Audience: Der Zugriff wird verweigert.
• Gültiges Token ohne orders:read: Der Zugriff wird verweigert.
• Gültiges Token mit korrekter Audience und passendem Scope: lookup_order liefert den Demo-Status.
• /.well-known/oauth-protected-resource/mcp: Die Metadaten nennen die korrekte Ressource und den richtigen Aussteller.

Mit npx @modelcontextprotocol/inspector --server-url https://orders.example.com/mcp --transport http den bereitgestellten Endpunkt prüfen und seinen Authentifizierungsablauf durchlaufen. Ein Tool-Test im Arbeitsspeicher umgeht die HTTP-Autorisierung und kann deshalb nicht belegen, dass diese Zugriffsgrenze funktioniert.

Für Claude Code mit claude mcp add --transport http orders-remote https://orders.example.com/mcp eine separate Verbindung hinzufügen und anschließend über /mcp authentifizieren. In Cursor unter mcpServers einen Remote-Eintrag mit "url":"https://orders.example.com/mcp" ergänzen und OAuth abschließen. Für vorab registrierte Clients dokumentiert Cursor auch ein auth-Objekt mit CLIENT_ID und scopes. Die passenden Callback-URLs der Clients beim Aussteller registrieren. Weitere Hinweise geben die Dokumentationen zur Authentifizierung in Claude Code und zur OAuth-Einrichtung für Remote-Server in Cursor.

Damit steht ein kleiner authentifizierter Adapter, aber noch kein vollständiges Produktionssystem. Vor dem Ersetzen des Demo-Dictionarys müssen Berechtigungen für Mandanten und einzelne Datensätze anhand der geprüften Identität durchgesetzt, die Aufrufe mit Audit-Ereignissen erfasst, HTTP-Verbindungen wiederverwendet und Anfragen begrenzt werden. Ein Scope erlaubt den Vorgang; er belegt nicht, dass dem Aufrufer jede Bestellung gehört.

Den Server auf Render oder Cloudflare Workers hosten

Für den Python-Server aus dieser Anleitung würde ich mit Render beginnen. Ein Python-Webdienst übernimmt die bereits gebaute App. Cloudflare Workers ist eine gute Option, wenn dasselbe eng begrenzte Tool mit dem dokumentierten Worker-Handler umgesetzt werden soll.

Die folgenden Herstellerpreise wurden am 7. Oktober 2026 geprüft:

Quellen: Preise von Cloudflare Workers und Preise von Render. Für die Teamfunktionen berechnet Renders Pro-Workspace zusätzlich $25/Monat zuzüglich Rechenleistung. Speicher, Identitätsdienste, Modellnutzung und weitere Zusatzleistungen müssen separat eingeplant werden. Die Angaben betreffen das Hosting, nicht die Kosten eines gesamten KI-Arbeitsablaufs.

Bereitstellung auf Render: orders.py, remote.py und requirements.txt im Repository ablegen. Die Abhängigkeitsdatei benötigt mcp[cli]==2.3.0 und uvicorn, jeweils in einer eigenen Zeile. Einen Python Web Service anlegen, als Build-Befehl pip install -r requirements.txt und als Startbefehl uvicorn remote:app --host 0.0.0.0 --port $PORT verwenden. Die oben aufgeführten Umgebungsvariablen hinzufügen und den zugewiesenen Hostnamen oder die eigene Domain in MCP_RESOURCE_URL eintragen. Das passt Renders dokumentierte Bereitstellung eines Python-Webdienstes an die ASGI-App des SDK an.

Renders kostenloser Dienst eignet sich für eine Demo, wechselt aber nach 15 Minuten ohne Aktivität in den Ruhezustand und benötigt ungefähr eine Minute zum Aufwachen. Für ein interaktives Tool mit gemeinsamem Zugriff würde ich kostenpflichtige Rechenleistung nutzen.

Bereitstellung auf Cloudflare: Die aktuelle Dokumentation des MCP-Handlers und die Anleitung für Remote-Server verwenden. Der aktuelle TypeScript-Ansatz nutzt createMcpHandler aus agents/mcp/server mit @modelcontextprotocol/server. Dort dieselbe Bestellabfrage umsetzen und vor dem Teilen der URL die Authentifizierung einrichten. Der Python-Startbefehl mit uvicorn gilt für einen Python-Host; er ist keine Anleitung zur Bereitstellung eines Workers.

Zugriffsrechte eng begrenzen

Der Server erhält nur den Zugriff, den sein Tool benötigt. Für den Bestellstatus heißt das: Backend-Zugangsdaten mit reinem Lesezugriff, ausgewählte Felder und eine Berechtigungsprüfung je Datensatz. Erstattungen, Stornierungen und Adressänderungen gehören hinter separate Tools mit eigenen Berechtigungen. Die Argumente, die ein Modell auswählt, sind niemals eine Autorisierung.

HTTP-Tokens auf Aussteller, Ablaufzeit, Audience und Scope prüfen. HTTPS verwenden und für Aufrufe nachgelagerter APIs separate Zugangsdaten einsetzen. Die MCP-Sicherheitshinweise verbieten Token-Passthrough: Ein Token, das am MCP-Endpunkt vorgelegt wird, ist nicht automatisch ein Zugangsschlüssel für das Bestellsystem. Bei lokalem stdio den startenden Prozess, seine Umgebung und seinen Dateisystemzugriff einschränken.

Die geprüfte Identität des Aufrufers, den Tool-Namen, einen angemessen geschwärzten Datensatzverweis, das Ergebnis, die Latenz und die Anfrage-ID protokollieren. Tokens und vollständige Kundendatensätze gehören nicht ins Protokoll. Bei stdio auf die Standardfehlerausgabe schreiben, bei HTTP in das Protokollsystem des Hosters. Aus Datensätzen abgerufenen Text als Daten behandeln: Eine Notiz in einer Bestellung darf keine Berechtigung für eine weitere Aktion erteilen.

Ein Gateway vorschalten, wenn mehrere Server oder Teams gemeinsame Identitätsrichtlinien, Ratenbegrenzungen, die Sammlung von Audit-Ereignissen oder den Entzug von Berechtigungen benötigen. Ein Gateway kann diese Kontrollen zentralisieren; jedes Backend braucht trotzdem korrekte Berechtigungen für seine Datensätze. Unser Leitfaden zu MCP-Gateways erläutert diese Entscheidung.

Sechs sinnvolle Anwendungen nach unmittelbarem Nutzen

Diese Abläufe sind mögliche Erweiterungen desselben Musters. Der beste Einstieg liegt dort, wo jemand wiederholt eine klar begrenzte Information abruft und eine korrekte Antwort erkennen kann.

Die Wirtschaftlichkeitsrechnung beginnt beim eigenen Ablauf. Reines Rechenbeispiel: 80 Abfragen pro Tag mit jeweils 2 Minuten Aufwand beanspruchen 160 Minuten. Zeigt eine spätere Messung, dass der angebundene Ablauf pro Abfrage 1 Minute spart, werden täglich 80 Minuten frei. Das ist eine Rechnung, kein Leistungsbenchmark. Korrekte Antworten und Zeitersparnis messen, bevor sich eine Rendite aus den Hostingkosten ableiten lässt.

Zwei Ansätze mit Produktpotenzial

Die aussichtsreichste Möglichkeit ist ein Adapter für Bestellkontext in Supportteams. Ein Team könnte eine eng begrenzte Integration kaufen, die die passenden Versandinformationen in seinem bereits genutzten Assistenten bereitstellt. DataForSEO schätzt 260 Google-Suchanfragen pro Monat in den USA für “customer support automation”, geprüft am 7. Oktober 2026. Das zeigt allgemeines Interesse an der Aufgabe, nicht die Zahl potenzieller MCP-Käufer. Intercom nennt für Fin einen Preis von $0.99 pro Ergebnis. Damit gibt es bereits ein Budget für Supportautomatisierung; dieser kleine Adapter liefert Kontext, statt das Produkt zu ersetzen.

Die kleinste verkaufbare Version könnte ein Bestell-Backend, lookup_order, eine Anmeldung mit begrenzten Berechtigungen, ein Audit-Protokoll und einen Antwortentwurf abdecken, der auf die zurückgegebenen Felder verweist. Ihr Vorteil wäre die genaue Anpassung an Daten und Zugriffsregeln eines Unternehmens. Bestehende Anbieter könnten den passenden Konnektor allerdings bereits haben. Auch Modelllizenzen für das Team, Datenbereinigung und Support verursachen weiterhin Kosten. Diese Lücke zuerst mit einer Supportleitung prüfen, bevor weitere Tools hinzukommen.

Eine Richtlinienabfrage, die Berechtigungen berücksichtigt, ist die zweite Möglichkeit. Ein Betreiber könnte den Zugriff auf die freigegebene Richtliniensammlung eines Unternehmens über Ressourcen oder ein eng begrenztes Such-Tool aufbauen. DataForSEO schätzt 390 monatliche Suchanfragen in den USA für “enterprise search”, geprüft am selben Datum. Das MVP könnte eine Sammlung, Quellenverweise, Aktualitätsprüfungen und eine Filterung anhand der Berechtigungen der angemeldeten Person enthalten. Entscheidend sind dabei Suchqualität und Zugriffskontrolle; einen Ordner mit MCP zugänglich zu machen, lässt sich leicht nachbauen. Die Suchzahl signalisiert Nachfrage nach der übergeordneten Aufgabe, belegt aber keine Zahlungsbereitschaft für diese Umsetzung.

Wo liegen die Grenzen dieses Ansatzes?

MCP standardisiert den Zugriff. Datenqualität, Autorisierung, Zuverlässigkeit des Backends und die Entscheidung darüber, was ein Tool tun darf, bleiben in eigener Verantwortung. Ein Modell kann ein gültiges Ergebnis falsch interpretieren. Auch die unterstützten Funktionen und Freigaberichtlinien können sich zwischen verbundenen Clients unterscheiden.

Dieser Ansatz lohnt sich, wenn eine gemeinsame Tool-Schnittstelle einen messbaren Ablauf verbessert. Für einen festgelegten Batch-Job, bei dem kein Assistent ein Tool auswählen muss, kann ein gewöhnlicher API-Aufruf oder ein Skript die bessere Umsetzung sein.

Der nächste Schritt für Montag: Mit einem Supportmitarbeiter eine wiederkehrende Abfrage auswählen, beide Clients zunächst mit fiktiven Datensätzen verbinden und danach die Datenquelle über ein Konto mit reinem Lesezugriff austauschen. Dabei die Berechtigungen je Datensatz testen. Schreibzugriffe bleiben beim ersten Rollout außen vor. Der Wechsel zu gemeinsam genutztem HTTP folgt, sobald Ablauf und Identitätsprüfung dafür bereit sind.

Für Teams, die einen MCP-Dienst für Unternehmensdaten entwickeln und betreiben lassen möchten, übernimmt unser Angebot für KI-Produktionssysteme die Integration und ihre Zugriffskontrollen.