Implementierung eines MCP-Servers

Ein MCP-Server beginnt oft mit einer scheinbar einfachen Anforderung: Ein KI-Host soll Tickets zu einem Thema finden und zusammenfassen. Sobald dafür aktuelle Daten aus einem Fachsystem in den Modellkontext gelangen, reicht die Frage nach dem Endpoint nicht mehr aus. Entscheidend ist, welche Daten sichtbar werden, unter wessen Rechten gesucht wird und welche Aktionen der Server überhaupt zulassen darf.

Das war der Ausgangspunkt bei Lutions. Die Architekturfrage war schon vor dem ersten produktiven Tool klar: Der MCP-Server darf weder eine zweite offene Produkt-API noch eine autonome Agentenschicht werden. Der erste Teil dieser Reihe erklärt den Weg zwischen Host, Modell, MCP-Server und Fachsystem (Hermanns, 2026). Der folgende Text zeigt, wie diese Architekturentscheidung im Zugriffskonzept, in den Berechtigungen und im Betrieb konkret umgesetzt wurde.

Kurz zur Einordnung: Der Host ist die KI-Anwendung, die eine Nutzerfrage und erlaubte MCP-Fähigkeiten an ein Modell weitergibt. Der MCP-Server liefert daraufhin begrenzten Kontext oder führt eine erlaubte Fachoperation aus; er beantwortet die Nutzerfrage nicht selbst.

Erst den Zugriff schneiden, dann Funktionen ergänzen

MCP trennt Resources, Prompts und Tools. Tools sind dabei Funktionen, die ein Modell über den Host anfordern kann; Resources und Prompts haben andere Aufgaben im Kontextaufbau. Die aktuelle Spezifikation ordnet diese Server-Fähigkeiten ausdrücklich getrennt ein und behandelt Tools als sicherheitsrelevante, modellgesteuerte Schnittstelle (Model Context Protocol, 2026a; Model Context Protocol, 2026b).

In unserem Fall haben wir daraus eine einfache Entscheidung abgeleitet: Der produktive Kern beginnt mit sechs lesenden Tools. Sie suchen sichtbare Tickets, laden einzelne oder mehrere Tickets und geben begrenzte Kommentare, Verknüpfungen oder ein kompaktes Kontext-Bundle zurück. Der Server beschreibt sich selbst entsprechend als Read-only-Zugang und die Statussicht führt diese sechs Tools ebenfalls als read-only (Lutions, 2026a; Lutions, 2026b).

Dieser Schnitt reduziert mehrere Unsicherheiten zugleich. Ein lesendes Tool kann immer noch sensible Informationen berühren; es braucht daher dieselben Sichtbarkeits- und Projektgrenzen wie die Anwendung selbst. Es verändert aber weder Workflow noch Zuständigkeiten, Prioritäten oder Außenwirkung eines Tickets. Dadurch bleibt die erste Sicherheitsfrage überschaubar: Darf dieser Token diese Information sehen – und darf genau diese Information in den Kontext des Hosts gelangen?

Die beschränkte Tooloberfläche hilft auch dem Modell. Sie ist kein Sicherheitsmechanismus für sich; Toolbeschreibungen sind keine Autorisierungsentscheidung. Aber sie verringert Fehlbedienung und ermöglicht, Toollisten enger am tatsächlichen Berechtigungskontext auszurichten (Model Context Protocol, 2026b).

Ein Tool konkret: Suche statt Freitextzugriff

Der Sicherheitsgewinn liegt nicht nur in der Anzahl der Tools, sondern im Vertrag jedes einzelnen.  search_zockets  akzeptiert beispielsweise keinen universellen Befehl, sondern einen begrenzten Suchtext, einen Resultat-Limitwert zwischen 1 und 50 sowie optionale Fachfilter. Der folgende Ausschnitt ist eine vereinfachte, lesbare Fassung des serverseitigen Schemas:

{
  "name": "search_zockets",
  "readOnly": true,
  "input": {
    "query": "string, maximal 200 Zeichen",
    "limit": "integer, 1 bis 50, Standard 10",
    "status": "optional",
    "priority": "optional",
    "type": "optional",
    "projectKey": "optional"
  }
}

Das Schema ersetzt keine Autorisierung. Es verhindert aber, dass aus der Suche ein verdecktes „Führe beliebigen Zugriff aus“ wird. Die serverseitige Validierung und der Nutzerkontext entscheiden weiterhin, welche Treffer überhaupt zurückgegeben werden können (Lutions, 2026a).

Was daraus bei einer Anfrage wird

Ein Anwender fragt zum Beispiel nach offenen Risiken und Entscheidungen zu einem Thema. Der Host sucht zunächst mit  search_zockets  nach sichtbaren Kandidaten. Erst danach lädt er mit  get_zocket_context_bundle  eine begrenzte Auswahl von Tickets, optionalen sichtbaren Kommentaren und Links. Die Antwort des Modells entsteht erst aus diesem begrenzten Material.

Die Recherche folgt einer klaren Abfolge: erst suchen, dann gezielt Kontext abrufen, anschließend antworten. Er verhindert nicht, dass ein Modell Inhalte missversteht. Aber er verhindert, dass die Anfrage mit einem ungebundenen Zugriff auf alle Tickets oder einem pauschalen Volltext-Export beginnt. Für mich liegt darin der erste praktische Nutzen des Read-Kerns: Aktuelle Ticketinformationen werden für eine Analyse erreichbar, ohne die Recherchegrenze und die Fachrechte aufzugeben (Lutions, 2026c).

Rechte bleiben im Fachsystem

Ein MCP-Zugang schafft keinen eigenen Vertrauensraum. Er darf einem KI-Host keine Tickets oder Informationen eröffnen, die der zugehörige Nutzer in Lutions nicht selbst sehen dürfte. Unser Endpoint verwendet deshalb die bestehende API-Token-Authentifizierung. Für lesenden Zugriff ist issues:read die fachliche Basis. mcp:connect markiert zusätzlich den MCP-Zugang und kann nach dem dokumentierten Migrationspfad verbindlich durchgesetzt werden. Projektgebundene Tokens bleiben auch über MCP auf ihre erlaubten Projekte begrenzt; der Endpoint wird außerdem separat rate-limitiert (Lutions, 2026c).

Der MCP-Server erfindet kein eigenes Berechtigungsmodell. Er übersetzt eine Anfrage in eine Fachoperation und muss dabei dieselben Grenzen respektieren, die auch außerhalb von MCP gelten. Das entspricht einer Kernforderung der MCP-Sicherheitsprinzipien: Datenzugriff und Aktionen brauchen wirksame Zugriffskontrollen, und das Protokoll erzwingt diese Architektur nicht selbst (Model Context Protocol, 2026a).

Audit soll erklären, nicht mitschreiben

Bei Toolaufrufen entsteht schnell der Wunsch, möglichst alles zu protokollieren. Bei einem Ticketsystem wäre das der falsche Reflex. Vollständige Argumente, Ticketbeschreibungen, Kommentartexte und Ergebnis-Payloads würden das Audit in eine zweite, schwer kontrollierbare Kopie fachlicher Inhalte verwandeln.

In Lutions wird ein Toolaufruf daher als mcp.tool_called erfasst. Das Audit hält technische Metadaten fest: Toolname, Methode, Status, Laufzeit, Actor- und Tokenkontext, Projektkontext, Ergebnisanzahl und gegebenenfalls einen Fehlercode. Vollständige Argumente und fachliche Payloads gehören ausdrücklich nicht hinein. Die MCP-Statussicht nutzt genau diese Metadaten für Betriebssicht und Aggregationen (Lutions, 2026c; Lutions, 2026d).

Diese Form der Beobachtbarkeit beantwortet nicht jede Sicherheitsfrage. Sie zeigt aber, ob und wie ein Tool genutzt wurde, ohne den Inhalt einer Ticketanalyse selbst zu vervielfältigen. Für mich ist das ein brauchbarer Ausgleich: genug Evidenz für Fehleranalyse, Rate-Limit- und Missbrauchssignale; zu wenig Inhalt, um das Audit zur Schattenakte zu machen.

Der Punkt ist über Lutions hinaus übertragbar. Bei MCP geht es nicht nur darum, was der Server ausführen darf. Ebenso wichtig ist, welche Spuren ein Toolaufruf hinterlässt und wer diese später lesen kann. Sicherheitsrelevante Beobachtbarkeit beginnt daher mit einer Datenminimierungsentscheidung.

Warum Lutions derzeit Read-only bleibt

Der aktive Lutions-MCP-Vertrag ist derzeit Read-only. Write-Tools gehören nicht zum produktiven Toolinventar. Frühere Überlegungen und Pilotverträge für schreibende Aktionen bleiben bewusst Konzept- und Folgearbeit, nicht eine stillschweigende Freigabe im laufenden Betrieb.

Ein lesendes Tool liefert Kontext, ein schreibendes Tool erzeugt Wirkung. Deshalb ist ein Kommentar, eine Verknüpfung oder ein Statuswechsel kein bloßer nächster Tooltyp. Die konkrete Freigabegrenze bleibt Verantwortung von Fachsystem und Host; MCP schreibt dafür kein bestimmtes Interaktionsmodell vor (Model Context Protocol, 2026b).

Die folgende Einordnung markiert die aktive Grenze: Read-only ist der heutige MCP-Umfang. Weitergehende Aktionen sind keine angebotenen Tools, sondern brauchen jeweils einen eigenen Vertrag.

Wirkungsklasse	Beispiel	Status im MCP-Zugang
Read-only	Suche, Ticket lesen, Kommentare lesen	aktiv, mit Read-Scope
Schreibende Fachaktionen	interner Kommentar, Verknüpfung, Statuswechsel	kein aktives MCP-Tool; nur mit separatem, serverseitig abgesichertem Vertrag denkbar
Hochrisikoaktionen	Admin-, Sichtbarkeits- oder destruktive Aktionen	für den MCP-/Agentenprozess blockiert oder eigener High-Risk-Prozess

Für mögliche spätere Write-Fälle beschreibt die Dokumentation einen serverseitigen Ablauf aus Preview, menschlicher Approval-Entscheidung und Execute mit kurzer Gültigkeit, unverändertem Payload, Idempotenz und Audit-Korrelation. Er ist eine Architekturgrenze für spätere Entscheidungen, keine versteckte Freigabe im heutigen Betrieb.

Was der aktuelle Stand kann – und was nicht

Der bestehende Kern macht aktuelle, sichtbare Ticketinformationen über eine begrenzte Toolkette zugänglich. Er kann Suchergebnisse, Ticketdetails, begrenzte Kommentare und Links für eine Analyse bereitstellen; die Statussicht und das Audit machen die technischen Toolaufrufe nachvollziehbar.

Er beweist dagegen nicht, dass ein KI-Host jede Anfrage richtig zerlegt, die beste Toolreihenfolge wählt oder aus Ticketdaten stets zuverlässige Bewertungen ableitet. Ebenso wenig folgt aus einer funktionierenden Read-Integration, dass schreibende Agenten produktiv vertretbar wären. Für riskantere Wirkungsklassen fehlen weiterhin die allgemeinen Runtime-Grenzen für Preview, Approval und Execute.

Das ist kein Makel neben der Architektur. Es bestimmt den nächsten Evaluationsschritt: Welche Hosts arbeiten mit den begrenzten Ergebnissen tatsächlich gut? Welche Datenmenge hilft einer Ticketanalyse, ohne Kontext zu überladen? Und wann erhöht eine weitere Fähigkeit den Nutzen stärker als Kosten, Angriffsfläche und Erklärungsbedarf?

Ein konkreter Modellbefund

Die beiden folgenden Screenshots zeigen einen bewusst kleinen, aber vollständigen Testfall. Die Frage ist auf Deutsch formuliert und benennt eine bekannte Ticketreferenz: Das Modell soll den Inhalt kurz zusammenfassen. Damit wird weder eine offene Recherche noch eine komplexe Agentenaufgabe getestet, sondern die Frage, ob ein lokaler Host eine konkrete Fachinformation über MCP kontrolliert abrufen und verständlich wiedergeben kann.

Teststeckbrief. 

• Host: LM Studio, das MCP-Server als Host einbinden kann (LM Studio, 2026).
• Modellkennung: google/gemma-4-e4b aus der Gemma-4-Familie (Gemma Team, 2026).
• Aufgabe: ein bekanntes Lutions-Ticket auf Deutsch zusammenfassen.
• Erlaubte Fähigkeiten: ausschließlich die sechs Read-only-Tools des Lutions-MCP-Servers.
• Erwarteter Befund: Das Modell wählt für eine bekannte Referenz das Einzelabruf-Tool und die Antwort bleibt inhaltlich beim Ticket. Die Referenz, der Prompt und die Modellkennung sind festgehalten; ein öffentlich reproduzierbarer Lauf mit Hostversion, Zeitstempel und standardisiertem Fragenkatalog ist daraus noch nicht geworden.

Im ersten Screenshot ist die sichtbare Ablaufansicht des lokalen Modells google/gemma-4-e4b in LM Studio zu sehen. Der Host stellt die sechs Read-only-Tools des Lutions-MCP-Servers bereit. Für die bekannte Ticketreferenz entscheidet sich das Modell für get_zocket, nicht für Suche, Batch-Abruf, Kommentare, Links oder das Kontext-Bundle. Der sichtbare Toolaufruf enthält ausschließlich die benötigte Ticketreferenz als issueRef. Direkt darunter erscheint der Aufruf im MCP-Kontext; die Antwortansicht beginnt anschließend mit dem zurückgemeldeten Ticketinhalt. Das ist der relevante technische Befund des ersten Bildes: Das Modell erkennt die passende, eng begrenzte Fachoperation und löst sie aus.

Der zweite Screenshot in Abbildung 4 zeigt die daraus entstandene Antwort. Sie ordnet das Testticket richtig als Übertragung einer LLM-Wiki-Idee auf Lutions ein. Sie trifft dessen Kernpunkt – eine gepflegte, prüfbare Wissensschicht statt eines isolierten Chatbots – und nennt die drei zentralen Aspekte: Knowledge Layer statt Chatbot, Sourcecode als primäre Wahrheit und einen Prozess aus Knowledge Impact Check, Ingest, Test und Knowledge-Status. Der Abgleich mit dem Ticket bestätigt diese Einordnung. Für diesen Fall ist damit die Kette „Frage → passendes Tool → Ticketkontext → sachliche Antwort“ tatsächlich geschlossen.

Der Befund bleibt absichtlich eng. Er zeigt, dass der lokale Modellpfad eine bekannte Referenz korrekt über ein Read-only-Tool abrufen und in eine brauchbare deutsche Antwort überführen kann. Er sagt noch nichts darüber aus, wie zuverlässig Gemma 4 unbekannte Tickets findet, mehrstufig recherchiert, Quellen über mehrere Treffer hinweg abgleicht oder mit unklaren Fragen umgeht. Genau dort beginnt die weiterführende Evaluation von Suchplanung, Kontextzuschnitt und Antwortqualität (Lutions, 2026f).

Fazit

Der hier beschriebene Umsetzungsstand des MCP-Servers zeigt: Ein MCP-Zugang kann sinnvoll nutzbar sein, wenn der Server nicht zum zweiten, unkontrollierten Zugang ins Fachsystem wird. Wie dieser Rahmen aus kleinen Tools, Fachrechten und datensparsamem Audit entsteht, zeigt der Rückblick.

Der dargestellte Testfall mit LM-Studio als KI-Host belegt den Einzelabruf: Gemma 4 wählt get_zocket, erhält begrenzten Ticketkontext und formuliert dazu eine passende Antwort. Davon getrennt zeigen die internen Retrieval-Tests den Mehrticketpfad: Bekannte Referenzen können über get_zocket_context_bundle geladen und quellengebunden zusammengefasst werden. Beides ist kein Qualitätsurteil über jedes Modell und jede Rechercheaufgabe, aber ein praktischer Beleg dafür, dass der kontrollierte Read-Pfad auch außerhalb eines einzelnen Cloud-Hosts nutzbar ist (Lutions, 2026f).

Offen bleibt damit nicht mehr die grundsätzliche Anbindung, sondern ihre Qualität im Einsatz: Wie zuverlässig unterstützen unterschiedliche Modelle Recherche und Analyse? Welche Kontextzuschnitte und Prompt-Formen tragen, wo bleiben Grenzen? Wenn daraus genug belastbare Beobachtungen entstehen, kann diese Praxisperspektive später einen eigenen Beitrag tragen.

Quellenverzeichnis

Externe Primärquellen

• Model Context Protocol (2026a). Specification, Revision 2026-07 28.  https://modelcontextprotocol.io/specification/2026-07-28
• Model Context Protocol (2026b). Tools, Revision 2026-07-28.  https://modelcontextprotocol.io/specification/2026-07-28/server/tools
• LM Studio (2026). Use MCP Servers. https://lmstudio.ai/docs/app/mcp
• Gemma Team (2026). google/gemma-4-E4B: Model Card. https://huggingface.co/google/gemma-4-E4B

Eigene Artikel

• Hermanns, Christoph (2026). MCP-Server: Der offene Standard zwischen KI-Hosts und deinen Systemen

Lutions-Quellen

• Lutions (2026a). MCP-Server und Toolverträge. Interne Entwicklungsquelle.
• Lutions (2026b). MCP-Status- und Auditmodell. Interne Entwicklungsquelle.
• Lutions (2026c). MCP-Betriebs-, Scope- und Rate-Limit-Konzept. Interne Betriebsquelle.
• Lutions (2026d). MCP Observability und Audit. Interne Konzeptquelle.
• Lutions (2026f). MCP Read-Retrieval-Evaluation und lokaler LM-Studio-/Gemma-4-Test. Interne Testauswertung.