MCP · A2A · interoperability
Connecting AI is becoming easier. Controlling the connections is becoming harder.
MCP is standardising how AI applications connect to tools, resources and prompts. A2A is standardising how remote agents discover and communicate with one another. Those standards can reduce integration friction. They do not remove the need for company policy, identity, permissions or human authority.
Connectivity is not authority.
Enterprise interoperability control plane
Company policy
Identity · data · permissions · action rights · approval
TEMRIK control plane
Policy and authority over protocol connections
MCP
Tools + resources + prompts
A2A
Agents + tasks + messages
What interoperability means
Interoperability is the ability to connect without rebuilding every integration from zero.
In enterprise AI, that can mean a model using a standard tool interface, an application discovering a standard resource, or one agent communicating with another agent built by a different team or framework.
The benefit is portability. The new challenge is governance. A protocol can describe how a connection works while remaining intentionally agnostic about whether your company should permit that connection for a particular user, tenant, dataset, action or workflow.
Model Context Protocol
MCP standardises how AI applications connect to external context and capabilities.
The current specification describes communication between a host application, clients inside that host, and servers that provide context or capabilities. Servers can expose resources, prompts and tools through a common protocol rather than every application inventing a bespoke connector.
Read the official MCP specificationHOST
The LLM application that owns the user experience and initiates protocol connections.
CLIENT
The connector inside the host that communicates with an MCP server.
SERVER
The service that exposes context and capabilities.
MCP primitives
Tools, resources and prompts solve different integration problems.
MCP primitive
Tools
Functions a model or agent can discover and invoke, such as querying a system, running a calculation or performing an API action.
MCP primitive
Resources
Context and data exposed by a server for an application or model to use.
MCP primitive
Prompts
Reusable templated messages or workflows exposed by a server.
A tool being discoverable does not mean every agent should be allowed to call it.
The MCP specification itself emphasises user consent, data privacy, tool safety and the ability for humans to deny tool invocations. Enterprise policy should therefore decide which tools are visible, which scopes are granted and which operations require approval.
MCP security
Connection layer
Protocol security
For protected remote MCP servers, current MCP authorization is based on OAuth patterns and protected-resource discovery.
Business layer
Operational authority
OAuth can prove and scope access. It does not decide whether a particular business action is commercially, legally or operationally authorised.
Authentication answers who may connect. Governance answers what they may do.
Agent2Agent Protocol
A2A 1.0
A2A standardises how remote agents discover each other and exchange work.
A2A is useful where agents live across different processes, frameworks, languages, teams or organisations. Instead of one application importing another agent directly, a client can discover a remote agent's declared interface and communicate using the protocol.
Read the official A2A 1.0 specificationAgent Card
Discovery metadata describing the remote agent, its interfaces, capabilities and security declarations.
Message
A unit of communication sent to or returned by an agent.
Task
The core unit of action for work that has state, history and potentially a longer lifecycle.
Artifact
A result produced by a task, represented as one or more content parts.
How A2A work moves
Discover
Resolve a known endpoint, Agent Card or enterprise registry.
Authenticate
Establish the caller identity and permitted security scheme.
Send message
Provide intent, context and task input.
Track task
Observe submitted, working, completed, failed, rejected or input-required states.
Receive artifact
Consume the result while preserving provenance and policy context.
A2A Agent Cards can describe capabilities and security requirements. That helps discovery and compatibility. Enterprises still need independent trust policy before accepting a remote agent as an authorised actor.
MCP vs A2A
They solve adjacent problems. They are not substitutes.
MCP
Agent or model application to capability.
Use MCP when an AI application needs a standard way to discover and use tools, resources or prompts.
A2A
Agent to remote agent.
Use A2A when independent agents need a standard mechanism for discovery, messages, tasks and returned artifacts.
TEMRIK architecture position
Put policy and authority over both connection types.
Policy before protocol
A protocol request should pass through business rules before it becomes business action.
Who is the requesting human or machine actor?
Which tenant and company boundary applies?
What data class is involved?
Which server or remote agent is trusted?
Which tool, capability or task is actually requested?
What scope and credentials are permitted?
Can data leave the company boundary?
Can the action change an external system?
Does the action require human approval?
What evidence must be recorded?
Permission model
The useful unit of control is not “MCP allowed” or “A2A allowed.”
Enterprise permission should be more specific than the transport.
Actor
User, agent, service identity
Target
MCP server, tool or A2A agent
Data
Public, internal, confidential, restricted
Operation
Read, prepare, write, execute, delegate
Scope
Tenant, project, account, record set
Consequence
Low, bounded, material
Approval
None, role-based, named human
Evidence
What must be retained
Security controls
Identity before capability
Authenticate the human, workload or agent before granting a protocol connection.
Allowlist before discovery
Do not expose every server, tool or remote agent merely because it can be discovered.
Least privilege
Limit credentials, scopes, data access and tool availability to the job being performed.
Trust the server, not its prose
Treat remote tool descriptions, annotations, Agent Cards and returned content as inputs to verify, not as authority.
Approval for consequence
Sensitive write actions should be gated outside the model where the business requires explicit authority.
Evidence by default
Record material protocol events, policy outcomes, approvals, tool calls and released actions without logging secrets unnecessarily.
Vendor independence
Open protocols can reduce integration lock-in. They do not make every provider interchangeable.
OpenAI, Anthropic, Microsoft and AWS now document MCP support in different forms, while Microsoft and AWS also document A2A integrations. This is evidence of an increasingly interoperable ecosystem, not evidence that every host implements every feature identically.
Production architecture still needs to account for provider-specific authentication, transport support, approval models, session semantics, quotas, observability, data handling and feature maturity.
Enterprise patterns
There is no single correct interoperability topology.
Direct connection
One approved application connects to one approved MCP server or A2A agent. Simple, but policy is distributed.
Gateway / broker
Connections pass through a controlled intermediary that can authenticate, filter, observe and apply policy.
Registry + policy
Approved servers, agents, capabilities and metadata are catalogued; policy determines what each actor may discover or invoke.
Federated control
Different business units operate their own integrations while company-wide identity, risk and evidence rules remain consistent.
TEMRIK control plane
Architecture direction
TEMRIK is designed to make interoperability subordinate to company authority.
The design principle is not to replace MCP or A2A. It is to put a durable company policy layer around whichever standards, models, agents and tools a business chooses to use.
This is an architecture direction. Exact protocol support, providers, gateways and enforcement mechanisms depend on the production implementation.
Control sequence
How the pages fit together
Agentic AI
How agents reason, use tools, maintain state and coordinate.
AI Security
How company data, identity, providers and permissions are bounded.
Human Control
How consequential action remains subject to human authority.
How TEMRIK works
How company context, control and action fit into one operating architecture.
Research basis
Built from current protocol specifications and primary provider documentation.
Protocols evolve quickly. These sources were checked for this page and should be re-checked when designing a production interoperability boundary.
Model Context Protocol
MCP 2026-07-28 specification
Authoritative MCP architecture, features, security principles and current protocol requirements.
Primary sourceModel Context Protocol
MCP tools specification
How MCP servers expose model-invoked tools, schemas, listing, calls and tool-safety expectations.
Primary sourceModel Context Protocol
MCP authorization
OAuth-based authorization requirements, protected-resource metadata and discovery for protected MCP servers.
Primary sourceA2A Protocol
Agent2Agent Protocol 1.0 specification
Agent Cards, messages, tasks, artifacts, protocol bindings, authentication and security considerations.
Primary sourceOpenAI
MCP servers
Remote MCP support, allowed tools, approvals and explicit guidance to treat remote MCP servers as a security boundary.
Primary sourceAnthropic
Model Context Protocol
Anthropic documentation for MCP as an open standard for connecting applications, context and tools.
Primary sourceMicrosoft
Agent-to-Agent in Agent Framework
A2A for communication across process, framework, language and organisational boundaries.
Primary sourceAWS
AgentCore supported protocols
Current AgentCore support for HTTP, MCP, A2A and AG-UI protocol contracts.
Primary sourceFree field guide
27 Rules of Peace
Connection standards are useful. Operating rules decide whether the connection is safe to use.
The free TEMRIK field guide explores playbooks, evidence, escalation and human decision rights for AI-assisted work.
Map the interoperability layer
Give AI access to the capabilities it needs. Keep the company in control of what those capabilities can do.
Map one workflow across users, agents, MCP servers, remote agents, tools, data classes, permissions, approvals and evidence.
TEMRIK does not claim universal MCP or A2A compatibility on this page. Protocol and provider support are implementation-dependent and should be verified for each production deployment.