MCP, tool servers e contesto strutturato

Quando un agente deve leggere ticket, documentazione, database, repository o sistemi di monitoraggio, servono interfacce controllate. MCP e tool server nascono per esporre risorse e azioni in modo strutturato, invece di affidarsi a copia-incolla o script improvvisati.

Perché questa lezione conta

Un agente utile non vive solo nella chat. Deve accedere a fonti esterne: issue tracker, documentazione interna, filesystem, log, metriche, API. Ogni accesso però introduce rischi: permessi, dati sensibili, azioni distruttive, costi.

Il punto non è collegare tutto. È decidere cosa vale la pena esporre e con quali limiti.

Risorse, prompt e tool

Un sistema di contesto strutturato può esporre:

• risorse: documenti, file, ticket, log;
• prompt: template riusabili;
• tool: azioni invocabili con parametri;
• metadati: schema, descrizioni, permessi.

Più l’interfaccia è chiara, meno il modello deve indovinare.

Quando serve MCP

Serve quando:

• più client devono usare le stesse fonti;
• il contesto cambia spesso;
• vuoi controllare permessi e schema;
• servono tool riusabili;
• vuoi evitare integrazioni ad hoc per ogni agente.

Non serve quando basta uno script locale, un file README o un endpoint semplice.

Valutare un tool server

Per ogni fonte chiedi:

Domanda	Perché conta
Che cosa espone?	evita tool troppo generici
È read-only o scrive?	cambia il rischio
Quali dati sensibili tratta?	impatta privacy e log
Che schema hanno i parametri?	riduce chiamate sbagliate
Come fallisce?	serve fallback

Laboratorio guidato

Prendi un tool server esistente o progettane uno:

• documentazione interna;
• ticket;
• repository;
• log applicativi;
• database read-only.

Compila:

Nome:
Risorse esposte:
Tool esposti:
Permessi:
Dati sensibili:
Errori possibili:
Quando usarlo:
Quando non usarlo:

Output atteso

Una valutazione: quale parte del tuo contesto vale la pena esporre via MCP o tool server.

Deve concludere con una scelta:

• MCP;
• script locale;
• API ad hoc;
• file statico;
• nessuna integrazione.

Checklist di verifica

• so distinguere risorsa e tool;
• non espongo azioni distruttive senza guardrail;
• ogni tool ha schema chiaro;
• so motivare quando MCP è eccessivo;
• considero privacy, log e permessi.

Errori comuni

Collegare tutto. Ogni integrazione aumenta superficie di rischio.

Tool troppo generici. Un execute(query) senza limiti è difficile da controllare.

Dimenticare errori e fallback. Anche il tool server fallisce: timeout, permessi, dati mancanti.

Collegamenti

• Modulo: Contesto e memoria nel progetto — lezione 24 del corso.
• Lezione precedente: Codebase indexing e agenti che leggono i file.
• Prossima lezione: Memoria persistente vs contesto effimero.