MCP oltre la demo: progettare agenti che lavorano davvero con lo stack aziendale

La demo classica di Model Context Protocol è semplice: colleghi un server MCP, chiedi qualcosa al modello e compare una tool call. In produzione, però, il problema interessante inizia dopo. Un agente utile deve muoversi tra sistemi con responsabilità diverse senza trasformarsi in un insieme fragile di integrazioni.

Uno stack reale è eterogeneo

La conoscenza può vivere in Notion o Confluence; il lavoro operativo in Linear o Jira; il codice in GitHub; le conversazioni in Slack; clienti e deal in HubSpot; pagamenti e subscription in Stripe; design in Figma; metriche in Amplitude o Mixpanel; errori applicativi in Sentry. A questi si aggiungono ERP, database, pannelli amministrativi e API proprietarie.

MCP fornisce un protocollo comune con cui un client AI può scoprire e invocare capacità esposte da server diversi. Non elimina le API sottostanti: crea un livello agent-friendly sopra sistemi che possono continuare a usare REST, GraphQL, SDK, code e servizi interni.

Tool di dominio, non wrapper casuali delle API

La qualità di un server MCP dipende molto dal design dei suoi tool. Esporre decine di primitive tecniche costringe il modello a ricostruire la business logic. È spesso più efficace offrire operazioni semanticamente chiare: trovare un progetto, creare una issue, recuperare il contesto di un cliente, verificare lo stato di una fattura o pubblicare un contenuto.

Linear, ad esempio, documenta tool per trovare, creare e aggiornare issue, progetti e commenti. HubSpot espone accesso controllato ai dati CRM e operazioni di lettura e scrittura. Atlassian consente agli strumenti AI di interagire con Jira e Confluence. Sono esempi utili perché mostrano MCP applicato a domini diversi, non soltanto al coding.

Comporre più server

Il vero salto avviene quando il client dispone di più server MCP. Una richiesta come “analizza il bug segnalato dal cliente enterprise e prepara il piano di intervento” può richiedere contesto dal CRM, conversazioni, issue tracker, repository e monitoring. L’orchestrazione appartiene al livello agentico; ogni server resta responsabile del proprio dominio.

Read e write hanno rischi diversi

Cercare una pagina e creare un rimborso non sono operazioni equivalenti. Un’architettura seria distingue capacità di lettura e scrittura, applica OAuth e scope appropriati, valida gli input, registra le operazioni e introduce conferme per le azioni sensibili. Anche i prodotti che adottano MCP stanno introducendo controlli amministrativi e meccanismi di governance.

Custom MCP per il software proprietario

Non tutto vive in SaaS pubblici. Un server MCP personalizzato può trasformare use case interni in tool: get_inventory, create_quote, check_customer_credit, schedule_technician o publish_article. Il modello vede un contratto; dietro il tool possono esserci Laravel, Spring Boot, una REST API, un message broker o un sistema legacy.

Il confine architetturale conta

Il server MCP non dovrebbe diventare il posto in cui duplicare la business logic. Idealmente traduce una richiesta agentica verso application service già esistenti, mantenendo autorizzazione, validazione e invarianti nel dominio. In questo modo l’AI è un nuovo consumer dell’applicazione, non il nuovo centro dell’architettura.

Perché interessa ai developer

MCP rende più concreta una direzione importante: costruire capacità applicative riutilizzabili da diversi client AI senza progettare un’integrazione ad hoc per ogni modello. Ma lo standard da solo non rende un agente affidabile. Naming dei tool, schemi, granularità, permessi, idempotenza, osservabilità e gestione degli errori diventano parte della developer experience.

La sfida non è far chiamare una funzione a un LLM. È progettare un confine sicuro e comprensibile tra il ragionamento probabilistico del modello e i sistemi deterministici che fanno funzionare il business.