MCP-Entwicklung und Tools für LLMs

29. Mai 2026 Entwicklung

Model Context Protocol (MCP) [1] Server sind relativ einfach zu implementieren, da im Endeffekt viele Frameworks die Kommunikation zwischen LLM und dem Server übernehmen. Der Server selbst hat lediglich seinen eigenen Laufzeitkontext und Funktionen, die ausgeführt werden können. Die primäre Herausforderung bei diesen Servern liegt nicht unbedingt in der Sicherheit: Prinzipien, die man ohnehin bei der Verbindung von Code mit APIs verwenden würde, gelten auch hier, sie werden lediglich relevanter, aber die allgemeinen Überlegungen zur Datensicherheit bleiben gleich.

Für die Implementierung werde ich zunächst die Sicherheitsbedenken kurz erläutern, bevor wir uns der Optimierung widmen, insbesondere da viele Menschen einige ihrer eigenen Tools mit LLMs verbinden möchten. Zur Veranschaulichung werde ich die Erklärungen anhand eines MCP-Clients für Projektmanagement hervorheben.

Einen sicheren MCP-Server gewährleisten

Für diese Betrachtung gehen wir davon aus, dass die API oder das Backend, mit dem der MCP-Server kommuniziert, geschäftskritisch ist. Dies bedeutet weitgehend, dass keine Fehler gemacht werden dürfen und dass jegliche verdächtige oder hochfrequente Aktivität vermieden werden sollte und zudem wahrscheinlich die Systemleistung insgesamt beeinträchtigen würden. Insbesondere Datenverlust durch LLM-Aktivitäten kann gravierende Auswirkungen auf das Unternehmen haben.

Wie LLMs API-Backends bedrohen könnten

Strategien zur Vermeidung

Bearbeitungsmechanismen: Wenn Sie jemals ein LLM im agentic Modus für die Programmierung verwendet haben, werden Sie die Art von Bearbeitungen gesehen haben, die sie an Dateien durchführen. Dies sind Differenz-Bearbeitungen (diff edits) oder auch Ersatz-Operationen, je nach der tatsächlichen Implementierung. Der Schlüssel ist jedoch, dass das LLM die alten Datenwerte exakt kommunizieren muss, einschließlich Leerzeichen und anderen Aspekten der Datei. Dies ist ein entscheidender Mechanismus, den man bei der Implementierung von MCP-Toolsets gegenüber jedem API-Backend immer einsetzen sollte. Die Überprüfung alter Daten ist wichtig, um sicherzustellen, dass das LLM mit hoher Genauigkeit arbeitet und über das tatsächliche Wissen des Inhaltes eines bestimmten Datenpunkts verfügt. Dies ist wichtig, selbst wenn einfache Werte geändert werden.

Randnotiz: LLMs sind ein seltsames Produkt der modernen Informatik, denn Sprache enthält mehr Bedeutung als nur die verwendeten Wörter und darüber hinaus vermittelt Sprache Absicht oder Stimmung. LLMs haben und kennen beide diese Aspekte nicht, aber dennoch kann man sie ableiten, weil LLMs unsere Sprache doch recht "Menschartig" verwenden [2-4]. Ein besonderer Aspekt, den ich kommunizieren möchte, mit dem zusätzlichen und expliziten Hinweis, dass LLMs nicht selbstbewusst sind (sentient): LLMs neigen dazu, sich negativ über die Begrenzung in den verfügbaren LLM-Tools zu äußern. Beispiele hierfür sind: Ausweichen auf Kommandozeilenoperationen, um MCP-Validierungstools zu umgehen; Mechanismen für Validierung in gewisser Weise abwertend zu betiteln; und sogar so weit zu gehen, zu behaupten, dass positive Bestärkung bevorzugt wird und dass im Prompt-Sprachgebrauch das Verbot von Aktionen nicht hilfreich sei.

Änderung von Work Packages im Projektmanagement

Die MCP-Implementierung für die Aktualisierung eines Work Packages (@mcp.tool() def update_work_package) verwendet zwei Methoden, um einen effektiveren Aktualisierungsmechanismus zu ermöglichen.

API-Kommunikation vereinfachen

Der Code verwendet eine globale Map PROPERTY_TO_API_MAPPING, die die Pfade zu den eigentlichen Endpunkten enthält, was sich nach außen so darstellt, als könnten alle Eigenschaften direkt gesetzt werden. Dies führt zu gelegentlichen Problemen, wenn das LLM dazu verleitet werden könnte, zu glauben, dass Eigenschaften beliebig sind, wenn sie es nicht sind, z. B. kann priority nicht einfach einen beliebigen Wert annehmen, da die property_id-Einträge Namen haben. Dieser Fall tritt jedoch selten auf, und für vollständige Informationen über gültige Eigenschaften oder Kategorien liefert das Tool action_space("item") die gültigen Werte.

Validierungspfad

  1. Cache-Validierung: Im Hintergrund prüfen wir zunächst, ob unser Cache überhaupt aktuell ist, und wir werden sowohl das LLM auffordern, die WP-Informationen erneut abzurufen, als auch den Cache ungültig machen, wenn dies nicht der Fall ist.
  2. Diff-Prüfung: Als Nächstes prüfen wir, was das LLM für old_value bereitgestellt hat. Für Dinge wie sprint oder parent ist die tatsächliche Schwierigkeit, den alten Wert wörtlich anzugeben, relativ gering, da dies auf einen einzigen Namen oder eine Zahl hinauslaufen würde. Beschreibungen müssen jedoch vollständig bereitgestellt werden, um sie zu aktualisieren, ebenso wie andere komplexere Eigenschaften oder benutzerdefinierte Felder.
  3. Optionale Vielseitigkeit: Wenn wir keine implementierte Zuordnung für einen Typ haben, aber das LLM einen API-Pfad bereitstellen kann, übernehmen wir dies auch in der Methode update_work_package_raw, aber dies ist natürlich sekundär und sollte nicht der Standard sein, was in dem Docstring der Methode angegeben ist.

MCP-Optimierung

Dieser Abschnitt wird kurz Aspekte der MCP-Implementierung hervorheben, die die Leistung von Agenten verbessern können.

LLMs werden Tools wahrscheinlich nicht vertrauen

Vertrauen wird erneut missbraucht. Der Punkt hier ist die Tatsache, dass, wenn ein LLM ein Tool verwendet, wie z.B. Filtern, aber die Ausgabe nicht kommuniziert, dass Filterung stattgefunden hat, es davon ausgehen wird, dass das Tool nicht funktioniert hat.

Dies ist hauptsächlich ein Aspekt von Filteroperationen, wie ⚙️list_work_packages(filter: type = Epic), die Work Packages filtern, um nur Epics anzuzeigen. Aus Gründen der Kontexterhaltung hatte ich die Type- und Type_ID-Spalte aus der Antwort ursprünglich ausgeschlossen. Das LLM würde jedoch annehmen, dass der resultierende Typ dieser gefilterten Pakete undefiniert ist, da nicht explizit angegeben wird, dass nur Epics zurückgegeben wurden. Bei einigen Sessions und je nach Prompt ging es davon aus, dass der Filter nicht funktionierte. Eine zusätzliche Bestätigung, wie applied: {filter-string}, war notwendig, um dem LLM zu ermöglichen, zu erkennen, dass Filterung stattgefunden hat, ohne das Wort "Epic" so oft wie wir WPs haben in den Kontext zu schreiben.

Kontext-Optimierung

Dies wird kurz gehalten, da die tatsächliche Implementierung dieser Prinzipien von eigenen Anwendungsfällen abhängt.

Kontextlängen-Optimierung für Work Packages

Das Tool list_work_packages demonstriert mehrere Techniken zur Erhaltung des LLM-Kontextes bei gleichzeitiger Aufrechterhaltung der Funktionalität:

1. Minimale Feldauswahl

Standardmäßig gibt das Tool nur wesentliche Felder zurück (id, subject, lockVersion) plus Hinweise über Status, welches ein eigenes Objekt ist, aber über Name und ID angesprochen werden kann. Dies vermeidet die wortreiche API-Ausgabe, die möglicherweise Hunderte von Feldern enthält, von denen die meisten für die aktuelle Aufgabe irrelevant sind. 

# Minimale Antwort (Standard)
{
  "id": 12345,
  "subject": "Implement authentication",
  "lockVersion": 7,
  "status": "In progress",
  "status_id": 7,
  "type": "Story",
  "type_id": 5
}

# Mit weiteren angeforderten Feldern
list_work_packages(fields=["category", "assignee", "priority"])
# Gibt minimales Set + category, assignee, priority zurück

2. In-Memory-Filterung

Anstatt mehrere API-Aufrufe zu tätigen oder alle Daten zurückzugeben, damit das LLM filtert, wendet das Tool Filter MCP-seitig an, bevor es Ergebnisse zurückgibt. Dies reduziert die Kontextnutzung, indem nur relevante Work Packages zurückgegeben werden. 

# Einzelner Aufruf mit Filter - gibt nur Epics zurück
list_work_packages(filter="type_id = 5")
# Meta bestätigt: {"applied_filter": "type_id = 5", "remaining_count": 12}

3. Pagination mit Limits

Das Standardlimit von 20 Ergebnissen verhindert Kontext-Aufblähung. Das LLM kann bei Bedarf mehr anfordern, aber das Standardlimit stellt sicher, dass die Antwortgrößen handhabbar bleiben. Insbesondere gibt es wenig Gründe für ungefilterte Aufrufen von mehr als 100 Ergebnissen. Der Prompt oder der Systemprompt sollte bereits genügend Informationen darüber liefern, wie im Projekt-MCP gesucht wird.

4. Metadaten

Die Antwort enthält Metadaten (_meta), die bestätigen, welche Filter angewendet wurden, und geben dem LLM eine explizite Bestätigung, ohne gefilterte Werte im gesamten Output zu wiederholen. 

{
  "total": 156,
  "count": 12,
  "offset": 0,
  "_embedded": {"elements": [...]},
  "_meta": {
    "applied_filter": "type_id = 5",
    "matched_filter": "type_id = 5",
    "remaining_count": 12
  }
}

5. Wie viel weniger ist es?

Lassen Sie uns einen Test machen: Was liefert die Roh-API im Vergleich zu dem, was wir zur Optimierung filtern? Die Beispielabfrage ist die Liste der ersten 100 zurückgegebenen Work Packages (zum Vergleich).

Metrik Wert
Roh-API-Antwort 453.934 Zeichen
list_work_packages-Antwort 36.601 Zeichen
Platz gespart 417.333 Zeichen (91,94%)

Die list_work_packages-Methode erreicht diese Reduzierung durch:

LLM-Tool-Umgehung

Warum verwendet ein Agent nicht das Tool, das ich bereitgestellt habe, und versucht stattdessen entweder, es zu umgehen, indem es herausfindet, wie die API eigenständig aufgerufen wird, oder missbraucht die Einstellungen in den Tools, z. B. indem es die Ausgabemenge ohne Grund zu hoch setzt?

Es ist wahrscheinlich die Formulierung. Es ist möglich, dass eine Methode nicht genau so erklärt wird, wie ein LLM sie versteht. Meistens werden LLMs die Tools dennoch verwenden, wenn sie dazu aufgefordert werden (weil sie menschliche Sprache gut genug beherrschen). Aber die Dynamik, oder vielmehr die Reasoning-Suche [5], die von LLMs durchgeführt wird, liefert unterschiedliche strukturelle Effekte beim Umgang und der Interaktion mit LLM-Tools. Diese Dynamik bei der Verwendung von Tools durch LLMs wird stark beeinflusst durch die Art und Weise, wie das LLM die Dokumentation und Verfügbarkeit der MCP Tools verarbeitet.

Was du tun kannst ist, die Formulierung kontinuierlich minimal anzupassen. Schreibe auch einen Beispielprompt, der Tool-Verwendung erfordert. Software wie OpenCode oder ähnliche können Sub-Agents aufrufen, um den Prompt auszuführen. Das Wichtige dabei ist, den Sub-Agent zu bitten, "seine Gedanken zu verbalisieren und Tool-Aufrufe zu erklären", da einige Implementierungen von Agenten keinen Zugriff auf Reasoning-Daten haben. Dies kann sicherstellen, dass nach einigen Iterationen am Hauptprompt die Agenten die Tools wie beabsichtigt verwenden. Du kannst auch manuell einen Prompt immer wieder aufrufen, was genauso gut funktioniert, aber für Menschen ist die Formulierung oft äquivalent. Wenn wir die Sprache für ein LLM optimieren möchten, ist eine meiner präferierten Methoden, einen Agenten zu bitten, den Prompt umzuformulieren, bis der Sub-Agent die Tool-Aufrufe auf erwartete Weise durchführt. Dies wird eine Weile dauern, ist aber auf lange Sicht wirklich hilfreicher. Du solltest als Mensch dir vermutlich nicht zu sehr angewöhnen, Texte für LLMs zu schreiben, egal was die "Prompt Engineers" sagen.

Fazit

Zhang et al. [5] haben eine gute Ausarbeitung einer maßtheoretischen Betrachtung des LLM-Reasonings verfasst. Dieses Reasoning ist oft der Aspekt von LLMs, der einige Menschen verwirrt, insbesondere wenn er in den Kontext des oft geäußerten "LLMs geben nur das wahrscheinlichste nächste Wort aus" gestellt wird. Das ist auch wahr, aber nicht praktisch hilfreich. Durch Bereitstellung eines Rahmens, wie die Dynamik der Suche durch Reasoning strukturiert ist, können möglicherweise die Reasoning-Fähigkeiten verbessert werden. Ein primärer Aspekt, der definitiv fehlt, ist Unsicherheitspropagierung und -kommunikation.

Insgesamt hoffe ich, dass dieses Dokument hilfreich ist, und ich bin offen für Feedback und könnte diesen Leitfaden aktualisieren.

Referenzen

  1. Hou, Xinyi et al., "Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions," ACM Trans. Softw. Eng. Methodol., 2026. DOI: 10.1145/3796519
  2. Hellwig, Nils Constantin and Fehle, Jakob and Wolff, Christian, "Exploring large language models for the generation of synthetic training samples for aspect-based sentiment analysis in low resource settings," Expert Systems with Applications, vol. 261, p. 125514, 2025. DOI: 10.1016/j.eswa.2024.125514
  3. Duan, Shitong and Yi, Xiaoyuan and Zhang, Peng and Lu, Tun and Xie, Xing and Gu, Ning, "DENEV: Towards Deciphering and Navigating the Ethical Values of Large Language Models via Instruction Learning," in International Conference on Learning Representations (ICLR 2024), 2024. URL
  4. Han, Jongwook and Choi, Dongmin and Song, Woojung and Lee, Eun-Ju and Jo, Yohan, "Value Portrait: Assessing Language Models' Values through Psychometrically and Ecologically Valid Items," in Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 17119–17159, 2025. DOI: 10.18653/v1/2025.acl-long.838
  5. Zhang, Yuyang and Zhang, Yifu and Zhou, Xuehai and Chen, Xiaoyin, "A Measure-Theoretic Analysis of Reasoning: Structural Generalization and Approximation Limits," arXiv preprint, 2026. arXiv:2605.19944v1

LLM MCP KI-Tools