Choose the contract for each interaction

Learning objective

Distinguish agent-to-agent messaging from agent-to-tool interoperability.

Core idea

For an architect connecting independently owned systems, choose the contract by what the remote side promises. An agent accepts a task or message and owns how to produce its result. A tool exposes a named operation with defined inputs and outputs. Agent2Agent (A2A) and Model Context Protocol (MCP) standardize different interaction models for those responsibilities.

The implementation behind an endpoint does not decide its protocol. A tool can internally use a model, and an agent can expose a tool interface. Foundry can also present an A2A connection to the calling model as a tool. Identify the external contract and responsibility first, then select the integration. See 1.2.2 for placing these integrations among other architecture components.

How it works

Delegate work through an agent contract

A2A supports communication between independent agent systems without requiring access to their internal state, memory, or tools. An Agent Card describes capabilities and interaction requirements. The receiving agent controls its own internal execution while the caller manages the larger user request.

The specification’s Send Message operation accepts a SendMessageRequest and returns either a Task or a direct Message. A task represents processing with a tracked lifecycle; a direct message suits an interaction that does not need task tracking. The Get Task operation retrieves the state and artifacts of an existing task. An artifact is an output of the delegated work, rather than the remote agent’s complete internal working state.

The taskId and contextId fields serve different purposes. A task identifier addresses a particular task. A context identifier supports continuity across related interactions, including another task in the same context. Neither should be treated as proof of caller authorization. The protocol defines references and behavior; an authenticated integration still has to enforce access.

General A2A capabilities do not imply support in every implementation. For example, the specification makes streaming depend on AgentCard.capabilities.streaming. Check the target’s declared capabilities and its hosting platform’s constraints before designing progress delivery. Do not select an interaction solely because the protocol specification describes it.

Invoke operations through a tool contract

MCP standardizes how a host connects to servers providing tools and contextual data. In its tool interface, a client uses tools/list to discover operations and tools/call to invoke a named operation with arguments. A tool definition contains name, a description, and an inputSchema; it can also provide an outputSchema for structured output.

These schemas define the operation contract. A tool called lookup_invoice should expose the identifiers it accepts and the result it returns. It does not automatically accept responsibility for the broader objective “resolve this disputed invoice.” The host or agent decides when to call it and what to do with its observation, as described in 0.4. Runtime validation of these structures is covered in 0.10.

MCP distinguishes protocol errors from tool-execution errors. A malformed request or an unknown tool can produce a JSON-RPC error. A tool that executes but encounters an application failure reports isError: true in its result. Receiving a protocol response therefore does not prove that the requested business operation succeeded. Side by side, an A2A caller hands over work and gets back a task or a message, while an MCP client invokes a named operation and gets back a result, an error result or a protocol error.

MCP is not synonymous with “fast, synchronous function.” Its specification and extensions can include longer-running behavior. Foundry’s long-running MCP operations and toolbox MCP task support are documented as preview. That capability does not turn an MCP operation into an A2A delegation contract or justify assuming every host supports it.

Map the contracts into Foundry

Foundry exposes remote-agent calls through its A2A tool integration; for tool definitions and their version and status mapping, see 1.2.2.

For a Foundry agent target, incoming A2A must be enabled and the calling identity needs the Foundry Agent Consumer role or higher on the target project. The documented Foundry target supports text modality and does not support streaming responses; its version 1.0 binding uses JSON-RPC. Incoming A2A also requires the agent to use the responses protocol. Those are Foundry implementation constraints, not universal A2A protocol restrictions.

Foundry serves both A2A versions on the same base path. A request with neither the A2A-Version header nor the a2a-version query parameter defaults to preview v0.3. Select generally available v1.0 explicitly with A2A-Version: 1.0, ?a2a-version=1.0, or a client that fetches the …/agentCard/v1.0 card and negotiates that version. If header and query selectors conflict, Foundry returns HTTP 400 with the version-ambiguous problem type.

Foundry connects to remote MCP servers using MCPTool, with settings including server_url and server_label. Authentication through a project connection is separate from the server’s operation definitions. Approval configuration is another distinct decision; the Microsoft example sets require_approval="always". An operation’s availability in tools/list neither authenticates a caller nor constitutes approval to execute it.

Foundry’s classic Connected Agents tool is unavailable in the Foundry Agent Service API documented by these pages. The documented alternatives include A2A connections and workflows. Do not assume the classic tool name remains a supported integration merely because a remote agent exists. Local orchestration and remotely interoperable agent messaging also serve different needs; see 0.5 and 1.1.3.

Key distinctions and trade-offs

Compare what each contract puts under the caller’s control:

Delegation can reduce coupling to a specialist’s internal toolchain, but adds another owner whose result you must evaluate. A tool contract provides a narrower interface, but leaves the larger reasoning and orchestration with the caller. Neither protocol automatically grants shared memory, user permissions, or a successful outcome.

Architecture / decision scenario

An order-support agent needs two capabilities: retrieve an order’s shipping status and ask a supplier’s specialist to investigate a disputed delivery. The shipping service exposes a named lookup with a fixed identifier contract. The supplier operates its own agent, which can investigate and request further information.

The team uses MCP for the lookup. It verifies the tools/list definition, sends tools/call with the required arguments, and handles isError separately from protocol failure. The lookup’s returned record is an observation; the calling agent still owns its response to the customer.

For the supplier investigation, it uses A2A and treats the remote result as delegated work. It retains task and context references rather than assuming both identifiers describe the same thing. If the target is a Foundry agent, the team enables incoming A2A, grants the calling identity Foundry Agent Consumer, confirms that the target uses the responses protocol, and selects v1.0 explicitly with A2A-Version: 1.0. It does not promise the customer a streaming remote response that the Foundry target does not support.

The supplier agent happens to call MCP tools internally. That does not change the support agent’s A2A contract or reveal the supplier’s private state. If the investigation produces an artifact, the support application evaluates it before declaring the dispute resolved. Remote task completion and business acceptance remain separate outcomes.

Common exam traps

• Choosing a protocol solely because the endpoint internally uses an LLM.
• Treating an A2A connection presented as a Foundry tool as an MCP-only interaction.
• Assuming an Agent Card transfers the remote agent’s memory or internal tools.
• Treating taskId and contextId as interchangeable or as authorization credentials.
• Assuming every A2A implementation supports streaming because the specification defines it.
• Assuming an unversioned request to a Foundry A2A base path selects v1.0 instead of defaulting to preview v0.3.
• Interpreting a successful MCP protocol exchange as successful tool execution.

What to remember

A2A delegates work to an independently controlled agent. MCP makes named tools interoperable with a host. Read the external contract, verify the implementation’s capabilities, and keep identity, approval, task completion, and business acceptance as distinct decisions.

Knowledge check

References

• A2A Project, Agent2Agent protocol specification
• Model Context Protocol, Tools
• Microsoft, Connect to an A2A agent endpoint from Foundry Agent Service
• Microsoft, Connect agents to MCP server endpoints
• Microsoft, Enable an A2A endpoint for a Foundry agent