Ein Leitfaden zur Entwicklung benutzerdefinierter MCP-Erweiterungen: Vom Repo-Layout bis zur Veröffentlichung

Kundenspezifische MCP-Erweiterungen verwandeln einen generischen Assistenten in einen Spezialisten, der in deinen Systemen Arbeit erledigen kann — sicher, wiederholbar und mit Schutzmechanismen.

Was „MCP Extension“ in MCP-Repositories wirklich bedeutet

In MCP-Repositories ist eine „Erweiterung“ meist eines von zwei Dingen:

1. Ein eigenständiger MCP-Server, den du veröffentlichst (oder privat hältst) und der Fähigkeiten — Tools, Ressourcen und Prompts — über das Model Context Protocol bereitstellt.
2. Ein Repository-Modul/-paket, das beim Erstellen, Konfigurieren oder Bereitstellen von MCP-Servern hilft (z. B. eine Bibliothek gemeinsamer Auth-Handler, Schema-Validierung oder Deployment-Templates).

Die meisten Teams meinen das Erste: ein kundenspezifischer MCP-Server, der domänenspezifische Fähigkeiten hinzufügt, wie „unser Lagerbestand abfragen“, „ein Jira-Ticket erstellen“, „einen Compliance-Bericht generieren“ oder „die Kundenanrufe der letzten Woche zusammenfassen“.

MCP ist auf Protokollebene bewusst einfach, aber reale Erweiterungen erfordern sorgfältiges Design: Umfang, Auth, vorhersehbare Ausgaben, Fehlerbehandlung und Dokumentation, die die Erweiterung für Menschen und Modelle nutzbar macht.

Beginne mit dem Capability-Design (bevor du Code schreibst)

Der schnellste Weg, eine unordentliche Erweiterung zu bauen, ist, indem du direkt Endpunkte implementierst. Der schnellste Weg, eine zuverlässige Erweiterung zu bauen, ist, mit dem Capability-Design zu beginnen.

Entscheide, was du exponierst: Tools vs Resources vs Prompts

MCP-Server können drei Kernfähigkeiten bereitstellen:

• Tools: aufrufbare Funktionen, die etwas tun. Beispiele: create_ticket, search_docs, run_sql_readonly.
• Resources: strukturierte Daten, die abgerufen und referenziert werden können. Beispiele: eine Dateibaumstruktur, ein Knowledge-Base-Artikel, ein Kunden-Datensatz.
• Prompts: wiederverwendbare Prompt-Vorlagen, die das Modell konsistent für gängige Aufgaben anleiten.

Eine praktische Faustregel:

• Wenn es den Zustand ändert oder eine Aktion auslöst: Tool.
• Wenn es hauptsächlich „lesen und zitieren“ ist: Resource.
• Wenn es „diesen Workflow oft wiederholen“ ist: Prompt.

Reduziere die Angriffsfläche

Maintainer von Erweiterungen überschätzen oft, wie viele Tools sie benötigen. Beginne mit weniger Tools, die robust und komponierbar sind.

Schlechtes Muster:

• create_ticket_bug
• create_ticket_task
• create_ticket_incident

Besseres Muster:

• create_ticket mit einem eingeschränkten type-Feld, serverseitig validiert.

Dein zukünftiges Ich wird es dir danken, wenn du Logging, Quotenlimits oder Berechtigungsprüfungen hinzufügen musst — einmal, nicht dreimal.

Schreibe „Tool-Verträge“ ernsthaft

Schreibe vor der Implementierung pro Tool eine einseitige Vereinbarung:

• Name: stabil, lower_snake_case
• Zweck: ein Satz
• Eingaben: Schema mit Typen und Einschränkungen
• Ausgaben: Schema mit Beispielen
• Fehlermodi: typische Fehler und Nachrichten
• Sicherheit: benötigte Scopes, Redaktionen, Audit-Anforderungen
• Idempotenz: was passiert, wenn das Tool zweimal aufgerufen wird?

Behandle diese Verträge als Teil deines Repos. In vielen MCP-Repositories werden diese Dokumente zu deinem besten langfristigen Wartungsvermögen.

Wähle eine Erweiterungsarchitektur, die dich später nicht einsperrt

Du implementierst einen MCP-Server typischerweise als kleinen Service, der MCP über stdio oder HTTP spricht (je nach Stack und Client). Unabhängig vom Transport willst du eine Struktur, die unterstützt:

• Tools hinzuzufügen, ohne Dateien explodieren zu lassen
• Zentralisierte Authentifizierung und Richtlinien
• Gemeinsame Validierung und Fehlerformatierung
• Deterministische Ausgaben
• Tests ohne echte Zugangsdaten

Ein sauberes Repo-Layout für MCP-Erweiterungen

Ein weithin praktikables Layout:

• src/
  • server/ (MCP-Wiring, Registrierung, Transport)
  • tools/ (eine Datei pro Tool oder pro Domäne)
  • resources/ (Resource-Handler)
  • prompts/ (Prompt-Vorlagen + Metadaten)
  • lib/ (Auth, Clients, Validierung, Redaktion, Logging)
• tests/
  • unit/
  • integration/
  • fixtures/
• docs/
  • tools.md
  • resources.md
  • prompts.md
  • security.md
  • changelog.md
• examples/ (minimale Skripte zur lokalen Nutzung)
• mcp.json oder Konfigurationsvorlage (falls dein Ökosystem sie verwendet)

Diese Struktur bildet sauber ab, wie MCP-Fähigkeiten konsumiert werden: tools/resources/prompts sind auffindbar, und deine Policy- und Klebelogik bleibt zentralisiert.

Mach den „Happy Path“ langweilig

Eine Erweiterung sollte vorhersehbar funktionieren, selbst wenn das Modell … kreativ ist.

Ziele:

• Strikte Eingabevalidierung (unbekannte Felder ablehnen)
• Normalisierte Ausgaben (stabile Schlüssel, stabile Typen)
• Konsistente Fehlerform (maschinenfreundlich)
• Klare „was als Nächstes zu tun ist“-Nachrichten für wiederherstellbare Fehler

Tools implementieren: Praktische Muster, die funktionieren

Tools sind der Ort, an dem die meisten kundenspezifischen MCP-Erweiterungen ihren Wert zeigen. Und sie sind auch der Ort, an dem sie scheitern.

Definiere Schemata und validiere serverseitig

Auch wenn dein Client validiert, muss dein Server erneut validieren. Behandle alles als untrusted input.

Typische Einschränkungen, die es wert sind durchgesetzt zu werden:

• Begrenzungen für Stringlängen (Namen, Titel, Beschreibungen)
• Enum-Einschränkungen (priority: low/medium/high)
• Regex-Einschränkungen (Ticket-Keys, Kunden-IDs)
• Maximale Array-Größen (um Payload-Explosionen zu vermeiden)
• Datumsformate (nur ISO 8601, der Übersicht halber)

Wenn dein Stack JSON Schema oder einen typisierten Validator unterstützt, benutze ihn und fail fast.

Gib Ausgaben zurück, die Modelle zuverlässig wiederverwenden können

Modelle arbeiten am besten mit:

• Flachem JSON, wenn möglich
• Stabilen IDs
• Expliziten Statusfeldern
• URLs, wenn relevant
• Minimalem Prosatext in Feldern, die programmatisch verwendet werden sollen

Beispielausgabe für ein Action-Tool:

• status: success | failed
• id: neu erstellte Objekt-ID
• url: Deep-Link
• summary: kurze, menschenlesbare Zeile
• next_actions: optionales Array empfohlener Folgeaktionen

Vermeide es, rohe API-Antworten zu dumpen, sofern du nicht auch eine normalisierte Ansicht bereitstellst.

Implementiere ein standardisiertes Fehler-Envelope

Ein konsistentes Fehler-Envelope macht deine Erweiterung leichter zu debuggen und sicherer zu automatisieren. Ein gutes Envelope enthält:

• error_code (stabil, durchsuchbar)
• message (menschenlesbar)
• details (strukturiert, optional)
• retryable (boolean)
• suggested_fix (kurzer Vorschlag)

Wenn ein Modell auf einen Fehler trifft, kann es entscheiden, ob es erneut versucht, nach fehlenden Daten fragt oder stoppt.

Füge früh Ratenbegrenzungen und Timeouts hinzu

Selbst interne Erweiterungen können interne Systeme versehentlich DDoS-en, wenn sie wiederholt aufgerufen werden. Setze von Anfang an Schutzmechanismen:

• Pro-Tool-Timeouts (z. B. 10–30 Sekunden)
• Retry-Policies mit Backoff (vorsichtig bei nicht-idempotenten Tools)
• Serverseitige Ratenlimits (pro Benutzer/Token)
• Circuit Breaker für Downstream-Ausfälle

Resources implementieren: Mach Daten referenzierbar, nicht nur abfragbar

Resources werden unterschätzt. Ein gutes Resource-Design hilft dem Modell, Informationen zu zitieren und zu navigieren, ohne deinen Server in einen „großen Textblob-Anbieter“ zu verwandeln.

Bevorzuge kleine, verlinkbare Resources

Statt einer Resource namens company_handbook, ziehe in Betracht:

• handbook/index
• handbook/{section_id}
• handbook/search?q=...

Das erlaubt dem Modell, nur das zu holen, was es braucht, und reduziert Token-Verschwendung.

Füge Metadaten für Nachvollziehbarkeit hinzu

Resource-Antworten sollten enthalten:

• Eine stabile Resource-Identifikation
• Zeitstempel der letzten Aktualisierung (wenn möglich)
• Quell-Links oder kanonische IDs
• Zugriffslevel (public/internal/restricted)
• Optionale Auszüge plus Pfad zum Abruf des Vollinhalts

Nachvollziehbarkeit ist wichtig für Compliance und zum Debuggen von „woher kam diese Antwort?“

Prompts: Das stille Arbeitspferd großartiger Erweiterungen

Prompts in MCP sind nicht nur „hilfreicher Text“. Sie sind wiederholbare Workflows, die du mit deiner Erweiterung auslieferst, damit sich der Assistent konsistent verhält.

Nützliche Prompt-Vorlagen umfassen:

• „Formuliere eine Support-Antwort in unserem Ton“
• „Fasse ein Ticket für einen Ingenieur zusammen“
• „Erzeuge Release-Notes aus gemergten PR-Titeln“
• „Konvertiere rohe Abfrageergebnisse in ein Executive Briefing“

Eine starke Prompt-Vorlage hat:

• Eine klare Rolle und Zielsetzung
• Erforderliche Eingaben
• Ein strukturiertes Ausgabeformat
• Schutzvorkehrungen („Wenn Daten fehlen, frage danach“)
• Stilrichtlinien, die zu deiner Organisation passen

Prompts reduzieren auch die Versuchung, Geschäftsregeln in Tool-Namen zu packen. Halte Geschäftslogik in Tools und Richtlinien; halte Workflow-Anleitungen in Prompts.

Sicherheit und Berechtigungen: Der Teil, den du später nicht patchen kannst

Wenn deine Erweiterung mit echten Systemen interagiert, braucht sie echte Sicherheit. „Ist intern“ ist keine Strategie.

Wähle ein Auth-Modell: User-delegated vs Service-delegated

Zwei gängige Ansätze:

• User-delegated: Die Erweiterung handelt im Namen eines Nutzers und respektiert dessen Berechtigungen. Am besten für Produktivitätstools, die Nutzerzugriff spiegeln sollen.
• Service-delegated: Die Erweiterung verwendet ein Service-Konto mit eingeschränkten Rechten. Am besten für kontrollierte Automatisierung und Read-Only-Dashboards.

User-delegated erfordert typischerweise Token-Austausch, Session-Handling und sorgfältiges Auditing. Service-delegated erfordert strikte Scope-Einschränkungen und möglicherweise separate Tools für privilegierte Aktionen.

Scope Tools nach Risiko

Nicht alle Tools sind gleich. Du kannst sie nach Risiko gruppieren und unterschiedliche Gates anwenden:

• Read-only: search, list, retrieve
• Write: create, update
• Destructive: delete, purge, revoke
• Financial/legal: billing, contracts, compliance actions

Für höher riskante Tools füge zusätzliche Anforderungen hinzu:

• Obligatorische Bestätigungsfelder
• Zwei-Personen-Freigabe-Workflows (wo anwendbar)
• „Dry run“-Modus
• Enge Ratenlimits
• Detaillierte Audit-Logs

Redigiere sensible Daten in beide Richtungen

Redaktion betrifft nicht nur ausgehende Logs. Sie betrifft auch Antworten.

Wenn die Downstream-API Geheimnisse, personenbezogene Daten oder Tokens zurückgibt, sollte deine Erweiterung:

• Sensible Felder standardmäßig entfernen
• Eine sichere „maskierte“ Repräsentation bereitstellen
• Volle Details nur mit expliziter Erlaubnis und klarem Zweck offenlegen

Protokolliere für Audits, ohne Daten zu leaken

Eine praktische Logging-Policy:

• Logge Tool-Name, Timestamp, Benutzeridentität, Request-ID
• Logge Hashes oder Zählwerte statt Rohinhalte
• Speichere Roh-Payloads nur in sicheren Audit-Speichern, falls erforderlich
• Füge Korrelations-IDs für Downstream-Calls hinzu

Das gibt dir Nachvollziehbarkeit, ohne dein Log-System zur Sicherheitslücke zu machen.

Testen kundenspezifischer MCP-Erweiterungen wie ein Profi

Die meisten Erweiterungsfehler sind keine Syntaxfehler. Es sind Integrations- und Randfallfehler: fehlende Felder, unerwartete Downstream-Antworten, Konkurrenzfälle und Berechtigungsfehler.

Unit-Tests: Validiere Schemata und Fehlerformen

Unit-Tests sollten abdecken:

• Schema lehnt unbekannte Felder ab
• Pflichtfelder werden durchgesetzt
• Enum-Einschränkungen
• Ausgabe-Normalisierung
• Konsistenz des Fehler-Envelopes

Integrationstests: Verwende Sandboxes und Fixtures

Für Integrationstests:

• Nutze Vendor-Sandboxes (Jira Sandbox, GitHub Test-Org, Stripe Testmodus)
• Mocke Downstream-APIs, wenn Sandboxes fehlen
• Nimm Fixtures für gängige Antworten auf
• Teste Timeouts und Retries

Eine gute Integration-Suite enthält „Failure Rehearsal“-Tests:

• downstream 500
• downstream 429
• auth expired
• permission denied
• partielle Daten zurückgegeben

Contract-Tests: Halte Tool-Verträge ehrlich

Erinnere dich an die Tool-Verträge, die du geschrieben hast? Verwandle sie in Tests:

• Beispielinput sollte die Validierung bestehen
• Beispieloutput sollte dem Schema entsprechen
• Bekannte Fehler-Szenarien sollten bekannte error_codes erzeugen

Contract-Tests verhindern stille Breaking Changes bei Refactorings.

Dokumentation, die sowohl Menschen als auch Modelle hilft

In MCP-Repositories ist Dokumentation nicht dekorativ. Sie ist, wie andere Entwickler und Toolkonsumenten verstehen, was du gebaut hast.

Mindestdokumentation zum Ausliefern:

• Quickstart: wie lokal ausführen, benötigte Env Vars, wie ein Client verbunden wird
• Tools reference: Inputs/Outputs, Beispiele, Fehlercodes
• Security: Berechtigungen, Scopes, Audit-Logging
• Operational guide: Deployment, Monitoring, Incident Response
• Changelog: user-facing Änderungen und Migrationen

Schreibe Beispiele so, als würden sie in Produktion kopiert — denn das werden sie.

Versionierung und Rückwärtskompatibilität: Vermeide überraschende Brüche

Kundenspezifische MCP-Erweiterungen entwickeln sich. Der einfachste Weg, Vertrauen zu verlieren, ist, Ausgaben ohne Vorwarnung zu ändern.

Verwende Semantische Versionierung mit Disziplin

Eine praktikable Policy:

• PATCH: Bugfixes, keine Schemaänderungen
• MINOR: additive Änderungen (neue optionale Felder, neue Tools)
• MAJOR: breaking Schema-Änderungen, umbenannte Tools, entfernte Felder

Depriziere, bevor du entfernst

Wenn du ein Tool oder Feld entfernen musst:

• Als veraltet in den Docs kennzeichnen
• Es für ein definiertes Zeitfenster funktionsfähig halten (30–90 Tage)
• Warnungen in Antworten hinzufügen, falls passend
• Einen Migrationspfad bereitstellen („verwende Tool X mit Feld Y stattdessen“)

Das ist noch wichtiger, wenn andere Repositories von deiner Erweiterung abhängen.

Distribution und Packaging in MCP-Repositories

Wie du verteilst, hängt von deiner Umgebung ab:

• Open-Source-MCP-Server auf GitHub veröffentlicht
• Privates Repo in deiner Organisation
• Internes Paket über ein Artifact-Registry verteilt
• Container-Image, das in einem Cluster deployed wird

Egal welche Verteilungsmethode, behandle Releases als Produkte.

Release-Checkliste

Bevor du ein Release taggst:

• Tests grün (Unit + Integration)
• Tool-Verträge aktualisiert
• Docs aktualisiert
• Changelog geschrieben
• Security-Review für neue Tools
• Monitoring-Dashboards aktualisiert (falls nötig)

Wenn deine Erweiterung kritische Systeme verbindet, führe ein gestaffeltes Rollout durch.

Observability und Betrieb: Halte es am Laufen, wenn es seltsam läuft

Das Modell sagt dir nicht, dass deine Erweiterung flacky ist. Nutzer tun das — nachdem sie ihre Zeit verschwendet haben.

Metriken, die es wert sind, erfasst zu werden

Erfasse mindestens:

• Tool-Aufrufanzahl pro Tool
• Latenz p50/p95/p99
• Fehlerquote pro Tool und pro Downstream-Dependency
• Timeout-Anzahl
• Rate-Limit-Trigger
• Auth-Fehler

Füge Dashboards hinzu, die dir die Frage beantworten lassen: „Ist die Erweiterung kaputt oder das Downstream-System?“

Tracing von Downstream-Aufrufen

Wenn deine Erweiterung mehrere Services aufruft, spart verteiltes Tracing Stunden. Selbst leichtgewichtige Korrelations-IDs helfen, einen Fehlerpfad zu rekonstruieren.

Sichere Degradation

Wenn eine Abhängigkeit down ist, wirf nicht nur kryptische Fehler. Biete:

• Eine klare Nachricht
• Ob ein Retry wahrscheinlich hilft
• Eine vorgeschlagene Alternative (Read-Only-Modus, gecachte Daten)
• Einen Status-Page-Link, falls vorhanden

Das lässt die Erweiterung selbst unter Belastung verlässlich erscheinen.

Eine Zwischenprüfung im Projekt: Das „Extension Quality“-Audit

Halbzeit beim Bauen: Pause machen und ein Audit entlang dieser Fragen durchführen:

• Kann jedes Tool in einem Satz beschrieben werden?
• Sind Tool-Namen konsistent und vorhersagbar?
• Sind Schemata strikt und validiert?
• Sind Ausgaben normalisiert und stabil?
• Existieren Fehlercodes und mappen sie auf Aktionen?
• Werden Berechtigungen serverseitig durchgesetzt?
• Werden sensible Daten redigiert?
• Haben wir mindestens einen Integrationstest pro Tool?
• Würde ein neuer Entwickler verstehen, wie man in einer Stunde ein Tool hinzufügt?

Wenn du mehrere „Nein“-Antworten hast, behebe die Struktur jetzt. Später wird es nur schwerer.

Beispielerweiterungen bauen: Drei praktische Blaupausen

Ein Leitfaden wird real, wenn du dir vorstellen kannst, was du baust. Hier sind drei Blaupausen, die sauber auf gängige Use-Cases von MCP-Repositories abgebildet sind. Jede kann als kleiner Server mit einer Handvoll Tools und Resources implementiert werden.

1. Internal Docs Navigator

   • Tools: search_docs, get_doc_section, list_collections
   • Resources: docs/{doc_id}, docs/{doc_id}/sections/{section_id}
   • Prompts: “Answer with citations from docs”
   • Wichtige Punkte: Zugriffskontrolle, Inhaltschunking, Zitationen, Aktualität

2. Ticketing and Incident Assistant

   • Tools: create_ticket, update_ticket, link_ticket, summarize_ticket, assign_oncall
   • Resources: tickets/{key}, incidents/{id}
   • Prompts: “Triage and propose next steps”
   • Wichtige Punkte: Idempotenz bei Erstellung, rollenbasierte Berechtigungen, Audit-Logs

3. **Data Warehouse Read-Only Query Server **

   • Tools: run_query_readonly, explain_query, list_tables, describe_table
   • Resources: schemas/{name}, tables/{name}
   • Prompts: “Write safe SQL and summarize results”
   • Wichtige Punkte: strikte Read-Only-Durchsetzung, Query-Timeouts, Ergebnislimits, PII-Masking

Diese Blaupausen sind nicht zum Zeilen-um-Zeilen-Kopieren gedacht. Sie sollen zeigen, wie „klein aber komplett“ in MCP-Repositories aussieht.

Umgang mit Idempotenz, Konkurrenz und „Doppelaufrufen“

Tool-Calling-Systeme können wiederholte Aufrufe desselben Intents auslösen — manchmal durch Retries, manchmal durch Benutzer-Nachfragen, manchmal durch Client-Reconnects.

Füge Idempotency-Keys für Schreiboperationen hinzu

Für Tools, die Daten erstellen oder mutieren, akzeptiere einen optionalen idempotency_key:

• Wenn derselbe Key erneut verwendet wird, gib das ursprüngliche Ergebnis zurück.
• Speichere Idempotency-Records mit einer sinnvollen TTL.
• Dokumentiere, wie lange Keys gültig bleiben.

Das verhindert doppelte Tickets, doppelte Rechnungen, doppelte Einladungen — klassische Erweiterungsfehler.

Schütze vor partiellen Fehlern

Wenn dein Tool mehrere Schritte durchführt:

• Bevorzuge Transaktionen, wenn Downstream das unterstützt.
• Andernfalls designe Kompensationsschritte (Rollback) oder einen „Resume“-Flow.
• Gib Zwischen-IDs zurück, damit Menschen untersuchen können.

Das Ziel ist nicht Perfektion; es ist Wiederherstellbarkeit.

Extensions „modellfreundlich“ machen, ohne modellabhängig zu werden

Die Versuchung ist groß, alles an die Gewohnheiten eines bestimmten Modells anzupassen. Widerstehe. Baue Erweiterungen, die Client-agnostisch und Model-agnostisch sind.

Halte Tool-Namen und Felder wörtlich

Vermeide ausgefallene Namen und überladene Felder. Nutze Begriffe, die dein Business bereits verwendet:

• customer_id statt cid
• invoice_number statt inv
• priority mit bekannter Enum

Wörtliche Benennung verbessert Korrektheit und macht deine Docs durchsuchbar.

Lege Geschäftsregeln in den Server, nicht in den Prompt

Prompts helfen Modellen, Regeln zu folgen, aber Durchsetzung gehört in den Code:

• Berechtigungsprüfungen
• Pflichtfreigaben
• Zulässige Zustandsübergänge
• Policy-Einschränkungen (z. B. „niemals diese Tabellen abfragen“)

Wenn eine Regel wichtig ist, setze sie durch. Prompts sind Anleitung, keine Sicherheit.

Ein praktischer Workflow für das Hinzufügen eines neuen Tools

Wenn ein Stakeholder fragt: „Können wir ein Tool X hinzufügen?“, folge einem wiederholbaren Workflow.

1. Kläre die Aufgabe
   Was ist das eigentliche Ziel des Nutzers? Welches System ist die Quelle der Wahrheit?

2. Entwirf den Tool-Vertrag
   Eingaben/Ausgaben, Fehler, Berechtigungsscope.

3. Review auf Sicherheit
   Kann es Daten löschen? Kann es PII offenlegen? Könnte es missbraucht werden?

4. Implementiere mit Validierung
   Striktes Schema, normalisierte Ausgaben, Fehler-Envelope.

5. Füge Tests hinzu
   Unit-Tests für Schema und Fehler; Integrationstests für den Downstream-Call.

6. Dokumentiere und liefere aus
   Aktualisiere Tool-Docs, Beispiele und Changelog. Tagge ein Release.

Dieser Workflow ist langweilig — im besten Sinne. Er reduziert „tribal knowledge“ und macht die Erweiterungsentwicklung skalierbar.

Häufige Fehler in kundenspezifischen MCP-Erweiterungen (und wie man sie vermeidet)

Fehler: ein run_any_command-Tool exposen

Ein Tool, das beliebige Befehle oder Abfragen ausführt, ist ein Sicherheitsrisiko. Selbst read-only „beliebige SQL“-Funktionen können sensible Daten exponieren, wenn du eine Tabelle oder View übersehen hast.

Behebung:

• Biete eingeschränkte Abfragen oder vorgefertigte Report-Tools an
• Erzwinge Allowlists
• Füge Zeilenlimits und Spaltenmaskierung hinzu

Fehler: Unbegrenzten Text zurückgeben

Massive Blobs schaden der Performance und erhöhen die Wahrscheinlichkeit, dass das Modell Schlüsselinfos verpasst.

Behebung:

• Gib Zusammenfassungen plus Möglichkeit, mehr zu holen
• Paginierung
• Intentionales Chunking von Resources

Fehler: schwache Fehlermeldungen

„Something went wrong“ ist nicht akzeptabel, wenn ein Modell Calls orchestriert.

Behebung:

• Standardisiere Fehlercodes
• Füge vorgeschlagene Fixes hinzu
• Markiere retryable Fehler klar

Fehler: kein Operations-Plan

Wenn niemand Monitoring und On-Call besitzt, degradiert die Erweiterung stillschweigend.

Behebung:

• Füge grundlegende Dashboards hinzu
• Definiere Ownership
• Dokumentiere Incident-Schritte

Veröffentlichung und Pflege deiner Erweiterung im Zeitverlauf

Eine MCP-Erweiterung ist nicht „fertig“, wenn sie einmal funktioniert. Die Wartungsphase ist, wo Vertrauen aufgebaut wird.

Behandle Änderungen in Downstream-APIs als erstklassiges Risiko

Wenn du mit SaaS-Anbietern integrierst:

• Verfolge deren Changelogs
• Pinne API-Versionen, wo möglich
• Führe Integrationstests regelmäßig aus
• Füge Kompatibilitäts-Hinweise in deine Docs

Halte eine enge Feedback-Schleife mit Nutzern

Beobachte, wie Leute die Erweiterung tatsächlich nutzen:

• Welche Tools werden am meisten genutzt?
• Welche Tools erzeugen am meisten Fehler?
• Was fragen Nutzer wiederholt, das zu einer Prompt-Vorlage werden könnte?
• Wo werden Menschen zu manuellen Schritten gezwungen?

Oft ist die beste „neue Funktion“ kein neues Tool — es sind bessere Defaults, klarere Outputs oder ein sicherer Workflow.

Etabliere Contribution-Guidelines im MCP-Repo

Wenn mehrere Teams Tools hinzufügen werden, brauchst du Standards:

• Namenskonventionen
• Schema-Stil
• Fehler-Envelope-Format
• Logging- und Redaction-Anforderungen
• Testanforderungen
• Review-Checkliste für Sicherheit

Ein kurzes CONTRIBUTING.md und eine PR-Vorlage können Wochen an Nacharbeit vermeiden.

Den Kreis schließen: Deine Erweiterung sollte vertrauenswürdig wirken

Eine großartige kundenspezifische MCP-Erweiterung fühlt sich an wie ein verlässlicher Kollege: klar in dem, was sie kann, ehrlich in dem, was sie nicht kann, und konsistent unter Druck. Baue klein, validiere alles, logge verantwortungsvoll, dokumentiere unermüdlich und versioniere so, als würden andere Leute davon abhängen — denn das werden sie.

External Links

MCP developer guide | Visual Studio Code Extension API Build an MCP App - Model Context Protocol Build your MCP server – Apps SDK | OpenAI Developers Making your own MCP server in VS Code | Microsoft Learn Visual Studio Code + Model Context Protocol (MCP) Servers Getting …

External References

• Internal Docs Navigator
• and Incident Assistant
• Read Only Query Server