Il tuo server MCP non ha bisogno di 40 tool

Le demo MCP spesso mostrano tutto in una volta sola. Mostrano ogni endpoint e ogni tabella del database. Sostengono che l'agente possa chiamare qualsiasi cosa.

Questo sembra potente per dieci minuti. Poi il modello fallisce. Chiama lo strumento sbagliato. Passa argomenti con una struttura errata. Richiede un grafico da un endpoint di ricerca. Ripete un'azione distruttiva.

Il problema non è MCP. Il problema è trattare MCP come un adattatore magico per il tuo backend.

Un server MCP non è solo la tua API resa accessibile agli agenti. È una superficie di prodotto per un utente molto letterale e molto facilmente distraibile. Quell'utente è un modello linguistico.

Se dai a un modello 40 strumenti simili, non gli stai dando potere. Gli stai dando 40 modi per essere quasi corretto.

Smetti di rispecchiare le tue rotte API. Gli esseri umani possono leggere la documentazione e comprendere il contesto. I modelli effettuano il pattern matching di nomi e descrizioni.

Costruisci il tuo layer MCP attorno all'intento dell'utente.

Invece di rispecchiare ogni rotta, raggruppale in confini chiari:

  • Uno strumento per i riassunti di mercato
  • Uno strumento per i calendari delle uscite
  • Uno strumento per snapshot di dati specifici
  • Uno strumento per indicatori storici

Una rotta API dice: Se invii questa richiesta, il server risponderà. Uno strumento MCP dovrebbe dire: Usami per questo compito esatto, con questi input esatti, e aspettati questo risultato specifico.

Le buone descrizioni degli strumenti sono logica di instradamento, non testi di marketing.

Sbagliato: name: get_data description: Gets data from the API.

Meglio: name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.

Segui queste regole per ottenere agenti migliori:

  1. Usa nomi noiosi. Gli sviluppatori amano nomi compatti come fetch o query. I modelli hanno bisogno di nomi specifici come search_docs o check_deployment_status. I nomi ambigui sono costosi.

  2. Controlla la struttura della risposta. Non restituire oggetti annidati giganti. Restituisci la struttura più piccola possibile che supporti il compito. Se il modello vede troppi dati, utilizzerà il campo sbagliato o allucinerà dettagli.

  3. Progetta per il fallimento. La qualità della produzione deriva da come gestisci gli errori. Non limitarti a restituire un errore 500 o un array vuoto. Spiega al modello perché è fallito. Se nessun record corrisponde, dì al modello di suggerire all'utente un intervallo di date più ampio.

Il miglior strumento per un agente non è quello più potente. È quello che il modello non può fraintendere.

Fonte: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Community di apprendimento opzionale: https://t.me/GyaanSetuAi