MCP: un contratto di strumenti, non un’integrazione per agente

Model Context Protocol (MCP), nella definizione che ne dà la documentazione di Copilot Studio, serve a collegarsi a knowledge server e sorgenti dati esistenti direttamente dentro il prodotto. Un server MCP collegato espone tre categorie di elementi: Resources, dati file-like che l’agente può leggere per avere più contesto; Tools, funzioni che il modello linguistico può chiamare per compiere un’azione; Prompts, template di prompt predefiniti. Copilot Studio, al momento, supporta tool e resource: i prompt no.

Il punto che rende MCP interessante per un Agent Builder è il ciclo di vita. Ogni tool o resource pubblicato dal server diventa automaticamente disponibile in Copilot Studio, ed è il server a fornire nome, descrizione, input e output. Quando aggiorni o rimuovi qualcosa lato server, Copilot Studio riflette dinamicamente la modifica, così che le versioni obsolete spariscano. Un singolo server può integrare e gestire molti tool, e ogni agente Copilot Studio può accedere a ciascuno di essi. Tradotto in pratica: invece di ricostruire un connettore o un agent flow dentro ogni agente che deve fare la stessa cosa, mantieni il contratto una volta sola sul server e lo riusi. Anche la descrizione di un tool, che è ciò che guida la scelta dell’orchestratore, si corregge in un posto unico.

Attenzione a non confondere gli oggetti. Un server MCP collegato compare come un tool dell’agente, non come un topic, non come un agent flow e non come una knowledge source. La distinzione conta perfino per le resource: perché un agente Copilot Studio possa usarne una, il proprietario del server deve configurarla come output di uno dei tool MCP. E serve la generative orchestration attiva: senza di essa MCP non si usa.

Aggiungere un server MCP esistente

Il percorso raccomandato parte dalla pagina Tools dell’agente: Add a tool → New tool → Model Context Protocol. Si apre l’MCP onboarding wizard, dove compili i campi obbligatori Server name, Server description e Server URL. La descrizione non è decorativa: l’agent orchestrator la usa per capire a runtime se chiamare il tuo server. Poi scegli l’autenticazione fra None, API key e OAuth 2.0. Con API key indichi il Type, cioè Header o Query, e il nome dell’header o del parametro. Con OAuth 2.0 scegli fra Dynamic discovery (il server supporta dynamic client registration con discovery), Dynamic (DCR senza discovery: fornisci Authorization URL e Token URL template) e Manual (Client ID, Client secret, Authorization URL, Token URL template, Refresh URL e Scopes opzionali). Nei casi che lo prevedono compare un callback URL da registrare presso l’identity provider. Si chiude con Create, poi nella finestra Add tool con Create a new connection e Add to agent.

Per i connettori MCP Microsoft già pronti il flusso è più corto: Tools → Add a tool → Model Context Protocol, scegli il connettore dall’elenco, autorizzi la connessione e selezioni Add and configure.

La seconda strada è costruire a mano un custom connector in Power Apps importando uno schema OpenAPI del server. Il dettaglio che qualifica lo schema come MCP è l’annotazione di protocollo; il trasporto supportato è Streamable, mentre SSE è deprecato e non più supportato.

paths:
  /mcp:
    post:
      summary: Contoso Lead Management Server
      x-ms-agentic-protocol: mcp-streamable-1.0
      operationId: InvokeMCP

Scegliere gli strumenti e tenerli sotto controllo

Aperto il server dalla scheda Tools dell’agente, la sua settings page mostra Details più due sezioni specifiche di MCP: Tools, con nomi e descrizioni dei tool offerti, e Resources, con un campione delle resource. Quando aggiungi un server tutti i tool sono attivi e il toggle Allow all è su on. Se non ti servono tutti, disattivi Allow all: compaiono i toggle individuali e spegni ciò che è superfluo. Da quel momento i tool nuovi che il server aggiunge arrivano disattivati per default — comportamento sano per la governance, ma da ricordare quando qualcuno segnala che “il tool nuovo non si vede”.

Essere selettivi serve anche per capacità: i server MCP contano nel totale dei tool che un agente può ospitare, e il numero di istanze di server che possono girare contemporaneamente in una singola conversazione è limitato. La raccomandazione esplicita è tenere pochi server per agente e rimuovere quelli che non usi più.

Fra i server di prima parte disponibili come connettori trovi Microsoft Dataverse, Microsoft Learn Docs MCP, Microsoft Sentinel MCP, Work IQ MCP con le varianti Work IQ SharePoint MCP e Work IQ OneDrive MCP, Azure - Foundry IQ e la famiglia Dynamics 365 (Sales, Service, Customer Insights, ERP Analytics, Contact Center). Il Dataverse MCP Server, per esempio, espone tool come list_tables, describe_table, read_query, search, fetch, create_record, update_record e delete_record. Hanno una pagina di riferimento dedicata anche il Microsoft management MCP server (server ID MCPManagement, con tool tipo GetMCPServers e CreateToolWithConnector) e il server Copilot (mcp_M365Copilot), entrambi in preview.

Certificazione, policy e guasti tipici

La certificazione è la strada per rendere un server MCP utilizzabile con fiducia oltre il proprio tenant: dà a clienti e amministratori garanzie su affidabilità, sicurezza e conformità. Il publisher deve essere verificato e possedere o controllare l’endpoint; la submission avviene in Partner Center con l’offer type Apps and Agents for M365 and Copilot, e il pacchetto richiede un manifest file, un tool file, un file intro.md e la configurazione dell’autenticazione via Azure Key Vault. Il percorso prevede validazione automatica di struttura e metadati, una functional and safety review, quindi approvazione e pubblicazione; i server certificati sono attesi disponibili in Azure Foundry oltre che in Copilot Studio, e resta a carico del publisher mantenere l’implementazione allineata al pacchetto certificato.

Sulla governance, il fatto strutturale è che la connettività ai server MCP poggia sui connettori Power Platform: se una data policy regola i connettori, regola anche l’accesso al server MCP e ai suoi tool. Non confonderli con i Copilot connectors di Microsoft 365, che sono un oggetto diverso e servono a portare contenuto come knowledge.

Per il troubleshooting, i problemi noti riguardano quasi tutti lo schema di input dei tool: exclusiveMinimum valorizzato come intero invece che booleano provoca una System.FormatException; se il campo type è un array di più tipi lo schema viene troncato, e il workaround è usare un tipo singolo; i tool con input di tipo reference vengono filtrati dall’elenco dei tool disponibili, perché input e output reference non sono supportati; gli enum vengono interpretati come stringhe. Quando un tool non compare, quindi, guarda prima lo schema del server e poi l’agente.

Sull’obiettivo Configure MCP tools l’esame verifica soprattutto tre cose: che sappias il percorso concreto nel prodotto (Tools → Add a tool → Model Context Protocol, wizard, connection, Add to agent); che riconosca le opzioni di autenticazione e quando serve un callback URL; e che non scambi un server MCP per una knowledge source o per un agent flow. La confusione più costosa è pensare che l’MCP server sia un contenitore di conoscenza: è un fornitore di funzioni, e la conoscenza vi transita solo se il proprietario del server espone una resource come output di un tool.