MCP, A2A e Connettori Copilot rispondono a problemi di integrazione diversi, ma oggi convivono nello stesso ecosistema “agentico”. Provo a spiegare con una lente architetturale, tenendo come punto fermo Copilot Studio come ambiente autore, giusto per circoscrivere il campo di gioco.
MCP – Model Context Protocol
Problema che risolve:
Come fa un agente/LLM a usare strumenti, dati e API esterne in modo standardizzato?
Cos’è
MCP è un protocollo open standard (2024, originato da Anthropic, oggi Linux Foundation) che definisce come un agente parla con strumenti e fonti dati, in modo strutturato e interoperabile.
È spesso descritto come “la USB‑C degli agenti AI”.
Tecnicamente:
- standardizza tool calling, accesso a dati, risorse e prompt
- usa un modello client–server
- è framework-agnostic e model-agnostic
- oggi è supportato anche da Microsoft (SDK C#, integrazione Copilot Studio, Foundry, ecc.)
MCP non collega agenti tra loro, ma agenti ↔ strumenti
Nello scenario
- SAP, Jira, Salesforce, API custom, DB, file system
- ogni sistema è esposto come MCP Server
- Copilot / agente è MCP Client
Esemplificando:
“Agente, recupera l’ordine da SAP”
→ MCP definisce come chiamare SAP e come strutturare risultato e permessi
In Copilot Studio
- MCP è usato dietro le quinte:
– nei federated Copilot connectors
– nei tool esterni chiamati dagli agenti - tu non scrivi MCP, ma ne benefici come layer standard
MCP è il foundation layer per tool & data access.
A2A – Agent‑to‑Agent Protocol
Problema che risolve:
Come fanno agenti indipendenti a collaborare tra loro?
Cos’è
A2A è un protocollo open (Google, 2025, ora Linux Foundation) per la comunicazione agente ↔ agente:
- agenti costruiti con stack diversi
- agenti gestiti da team / vendor diversi
- agenti che non condividono memoria, prompt o strumenti
A2A:
- usa HTTP / JSON-RPC
- introduce Agent Card (capacità dichiarate)
- supporta task delegation, status, streaming risultati
- è pensato come “HTTP degli agenti”
MCP ≠ A2A
- MCP = agente ↔ strumenti
- A2A = agente ↔ agente
Nello scenario enterprise
Esempio realistico:
- Agente HR
- Agente Finance
- Agente Operations (magari di un partner)
Ognuno:
- vive nel suo runtime
- evolve in modo indipendente
- collabora su un processo end‑to‑end
In Copilot Studio
- Microsoft supporta A2A nell’Agent Framework
- Copilot Studio introduce:
– connected agents
– multi-agent orchestration - almeno oggi:
– A2A è più architetturale
– meno “citizen developer ready” dei connector
A2A è il collaboration layer tra agenti.
Copilot Connectors – Il layer “low‑code produttivo”
Problema che risolvono:
Come collego rapidamente Copilot/Agenti a sistemi enterprise in modo governato?
Cosa sono
I Copilot connectors sono l’evoluzione dei connettori Power Platform / Graph:
- prebuilt o custom
- sicuri, governati, con DLP
- integrati nativamente in:
– Copilot Studio
– Microsoft 365 Copilot
– Microsoft Search
Due famiglie chiave:
Synced connectors
- indicizzano dati in Microsoft Graph
- ottimi per:
– documentazione§
– CRM
– repository stabili
Federated connectors (preview)
- usano MCP
- fetch runtime, live
- niente indexing
- ideali per:
– dati sensibili
– dati dinamici (SAP, ticketing, sistemi operativi)
In Copilot Studio
Sono il tuo strumento quotidiano:
- li usi come Tools
- li combini con:
– prompt
– reasoning
– agent flows
– Power Automate
I connector sono il delivery layer enterprise-ready.
Mettiamoli insieme (vista architetturale)
| Livello | Serve per | Tecnologia |
|---|---|---|
| Collaboration | Agenti che collaborano | A2A |
| Execution / Tools | Agente usa sistemi e API | MCP |
| Authoring & Governance | Produttività, sicurezza, DLP | Copilot Studio + Connectors |
Oppure, detta semplice:
Copilot Studio è dove progetti
Connectors sono come integri oggi
MCP è lo standard sotto
A2A è il futuro dei sistemi multi‑agente