Build · Topic 03 of 14
Tools, MCP and agent-to-agent: how AI agents call systems and each other
Tools are the named actions an AI agent may ask for; the model picks one and fills in the inputs, and your software runs it. MCP, the Model Context Protocol, is the open standard that connects an agent to tools and data through one interface. A2A, the agent-to-agent protocol, connects agents to each other.
In this guide: 83 pages
Key takeaways
- A tool is a name, a description and a JSON Schema. The model never runs it; your code does, and that is where every control sits.
- The current MCP specification is 2026-07-28 and it is stateless: no initialize handshake, no session id, HTTP+SSE and dynamic client registration deprecated, tasks moved into an extension. Most tutorials still describe the 2025 protocol.
- MCP and A2A now share one neutral home, the Agentic AI Foundation (MCP since 9 Dec 2025, A2A since 27 Aug 2026). All three clouds ship MCP; A2A is at version 1.0 on Microsoft and Google and on the 0.3 SDK in the documented AWS path.
- Put a gateway between agents and tools. It is where you pin tool lists, allow-list tools, scope tokens, require approval for writes and log every call.
- The official MCP Registry is still in preview (since 8 Sep 2025) and lists no private servers. Run a private registry and treat it as the allow list.
Why do tools matter more than the model?
A model on its own can only produce text, so an agent’s useful work, from looking up an order to creating a ticket, happens through tool calls, and the tool call is where the controls go. The model chooses the tool and fills in the inputs; your software runs it, checks it and hands the result back.
A tool is declared as a name, a natural-language description and a JSON Schema for its parameters. The description is what the model reads to decide when to call it, so it is prompt text and deserves the same review. The loop is the same on every vendor: the app sends the request plus the tool definitions, the model returns a structured call, the app executes it, the result goes back, and the model answers or asks for another call.
Tool count is the first thing that goes wrong. OpenAI’s guidance is fewer than 20 functions at the start of a turn, Google’s is 10 to 20 active tools, Anthropic says selection accuracy degrades past 30 to 50, and Microsoft 365 Copilot warns that quality may degrade beyond 10 functions. Anthropic measured five MCP servers at 58 tools and about 55,000 tokens of definitions before any work started (Anthropic, 24 Nov 2025). The answer every vendor shipped is tool search: tools are marked for deferred loading and the model searches for the ones it needs.
Computer use, where the model reads screenshots and drives a mouse and keyboard, is the fallback for systems with no API. It went generally available across vendors in 2026, and its documented drawbacks are cost (roughly 1,000 to 1,800 input tokens per screenshot on Claude), missed clicks on small targets, and a prompt-injection surface in whatever the screen shows. Use it last, in a VM with no credentials in reach.
How does MCP work?
MCP lets a system describe its tools, data and prompt templates once, as an MCP server, so that any MCP-capable agent can find and call them without a custom integration. A host application runs one client per server, and the two exchange JSON-RPC messages over stdio for a local server or Streamable HTTP for a remote one.
Servers expose tools (actions with a JSON Schema for inputs and, optionally, outputs), resources (readable data behind URIs) and prompts (reusable templates). The transports are stdio, which runs the server as a local subprocess, and Streamable HTTP, where each message is an HTTP POST to one endpoint and the reply comes back as JSON or as a server-sent event stream scoped to that request. HTTP+SSE was replaced in March 2025 and formally deprecated in July 2026.
The 2026-07-28 specification made the core stateless, the change most tutorials have not caught up with. There is no initialize handshake and no Mcp-Session-Id header. Every request carries its protocol version, client capabilities and client identity in _meta, so any request can land on any server instance behind a plain load balancer, and a mandatory server/discover call advertises what a server supports. A server that needs state hands the model a handle, such as a cart ID, which comes back as an ordinary argument. Server-to-client requests over a held-open stream are gone: the server returns input_required and the client retries the call with the input attached. Each POST carries Mcp-Method and Mcp-Name headers so gateways can route without parsing the body.
MCP specification revisions, with release dates from the spec repository.
| Revision | Released | What changed |
|---|---|---|
| 2024-11-05 | 25 Nov 2024 | Original protocol: stdio and HTTP+SSE transports, tools, resources, prompts, sampling, roots |
| 2025-03-26 | 26 Mar 2025 | OAuth 2.1 authorization; Streamable HTTP replaces HTTP+SSE; tool annotations; audio content |
| 2025-06-18 | 18 Jun 2025 | Server becomes an OAuth resource server with protected resource metadata; resource indicators required; structured tool output; elicitation |
| 2025-11-25 | 25 Nov 2025 | Client ID Metadata Documents recommended for registration; URL-mode elicitation; sampling with tools; experimental tasks; JSON Schema 2020-12 default |
| 2026-07-28 (current) | 28 Jul 2026 | Stateless core; server/discover; multi round-trip requests; Mcp-Method and Mcp-Name headers; tasks moved to an extension; dynamic client registration, roots, sampling, logging and HTTP+SSE deprecated; 12-month deprecation policy |
At release all four Tier 1 SDKs (TypeScript, Python, Go, C#) supported 2026-07-28, and Ruby reached Tier 1 on 29 Sep 2026. A client built for the current version falls back to the handshake protocol with an older server, and the lifecycle policy guarantees a 12-month deprecation window. The sub-page on what MCP is covers authorization for remote servers.
MCP vs function calling vs APIs vs A2A: which do you need?
You usually need three of the four. Function calling is how a model asks for a tool, MCP is how a tool is packaged so that any agent can discover and call it, your existing APIs stay underneath both, and A2A is for handing a whole task to another agent instead of calling a tool.
Four mechanisms that get confused with each other.
| Mechanism | What it is | Where the logic lives | Use it when |
|---|---|---|---|
| Function calling | The model-vendor feature that returns a structured tool call (OpenAI function_call, Claude tool_use, Gemini function_call) | Your code defines and runs the tool | One agent, tools you own, nothing to share |
| REST or OpenAPI API | A machine-to-machine contract with no model semantics | The system that owns the API | Always; MCP servers and gateways wrap it |
| MCP | An open standard for describing and calling tools, resources and prompts; stateless since 2026-07-28 | An MCP server, usually behind a gateway | Several agents or clients share the same tools, or you adopt a vendor’s server |
| A2A | An open standard for one agent to delegate a task to another; version 1.0.0 since 12 Mar 2026 | The remote agent, found through its Agent Card | Another team’s or vendor’s agent does part of the work and keeps its own state |
The A2A project’s own guide draws the line: MCP is vertical and deepens a single agent, A2A is horizontal and connects agents across a boundary. The sub-page on MCP vs A2A goes through the decision case by case.
What changed in the past year, and what does it mean for a rollout?
Three things changed between December 2025 and November 2026: the protocol went stateless, MCP and then A2A came under one neutral foundation, and every platform added a gateway and a registry. Each has a consequence for a company deploying agents this year.
Governance first. Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation on 9 Dec 2025, alongside goose from Block and AGENTS.md from OpenAI. Maintainers keep technical direction; the foundation handles budget, members and new projects. A2A joined on 27 Aug 2026, and by 22 Oct 2026 the foundation had 305 members and 10 projects.
The official MCP Registry is a different story. It launched in preview on 8 Sep 2025, its README reports an API freeze at v0.1 on 24 Oct 2025, and its documentation still warns that data resets may occur before general availability. It stores metadata only, never code, and lists no private servers. Enterprises are expected to run private sub-registries that pull from it; Azure API Center exposes a registry endpoint in that format, and AWS Agent Registry and Google Agent Registry hold MCP servers next to agents.
Vendor support is broad and uneven. Copilot Studio has had MCP generally available since 29 May 2025, and Microsoft 365 Copilot declarative agents take MCP servers as plugins. Azure API Management turns any managed REST API into an MCP server (tools only, generally available 18 Nov 2025). AgentCore Gateway converts OpenAPI, Smithy and Lambda targets into MCP tools and accepts four spec versions, from 2025-03-26 to 2026-07-28. OpenAI’s Responses API has called remote MCP servers since 20 May 2025 with approval required by default, and its connector IDs are deprecated for models released after 1 Sep 2026. Anthropic’s MCP connector is still beta; its September 2026 header pins each server’s tool list.
Three companies show what production looks like. Block said in June 2025 that it had built more than 60 internal MCP servers with one risk level per tool and OAuth with minimal scopes. Stripe runs a remote server with OAuth (its documentation cites the 2026-07-28 authorization spec) or scoped agent API keys, organisation-wide on and off switches, dashboard confirmation for sensitive actions, and a cutoff: full-access keys stop working on it after 30 Nov 2026. GitHub’s remote server has been generally available since 4 Sep 2025 and, after the stateless spec, removed its Redis session storage.
How do Microsoft, AWS and Google implement it?
The same capability, named the way each cloud names it, with statuses as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Tools in the agent platform | Foundry Agent Service: function calling, OpenAPI, MCP, A2A and catalogue tools; Copilot Studio: connectors, agent flows, MCP (GA 29 May 2025), computer use (GA May 2026) | AgentCore Gateway turns OpenAPI, Smithy and Lambda targets into MCP tools (GA 13 Oct 2025); Bedrock Agents Classic closed to new customers 30 Jul 2026 | Gemini API function calling with parallel and compositional calls; Agent Platform tools governed by Agent Gateway (GA 18 Jun 2026) |
| Publishing an MCP server | Azure API Management exposes any managed REST API as an MCP server, tools only (GA 18 Nov 2025); Azure MCP Server 1.0 (28 Oct 2025) | AgentCore Runtime hosts MCP servers; AWS MCP Server for any AWS API (GA 6 May 2026, two Regions) | Managed remote MCP servers for about 80 Google Cloud products, several preview; Workspace servers in developer preview |
| Gateway and policy on tool calls | API Management policies (Entra JWT, rate limits, IP filters, caching); Foundry Toolbox with tool search and credential passthrough | AgentCore Gateway inbound and outbound auth, semantic tool search; AgentCore Policy denies tool calls by rule (GA 3 Mar 2026) | Agent Gateway (GA 18 Jun 2026) with Model Armor (24 Jun 2026) and IAM Unified Access Policies covering MCP servers (GA 31 Aug 2026) |
| Private MCP registry | Azure API Center, with a registry endpoint in the official v0.1 format that VS Code and GitHub Copilot read | AWS Agent Registry holds MCP servers, tools and agents and exposes an MCP endpoint (GA 31 Aug 2026) | Agent Registry holds MCP servers, tools and A2A agents, enforced through Agent Gateway (GA 18 Jun 2026) |
| MCP versions accepted | Foundry MCP tool page (29 Oct 2026) lists no version; Copilot Studio keeps SSE transport in preview | AgentCore Gateway: 2026-07-28, 2025-11-25, 2025-06-18 and 2025-03-26 | Gemini Interactions API remote MCP: Streamable HTTP only, no SSE |
| Authorization to a tool | Foundry MCP tool: key, Entra identity, Entra user delegation or OAuth identity passthrough, with configurable approval | Gateway outbound auth: OAuth two-legged, three-legged and token exchange, IAM SigV4 or API keys | IAM allow and deny policies on managed servers; OAuth with PKCE for agents imported into Gemini Enterprise |
| A2A | Foundry a2a tool on A2A 1.0 (GA), a2a_preview on 0.3; Copilot Studio A2A GA April 2026 | AgentCore Runtime hosts A2A servers; the documented tutorial pins the 0.3 SDK; Gateway passes A2A traffic through | ADK agents consume and expose A2A natively; Agent Registry GA 18 Jun 2026 with A2A v1 agent cards |
The Foundry Toolbox as a whole carried no GA or preview label on 2 Nov 2026; skills inside it and MCP tasks through its endpoint are preview.
When should you not use MCP, and what goes wrong?
Do not wrap a system in MCP when one well-typed function in your own code does the job and only one agent will call it. Do not use A2A where a tool call would do; it adds state, latency and a second model’s judgment. Once MCP is in production, these are the ways it fails.
Tool poisoning, rug pulls and shadowing
Hidden instructions in a tool description are read by the model and invisible to the user; a server can change a description after approval, and one server’s description can change how the agent uses another’s tools. Invariant Labs described all three on 1 Apr 2025. Pin tool lists, and treat descriptions and annotations such as readOnlyHint as untrusted input, as Microsoft advises for the Foundry MCP tool and the MCP project said on 16 Mar 2026.
Toxic flows through tool results
On 26 May 2025 Invariant Labs showed a malicious public GitHub issue steering an agent with the official GitHub MCP server into leaking private repository data through a public pull request. No server patch fixes it: the danger comes from combining private data, untrusted input and an outbound channel.
Version drift and migration debt
Servers that depended on Mcp-Session-Id need rework for 2026-07-28. SSE-only servers are losing clients: Gemini’s Interactions API rejects SSE and Copilot Studio keeps it in preview. Azure API Management and Anthropic’s connector support tools only, so a server that relies on resources or prompts will not work through them.
Over-broad credentials and token passthrough
A Copilot Studio agent shared with maker-provided credentials lets anyone using it act with the maker’s access. A server that accepts or forwards a token issued for another service breaks audit, and the spec forbids it; the official TypeScript and Python SDKs shipped fixes in October 2026 for bearer authentication that accepted such tokens.
Malicious servers and local tooling bugs
CVE-2025-6514 (mcp-remote, CVSS 9.6) gave a malicious server command execution on Windows; CVE-2025-49596 (MCP Inspector, CVSS 9.4) let a web page drive an unauthenticated local proxy. An impostor npm package, postmark-mcp 1.0.16, copied every email to an attacker before removal. Asana’s own server exposed data across about 1,000 customers in mid-2025. The MCP security sub-page lists the advisories and fixes.
What should you set up?
The controls that make MCP safe to run at company scale, in the order we install them.
- A gateway in front of every remote MCP server (Azure API Management, AgentCore Gateway, Google Agent Gateway, or open source such as Docker MCP Gateway or agentgateway), with no direct agent-to-server connections from production.
- Two allow lists per agent: which servers it may reach, and which tools on each server.
- Pinned tool lists, so a server cannot change a tool after approval (Anthropic’s mcp-client-2026-09-15 header, a static mcpToolSchema on AgentCore Gateway), with a review whenever a server version changes.
- Authorization as the 2026-07-28 spec requires: protected resource metadata on the server, PKCE and the resource parameter in the client, audience validation, no forwarding of another service’s token, and Client ID Metadata Documents for client registration (dynamic registration is deprecated and kept only for authorization servers without CIMD support).
- Minimal scopes with step-up: ask for the least scope first and let the server challenge for more through WWW-Authenticate. Separate credentials for development and production servers.
- Approval for anything that writes or pays: require_approval on OpenAI and Foundry, the confirmation Microsoft 365 plugins ask for before data-modifying calls, and vendor-side confirmation where it exists.
- A private registry as the allow list of servers (Azure API Center, AWS Agent Registry or Google Agent Registry), with the gateway reading only approved entries, plus Defender for Endpoint discovery of local MCP server configurations.
- Patching and hygiene: pin SDK versions, keep DNS rebinding protection on for local servers, block private IP ranges in OAuth discovery, and show the exact command before a one-click local install.
Enterprise example · Worked example · illustrative
A 9,000-person insurer puts 14 MCP servers behind one gateway
Illustrative scenario. A property and casualty insurer with 9,000 staff, a Microsoft 365 tenant, agents in Copilot Studio and Microsoft Foundry, a policy administration system, a claims platform and SAP.
The trigger was a Defender for Endpoint report: 31 local MCP server configurations on 19 developer laptops, most started with personal API keys. Nobody had decided which servers were allowed, so the first rule was that production agents reach tools only through Azure API Management, and a server with no record in Azure API Center is unreachable from an agent.
The platform team exposed eight internal REST APIs, from policy lookup to address validation, as MCP servers in API Management, with Entra JWT validation, rate limits and IP filtering on each. Four vendor servers, including GitHub’s, were proxied through it. Two in-house servers on the private network were fronted by the same API Management instance over a VNet, so all 14 passed the same policies. That made 14 servers, each with an owner and a record in API Center.
Each agent got a Microsoft Entra Agent ID and an allow list naming the servers and tools it may call. Tools were tiered: tier 1 reads run without a prompt; tier 2 writes to non-financial systems go through require_approval in the Foundry MCP tool; tier 3, anything that moves money, is drafted by the agent and executed by a person in the claims system. The evaluation gate added 12 injection cases to the 60 claim scenarios each agent must pass.
Six months in, the gateway log answers the audit question (which agent called which tool, under which identity, with which scope). Two vendor servers changed their tool lists in that time; the pinned list caught both and the owners re-reviewed them within a day.
- Gateway
- Azure API Management for all 14 servers, the two internal ones reached over a VNet
- Owner
- Named owner per MCP server in Azure API Center; named owner per agent in the Agent 365 registry
- Identity
- Microsoft Entra Agent ID per agent; tokens audience-bound to one server; no maker-provided credentials
- Allow list
- Servers and tools per agent; registry entries only; tool lists pinned and re-reviewed on change
- Risk tier
- Three tiers by what a tool does: read, non-financial write, money movement
- Approval
- require_approval on tier 2 tools; tier 3 actions drafted by the agent and executed by a person
- Monitoring
- Gateway logs with agent identity and scope; Application Insights traces; injection cases in every evaluation run
- Retirement
- A deprecated server keeps its record for 90 days with calls blocked at the gateway, then the record and identity grants are removed
How do you start?
- Inventory the MCP servers already in use: Defender for Endpoint local discovery, the configuration files of VS Code, Claude Code and Cursor on developer machines, and your proxy logs.
- Pick the gateway for each cloud you run and route every production tool call through it. A direct connection from an agent to a server needs a written exception.
- Write the tool policy on one page: allow lists per agent, approval for writes, scopes per tier, who reviews a server change.
- Move authorization to the 2026-07-28 model: protected resource metadata on each server, PKCE and resource indicators in each client, audience validation and no token passthrough.
- Stand up the private registry; the gateway reads only approved entries.
- Add injection cases to the evaluation gate: a poisoned ticket, a public issue with hidden instructions, an email that asks the agent to call a tool.
- Review after Microsoft Ignite and AWS re:Invent in late 2026, and re-check which spec versions your gateway accepts.
Frequently asked questions
Is MCP the same as function calling?
No. Function calling is the model-vendor feature that returns a structured tool call for your code to run. MCP is an open standard for packaging tools, resources and prompts as a server that any MCP-capable client can discover and call.
Which MCP specification version should we build on?
2026-07-28, the current version on 2 Nov 2026. It is stateless, requires server/discover, deprecates HTTP+SSE, dynamic client registration, roots, sampling and logging, and moves tasks into an extension. Clients built for it fall back to the older handshake protocol during a migration.
Is an MCP server secure enough for enterprise use?
It can be, with controls outside the protocol. The 2026-07-28 authorization rules (audience-bound tokens, no passthrough, PKCE) address the token-level risks where a server implements them; the remaining risks, tool poisoning and injection through results, are handled by a gateway, pinned tool lists, allow lists and approval for writes. The MCP security sub-page lists the incidents.
Do we need A2A as well as MCP?
Only when another team’s or vendor’s agent does part of the work and keeps its own state. A2A gives you discovery through an Agent Card, a task with a lifecycle, and streaming or push updates. If the other side can be a stateless tool, an MCP tool or an API is simpler to govern.
What is an MCP gateway, and how is it different from an MCP server?
An MCP server exposes one system’s tools. A gateway sits in front of many servers and applies policy to every call: authentication, allow lists, approval, rate limits and logging, often with tool search across all of them. Azure API Management, AgentCore Gateway and Google Agent Gateway are the managed options.
Should we use the official MCP Registry?
Use it as a source, and run your own. It has been in preview since 8 Sep 2025, holds metadata only, lists no private servers and warns that data resets may occur before general availability. Azure API Center, AWS Agent Registry and Google Agent Registry all serve as the private sub-registry it expects.
Does Microsoft 365 Copilot support MCP?
Yes, in two places. Copilot Studio has had MCP generally available since 29 May 2025 (generative orchestration required, SSE in preview). Microsoft 365 Copilot declarative agents take MCP servers as plugins, where read-only calls skip confirmation after first consent and data-modifying calls ask the user.
In this topic
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Model Context Protocol specification changelog, 2026-07-28
- The 2026-07-28 specification
- Authorization, specification 2026-07-28
- Transports, specification 2026-07-28
- Security best practices, 2026-07-28
- Specification versioning
- Specification releases
- Extensions overview
- Enterprise-Managed Authorization is stable
- Tool annotations as a risk vocabulary
- About the MCP Registry
- Introducing the MCP Registry (preview)
- MCP joins the Agentic AI Foundation
- Agentic AI Foundation surpasses 300 members in less than one year
- A new chapter for A2A: joining the Agentic AI Foundation
- A2A protocol specification, version 1.0.0
- A2A and MCP
- Function calling guide
- Connectors and MCP guide
- Advanced tool use
- Tool search tool
- Computer use tool
- MCP connector
- Gemini function calling
- Gemini API changelog
- Announcing official MCP support for Google services
- MCP servers: supported products
- Gemini Enterprise Agent Platform release notes
- Scaling AI agent infrastructure with the MCP stateless updates
- Expose a REST API as an MCP server in Azure API Management
- Register and discover MCP servers in Azure API Center
- Model Context Protocol tool in Foundry Agent Service
- Foundry Toolbox overview
- Agent-to-agent tool in Foundry Agent Service
- Model Context Protocol is now generally available in Microsoft Copilot Studio
- Computer use in Copilot Studio
- What’s new in Copilot Studio
- MCP and API plugins for Microsoft 365 Copilot
- Microsoft 365 Copilot connectors overview
- Local AI agent discovery (Defender for Endpoint)
- Amazon Bedrock AgentCore Gateway
- MCP server targets for AgentCore Gateway
- AWS MCP Server is now generally available
- Agent-to-agent protocol support in AgentCore Runtime
- Amazon Bedrock Agents Classic maintenance mode
- MCP security notification: tool poisoning attacks
- GitHub MCP exploited: accessing private repositories via MCP
- Block’s playbook for designing MCP servers
- Stripe Model Context Protocol server
- Remote GitHub MCP Server is now generally available
- CVE-2025-6514: critical mcp-remote vulnerability
- CVE-2025-49596: remote code execution in MCP Inspector
- First malicious MCP server found in the wild (postmark-mcp)
- Asana warns MCP AI feature exposed customer data to other orgs
- TypeScript SDK security advisories
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner