Ihr MCP-Server braucht keine 40 Tools
MCP-Demos zeigen oft alles auf einmal. Sie zeigen jeden Endpunkt und jede Datenbanktabelle. Sie behaupten, der Agent könne alles aufrufen.
Das fühlt sich für zehn Minuten mächtig an. Dann scheitert das Modell. Es ruft das falsche Tool auf. Es übergibt Argumente in der falschen Form. Es verlangt ein Diagramm von einem Such-Endpunkt. Es wiederholt eine destruktive Aktion.
Das Problem ist nicht MCP. Das Problem ist, MCP wie einen magischen Adapter für Ihr Backend zu behandeln.
Ein MCP-Server ist nicht einfach nur Ihre API, die für Agenten zugänglich gemacht wurde. Er ist eine Produktoberfläche für einen sehr wörtlich nehmenden und sehr leicht ablenkbaren Nutzer. Dieser Nutzer ist ein Sprachmodell.
Wenn Sie einem Modell 40 ähnliche Tools geben, verleihen Sie ihm keine Macht. Sie geben ihm 40 Möglichkeiten, fast richtig zu liegen.
Hören Sie auf, Ihre API-Routen einfach zu spiegeln. Menschen können Dokumentationen lesen und den Kontext verstehen. Modelle führen Pattern-Matching bei Namen und Beschreibungen durch.
Bauen Sie Ihre MCP-Schicht um die Benutzerabsicht herum auf.
Anstatt jede Route zu spiegeln, gruppieren Sie diese in klare Grenzen:
- Ein Tool für Marktübersichten
- Ein Tool für Release-Kalender
- Ein Tool für spezifische Datenschnappschüsse
- Ein Tool für historische Indikatoren
Eine API-Route sagt: Wenn Sie diese Anfrage senden, wird der Server antworten. Ein MCP-Tool sollte sagen: Nutzen Sie mich für genau diese Aufgabe, mit genau diesen Eingaben, und erwarten Sie dieses spezifische Ergebnis.
Gute Tool-Beschreibungen sind Routing-Logik, keine Marketing-Texte.
Schlecht: name: get_data description: Gets data from the API.
Besser: name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.
Befolgen Sie diese Regeln für bessere Agenten:
- Verwenden Sie