The acronym is the first architecture test. If a meeting begins with “ACP” and nobody expands it, pause. In today's agent ecosystem, ACP can refer to more than one protocol, and those protocols solve different problems.
For teams building with Kiro, ACP means Agent Client Protocol. It standardizes the connection between a user-facing client, such as an IDE, and a coding agent. MCP means Model Context Protocol. It standardizes how an AI host and its clients use capabilities exposed by servers. The older IBM Agent Communication Protocol addressed agent-to-agent communication, but IBM states that project is part of A2A under the Linux Foundation [3]. There is also an Agentic Commerce Protocol in the market, which belongs to commerce workflows and is outside the scope of this article.
This article targets the current MCP specification dated 2026-07-28. That revision replaced the earlier connection-scoped handshake and session model with a stateless core: each request carries protocol metadata and capabilities, and an optional server/discover call lets clients inspect server capabilities in advance [1][8]. Implementations that still support older MCP revisions need an explicit compatibility path rather than assuming the two eras behave the same [7][8].
The distinction is more than vocabulary. It tells you where a protocol belongs in the system:
- MCP connects an agentic application to capabilities.
- Agent Client Protocol connects an interactive client to a coding agent.
- A2A connects independent agents when work must cross an agent boundary.
- APIs and events remain the right choice when the interaction is deterministic and does not need agent discovery.
Once those boundaries are clear, MCP and ACP stop looking like competing standards. They become complementary parts of an enterprise agent architecture.
The Clean Mental Model: Experience, Capability, and Delegation
MCP follows a host-client-server architecture. The host manages the AI experience and security decisions, each client communicates with exactly one server, and servers expose focused capabilities such as tools, resources, and prompts [1]. In the 2026-07-28 core, every request is self-contained and carries its protocol version and client capabilities. A client may call server/discover first, but discovery is optional [1]. That structure answers a practical question: which capabilities can this AI host access through each server boundary?
Stateless at the protocol layer does not mean stateless at the application layer. When a workflow needs continuity, the current MCP guidance is to make application state explicit, such as returning a workflow handle that a later tool call supplies as an argument, instead of hiding state in transport-session metadata [8].
The current core also removes server-initiated JSON-RPC requests. When a server needs client input during a request, Multi Round-Trip Requests return an input-required result and the client retries the original call with the requested input. Long-running tool work can use the separately negotiated Tasks extension [8]. These mechanisms support request completion; they do not turn MCP into a general agent-to-agent delegation protocol.
Agent Client Protocol answers a different question: how can a client application interact with a coding agent without a custom integration for every pairing? The protocol covers sessions, prompts, streaming updates, tool calls, permission requests, file access, and terminal interactions. Its role resembles the Language Server Protocol pattern: a common connection lets clients and agents evolve independently [2].
Delegation is a third boundary. When one independently deployed agent must discover another, assign a task, exchange artifacts, or track a long-running job, use an agent-to-agent protocol such as A2A. Do not force MCP to impersonate a multi-agent task protocol. Do not use editor-oriented ACP as a generic enterprise message bus.
| Architecture question | MCP | ACP: Agent Client Protocol | A2A |
|---|---|---|---|
| What does it connect? | AI host to tools, data, resources, and prompts | Editor or client experience to a coding agent | Independent agent to independent agent |
| Best fit | Capability discovery and invocation | Interactive coding-agent experiences | Cross-agent delegation and task exchange |
| Typical boundary | AI host/client to a focused capability server | IDE, CLI, web, or mobile client to agent harness | Team, runtime, vendor, or trust boundary |
| Avoid using it for | General distributed workflow state | Tool catalogs or arbitrary business integrations | Simple tool calls that belong behind MCP |
Choose only the protocols the workflow needs. A single assistant that reads a CRM and opens a ticket may need only MCP. A coding agent embedded in several editors may need ACP and MCP. A network of specialist agents owned by different teams may add A2A.
Kiro Shows How ACP and MCP Fit Together
Kiro offers a useful reference architecture because both protocols appear in one product without doing the same job.
Kiro documents one unified agent harness behind its IDE, CLI, web, and mobile experiences. Those clients talk to the harness through Agent Client Protocol. The harness manages conversation state, model access, permissions, context, tool execution, and agent behavior. Local Kiro clients connect over stdio, while its web and mobile surfaces connect to a sandboxed harness over WebSocket [4]. These are ACP and product-level session details, not MCP protocol sessions.
MCP sits on the capability side of that harness. When a developer connects an AWS documentation server, a project tracker, or an internal engineering service, MCP can add those capabilities to the agent's available tool and context set. Kiro's ACP documentation makes the layering visible: ACP session updates can report tool calls, while Kiro-specific ACP extensions report MCP-related OAuth and server-availability events [4].
Think of the flow this way:
Developer in an editor -> ACP -> Kiro agent harness -> policy and permission checks -> MCP -> approved engineering capability
ACP can make the agent experience portable across compatible clients. MCP can make external capabilities reusable across compatible AI hosts. The harness is the control point that joins the two in this Kiro example.
This separation helps platform teams avoid a common mistake: embedding every integration directly into every user interface. If a Jira action is coded into an editor plug-in, another client must rebuild it. If the action is exposed as a governed MCP tool, Kiro can discover it through the harness and another compatible, authorized MCP client may be able to reuse it.
Amazon Quick Extends the Same Capability Fabric to Business Teams
Amazon Quick demonstrates the other side of the architecture. It is a business-facing AI experience, not a coding editor, so Agent Client Protocol is not the relevant integration boundary. MCP is.
AWS documents that Amazon Quick can connect to remote MCP servers and register each exposed tool as an action that its AI assistant can invoke in a conversation [5]. A project management MCP server, for example, can let a user create a ticket, retrieve an issue, or update status without a one-off connector for each conversational experience.
Quick supports MCP servers reachable on the public internet and private servers reachable through an Amazon Quick VPC connection. Private servers can run in a connected VPC or on premises through Direct Connect or VPN. AWS also documents user OAuth, service-to-service authentication, PKCE, and resource indicators. Quick supports remote MCP connections rather than local stdio servers, and its documentation prefers HTTP streaming over the earlier SSE approach [5].
Compatibility still needs testing. The 2026-07-28 MCP specification deprecates Dynamic Client Registration in favor of Client ID Metadata Documents, while the current Amazon Quick documentation says automatic client registration supports DCR and does not yet support Client ID Metadata Documents [5][8]. Treat the client, server, authentication method, and protocol revision as an explicit compatibility matrix.
Now place Kiro and Quick over the same governed capability layer:
- A developer uses Kiro to inspect an incident, propose a code change, and open a remediation task.
- A product manager uses Quick to review the same incident's customer impact and update priority.
- A designer uses an approved research or design-system capability to retrieve the affected journey and attach acceptance evidence.
- An operator uses the same incident capability to verify deployment status and record the recovery timeline.
These users should not receive identical permissions. They should reuse the same capability contract with identity-aware authorization, action-level policy, and role-specific views. Reuse belongs at the tool and evidence layer, not at the permission layer.
That is the beginning of a shared capability fabric: one catalog of trusted actions available through several agent experiences, with policy deciding who can see and invoke each action.
Make MCP Tools Product Interfaces, Not Thin API Wrappers
A direct way to create an unwieldy MCP estate is to expose each REST endpoint as a separate tool. The model may see a crowded catalog, tool descriptions consume context, and users inherit internal API complexity.
AWS Prescriptive Guidance recommends designing tools around complete user workflows, particularly when several API operations commonly belong together. It also recommends splitting tools that grow beyond one user intent or require too many parameters [6]. That guidance supports a broader design principle: treat an MCP tool as a product interface for an agent.
The 2026-07-28 specification also expands tool schemas to full JSON Schema 2020-12, while retaining an object root for input schemas. That gives teams more expressive contracts, but it does not remove the need to test schemas against the specific clients in scope [8]. For example, Amazon Quick currently documents validation against JSON Schema Draft 7 or later and publishes additional connector limitations [5].
A production-tool review can define:
- 1User intent. State the outcome in language a person would use, such as “prepare release readiness evidence,” not the underlying endpoint name.
- 2Authority. Identify which human or workload identities can discover and invoke the tool, and which parameters are further restricted.
- 3Contract. Use a narrow schema, bounded values, useful descriptions, and versioned behavior.
- 4Risk class. Separate read, draft, reversible write, irreversible write, and regulated-data actions.
- 5Evidence. Return source identifiers, timestamps, status, and enough structured output to verify what happened.
- 6Failure behavior. Define timeouts, retries, idempotency, partial success, and escalation rather than returning an ambiguous paragraph.
- 7Operational target. Assign an owner, service level, cost budget, and deprecation process.
The distinction between discovery and permission is especially important. Hiding irrelevant tools improves selection quality, but discovery filtering alone is not authorization. The server or gateway must enforce the caller's rights again at invocation time.
A Collaboration Model for Product, Design, Engineering, and Operations
Protocols create interoperability. They do not create collaboration on their own. Cross-functional teams need a shared artifact model that turns a business intent into a traceable capability release.
Start with a capability brief owned by product. It defines the user, desired outcome, source systems, allowed actions, success measure, and explicit non-goals. The brief is small enough to review and precise enough to become acceptance criteria.
Design then defines the interaction and evidence contract. Which information should be visible before a tool runs? Where must the user approve? How does the experience display a draft, a completed action, a partial failure, or a denial? The designer is not decorating an agent transcript. They are specifying how human judgment enters the workflow.
Engineering implements the protocol contracts. ACP carries the interactive coding session where appropriate. MCP exposes the approved enterprise action. A2A is added only if responsibility genuinely crosses to another independently operated agent. The developer also supplies contract tests, policy tests, idempotency behavior, and observable events.
Security owns the decision points, not a late-stage checklist. It defines identity propagation, least-privilege scopes, data boundaries, approval thresholds, server allowlists, credential handling, and incident controls. A remote MCP server that can write to a system of record should never depend on a model prompt as its authorization layer.
Operations owns the runtime evidence. Material interactions should carry a common correlation ID from the user or agent request to the MCP invocation, downstream system, and result. Teams can track latency, success, denial, cost, and human-intervention signals segmented by capability version. Without that chain, an agent may complete a task while the organization remains unable to reconstruct what changed.
The resulting delivery path is simple enough to repeat:
Brief -> experience contract -> tool contract -> threat model -> evaluation set -> staged release -> runtime evidence -> product review
This is how different disciplines develop one capability without handing documents across organizational walls. Each role contributes to the same versioned object and evaluates the same business outcome.
Security and Reliability Practices That Survive Production
Local MCP servers deserve the same scrutiny as any executable installed on a developer machine. Kiro warns that a local stdio server can run with the environment's privileges and may access source code, environment variables, secrets, and credentials. Review the package, pin versions, restrict available credentials, and prefer a managed remote server when central policy and shared operations matter [4].
When an implementation uses the MCP HTTP authorization flow, the 2026-07-28 specification requires protected-resource metadata, resource indicators, and validation that a token was issued for the MCP server receiving it. It also prohibits passing the inbound MCP token through to an upstream service [9]. Authorization is optional in MCP overall, so local stdio and other transport choices follow different credential guidance [9].
For remote MCP and ACP connections, apply a production baseline:
- Authenticate people and workloads separately. A service token should not silently inherit a user's business authority.
- Default to deny. Allow read tools first, require explicit policy for writes, and put human confirmation in front of high-impact or irreversible actions.
- Validate both directions. Inspect tool arguments before execution and outputs before they enter model context. Treat retrieved text as untrusted data because it may contain prompt injection.
- Keep credentials out of protocol payloads. Use a secret manager, short-lived credentials, OAuth where supported, and server-bound tokens.
- Version schemas and pin clients. Per-request capability declarations do not replace compatibility testing. Run contract tests against each supported client, server, and protocol revision.
- Make writes idempotent. Retries should not open duplicate tickets, charge a customer twice, or apply the same infrastructure change again.
- Separate environments. Development agents should not discover production write tools by default. Use different server registrations, identities, and policy sets.
- Trace decisions and effects. Log the requesting identity, agent, model, tool version, policy decision, arguments hash, downstream result, latency, and cost without copying sensitive payloads into every telemetry store.
MCP's official architecture gives the host responsibility for connection permissions, consent, authorization decisions, and context aggregation [1]. The 2026-07-28 revision also makes Streamable HTTP requests self-describing and mirrors method and tool names into headers for routing and policy enforcement, while the message body remains the source of truth [7][8]. Enterprises should treat these as explicit control-plane functions. A protocol connection is not evidence that the connected capability is safe.
A Phased Path From Integrations To A Capability Fabric
Use the sequence below for one prepared, reversible workflow. Set the schedule and exit criteria after reviewing system access, risk, procurement, required approvals, and team availability.
First, map the boundaries. Inventory agent clients, MCP servers, direct APIs, plug-ins, and agent-to-agent calls. Expand every ambiguous ACP label. Identify duplicate tools and capabilities that bypass identity or audit controls. Select one high-value, reversible workflow shared by at least two roles.
Next, build one governed capability. Design the tool around user intent, place it behind a managed MCP endpoint, enforce user or workload identity, and add structured evidence. Connect it to a coding experience such as Kiro and a business experience such as Amazon Quick where the use case supports both. Give each role a distinct policy.
Then, operate and expand. Run evaluation prompts, failure injection, permission tests, and schema compatibility checks. Measure task completion, incorrect tool selection, denials, latency, human approvals, and cost. Publish the capability in an internal registry only after its owner and runtime target are clear. Add a second workflow by reusing the same identity, policy, telemetry, and release path.
The goal is not the largest MCP catalog. It is the smallest trusted set of capabilities that meaningfully improves work across roles.
Turn Protocol Choices Into an Operating System
Tactical Edge helps enterprises evaluate and implement governed capability architectures. Connectory is our production pull-request review application at app.connectory.ai; it applies repository context and workspace policies to report findings in GitHub before merge. Our Agentic Process Transformation and AgentOps services can help scope selected workflows and design AWS architectures with identity, observability, evaluation, cost controls, and human decision points appropriate to the use case.
The core design principle is straightforward: use ACP for the client-to-agent experience, MCP for reusable capabilities, and A2A only where independent agents truly need to collaborate. Then place all three inside one operating model that can answer who owns a capability, who may invoke it, what evidence it returns, and whether it improves the work.
That is how a product manager, designer, developer, security engineer, and operator stop using separate AI assistants and start building a shared system of capability.
Talk with Tactical Edge about your enterprise agent protocol architecture.
Frequently Asked Questions
What is the difference between MCP and ACP?
MCP, the Model Context Protocol, standardizes how an AI host and its clients use capabilities that servers expose, such as tools, resources, and prompts [1]. Agent Client Protocol standardizes the connection between a user-facing client, such as an IDE, and a coding agent [2]. One connects an agentic application to capabilities; the other connects an interactive client to an agent.
Is ACP the same as the IBM Agent Communication Protocol?
No. The older IBM Agent Communication Protocol addressed agent-to-agent communication, and IBM states that project is part of A2A under the Linux Foundation [3]. For teams building with Kiro, ACP refers to Agent Client Protocol. Expand the acronym before making an architecture decision.
Did MCP remove sessions?
The specification dated 2026-07-28 replaced the earlier connection-scoped handshake and session model with a stateless core. Each request carries its protocol metadata and capabilities, and an optional server/discover call lets clients inspect server capabilities in advance [1][8]. Implementations that still support older MCP revisions need an explicit compatibility path rather than assuming the two eras behave the same [7][8].
When should we use A2A or a plain API instead?
Use A2A when work must cross an agent boundary between independent agents. Keep APIs and events when the interaction is deterministic and does not need agent discovery. Our enterprise agent protocol practice covers how those boundaries get drawn for a specific workflow.
How do we govern capabilities exposed over MCP?
Treat each tool as a product interface with a named owner, defined inputs, documented side effects, and evidence returned to the caller, rather than a thin wrapper over an existing endpoint. Our agent governance and AgentOps practices cover ownership, authorization boundaries, evaluation, and telemetry for capabilities that several experiences reuse.
References
[1]Model Context Protocol. “Architecture,” specification 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/architecture
[2]Agent Client Protocol. “Protocol Overview.” https://agentclientprotocol.com/protocol/v1/overview
[3]IBM Research. “Agent Communication Protocol.” https://research.ibm.com/projects/agent-communication-protocol
[4]Kiro. “How Kiro Works” and “Agent Client Protocol.” https://kiro.dev/docs/how-kiro-works/ and https://kiro.dev/docs/cli/acp/
[5]Amazon Web Services. “Model Context Protocol Integration: Amazon Quick.” https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html
[6]Amazon Web Services. “Model Context Protocol Strategies on AWS.” https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/mcp-strategies/mcp-strategies.pdf
[7]Model Context Protocol. “Transports,” specification 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
[8]Model Context Protocol Core Maintainers. “The 2026-07-28 Specification,” July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
[9]Model Context Protocol. “Authorization,” specification 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization