The biggest bottleneck in enterprise AI deployment is not model quality. It is connectivity. Foundation models have reached a level of reasoning capability that exceeds what most enterprise workflows demand. The gap is between the agent and the systems it needs to act on. ERP platforms, device management consoles, fleet telematics servers, manufacturing execution systems none of these were designed with AI agents in mind. They expose REST APIs, SOAP endpoints, proprietary SDKs, and occasionally CSV exports. Every integration is bespoke.
This is where protocols matter. MCP (Model Context Protocol) and A2A (Agent-to-Agent Protocol) are emerging as the standard interfaces for two distinct problems: connecting agents to tools and connecting agents to each other. MCP, now governed by the Linux Foundation with tens of millions of monthly SDK downloads, provides a uniform interface for agents to discover and invoke tools, read data sources, and interact with enterprise systems. A2A, backed by Google and dozens of enterprise partners, enables agents built on different frameworks to communicate, delegate tasks, and exchange artifacts.
At Wenable Labs, we have built MCP servers for device management platforms, ELD hardware integrations, transportation management systems, and pharmaceutical quality systems. We use A2A for multi-agent coordination across these domains. This post documents the practical patterns we have converged on.
MCP: The Agent-to-Tool Standard
MCP addresses a deceptively simple question: how does an agent know what tools are available, what they do, and how to call them? Before MCP, the answer was prompt engineering. You described available functions in the system prompt, hoped the model would generate valid JSON for function calls, and wrote custom parsing logic on the other side. It worked, but it did not scale. Adding a new tool meant updating prompts across every agent that might use it. Changing a tool’s parameters risked breaking agents that had learned the old schema.
MCP replaces this ad hoc approach with three primitives.
Tools are actions the agent can take. A tool has a name, a description, an input schema, and an output schema. When an agent connects to an MCP server, it can discover all available tools and understand their interfaces without any prompt engineering. The tool “get_device_policy” takes a device group ID and returns a policy configuration object. The tool “update_compliance_status” takes a device ID and a status enum. The schemas are machine-readable and self-documenting.
Resources are data the agent can read. Unlike tools, resources are not actions they are information sources. A resource might expose “all devices in a given compliance state” or “the current fleet location snapshot.” Resources support URI-based addressing and can be static or dynamic.
Prompts are templates for common interaction patterns. They encode the best way to use a particular set of tools for a specific task. A prompt template for “investigate compliance violation” might specify the sequence of tool calls, the data to retrieve, and the format for the final report.
The enterprise value of MCP is straightforward: build the connector once, and any MCP-compatible agent can use it. When we build an MCP server for a device management console, every agent in the organization whether built with LangChain, CrewAI, Semantic Kernel, or a custom orchestrator can manage device policies through the same interface. The integration cost shifts from O(agents x systems) to O(agents + systems). In an enterprise running a dozen agent-powered workflows across five backend systems, that is the difference between 60 custom integrations and 17 standardized connectors.
Our pattern is one MCP server per enterprise system. Each server owns its domain, handles its own authentication, enforces rate limits, and produces audit logs. This maps cleanly to how enterprises already organize system ownership and access control.
Building MCP Servers: Practical Patterns
The architecture of an MCP server is not complicated. It is a service that wraps an existing enterprise API and exposes it through the MCP protocol. The complexity lives in the details: tool granularity, authentication, error semantics, and testing.
Server Architecture. We build MCP servers as lightweight services typically FastAPI (Python) or Express (TypeScript) that sit between agents and enterprise APIs. The server handles MCP protocol negotiation, tool discovery, request validation, and response formatting. The business logic is thin: translate MCP tool calls into enterprise API calls and translate the responses back. We deploy these as containerized services behind the same API gateway infrastructure that serves our other microservices.
Tool Design. Tool granularity is the most consequential design decision. Tools that are too coarse (“manage_devices”) give the agent insufficient control. Tools that are too fine (“set_device_field”) generate excessive round trips. We have settled on operation-level granularity: one tool per meaningful business operation. For a device management MCP server, this means tools like “get_device_policy,” “apply_policy_to_group,” “query_compliance_violations,” “generate_compliance_report,” and “get_device_health_summary.” Each tool corresponds to an operation an administrator would recognize.
Tool descriptions matter more than most teams expect. The description is how the agent decides whether to use the tool and how to invoke it. We write tool descriptions as if they were API documentation for a junior engineer: clear about what the tool does, explicit about required versus optional parameters, and specific about what the response contains.
Authentication and Authorization. Agents need identities. We use OAuth 2.0 client credentials for agent-to-MCP authentication, with each agent registered as a service principal. Permissions are scoped per tool: the compliance reporting agent can call “query_compliance_violations” and “generate_compliance_report” but cannot call “apply_policy_to_group.” This mirrors the principle of least privilege that enterprises already enforce for human users.
Error Handling. Agents need structured errors they can reason about, not HTML error pages or generic 500 responses. Our MCP servers return typed error objects with an error category (authentication, authorization, validation, not_found, rate_limit, upstream_error), a human-readable message, and a machine-readable code. The agent can distinguish between “you do not have permission” (stop and escalate) and “the upstream system is temporarily unavailable” (retry with backoff).
Testing. Every MCP server has integration tests that run against a staging instance of the enterprise system. Unit tests verify tool schema validation and error handling. Integration tests verify that tool calls produce correct results against real data. We run these in CI on every commit. The staging environments are seeded with representative data enough devices, policies, and compliance states to exercise realistic query patterns.
When we built the MCP server for WeGuard’s device management console, we started with five tools covering the highest-frequency operations: policy retrieval, policy application, compliance queries, device health summaries, and audit log retrieval. The initial implementation took roughly two weeks from design to production deployment. The MCP server now serves as the integration layer for ViVi, our AI agent for device management, and has since been extended to 14 tools covering the full administrative surface.
A2A: When Agents Need to Talk to Each Other
MCP connects agents to tools. A2A connects agents to each other. The distinction matters because production enterprise AI rarely involves a single agent operating in isolation. A compliance investigation might require a fleet management agent to pull driver records, a device management agent to check mobile device configurations, and a document processing agent to extract data from regulatory filings. These agents may be built by different teams, running on different frameworks, deployed in different environments.
A2A provides four capabilities that make this coordination possible.
Agent Cards are machine-readable descriptions of an agent’s capabilities, published at a well-known URL. An Agent Card declares what the agent can do, what inputs it accepts, and what outputs it produces. This enables agent discovery a supervisory agent can find and evaluate available agents without hardcoded knowledge of the ecosystem.
Task Delegation follows a structured lifecycle. A requesting agent creates a task, the receiving agent processes it, and the task progresses through defined states (submitted, working, completed, failed). Both sides can stream updates during execution, which matters for long-running enterprise operations that may take minutes to complete.
Artifact Exchange provides a standard format for agents to pass structured data to each other. The compliance agent does not just return “the fleet is non-compliant.” It returns a typed artifact containing violation records, affected vehicle identifiers, regulatory references, and recommended remediation steps.
We use A2A in our multi-agent architectures when specialized agents need to collaborate across domain boundaries. The supervisory agent in our fleet operations platform delegates investigation tasks to sub-agents responsible for ELD compliance, vehicle maintenance records, and driver hours-of-service tracking. Each sub-agent is an independent service with its own MCP connections to the relevant enterprise systems.
The decision between A2A and direct multi-agent orchestration is practical, not ideological. If all agents live in the same codebase and are managed by the same team, direct orchestration through a shared framework is simpler. A2A becomes valuable when agents cross team boundaries, framework boundaries, or organizational boundaries exactly the conditions that define large enterprise environments.
Security and Governance
Connecting AI agents to enterprise systems introduces a new category of access control. Agents are not users, but they act on behalf of users. They are not services, but they call services. Existing identity and access management frameworks need extension, not replacement.
Agent Identity. Every agent in our architecture has a registered identity in the organization’s identity provider. We use OAuth 2.0 client credentials grants with scoped permissions. The compliance reporting agent has a service principal with read access to compliance data and write access to report generation endpoints. It cannot modify policies, onboard devices, or access data outside its scope. Agent identities are managed through the same governance processes as service accounts provisioned by IT, reviewed quarterly, revoked when no longer needed.
Audit Trails. Every MCP tool call is logged with the calling agent identity, the tool invoked, the input parameters, the response summary, a timestamp, and the correlation ID linking the call to the originating user request. These logs feed into the organization’s existing SIEM infrastructure. When an auditor asks “who changed this device policy and why,” the answer includes the full chain: the user who issued the natural language instruction, the supervisory agent that interpreted it, the policy agent that executed it, and the specific MCP tool call that made the change.
Rate Limiting and Circuit Breakers. Agents can generate API calls at machine speed. Without safeguards, a poorly configured agent loop can overwhelm an enterprise system in seconds. Every MCP server enforces per-agent rate limits calibrated to the upstream system’s capacity. Circuit breakers trip when error rates exceed thresholds, preventing cascade failures. We have learned this lesson empirically: an early prototype generated 400 API calls in under a minute during a retry loop before we added circuit breaker logic.
The Governing Principle. An agent should never have more access than the human it is acting on behalf of. If an IT administrator cannot modify policies for a device group outside their region, the agent acting on their behalf cannot either. This is implemented through token delegation: the agent’s MCP calls carry the delegating user’s permission scope, and the MCP server enforces those boundaries at every tool invocation. This principle is non-negotiable. It is what makes enterprise AI deployments auditable, compliant, and trustworthy.
Where We Go From Here
MCP and A2A are the plumbing of production AI. They are not the parts of an agent system that generate excitement in demos. They are the parts that determine whether the system works reliably at scale, passes security reviews, and survives its first audit.
The analogy to early internet infrastructure is apt. TCP/IP and HTTP were not glamorous protocols, but they were what made networked applications possible. Without standardized interfaces, every system integration was a point-to-point connection that broke when either side changed. MCP and A2A play the same role for agentic AI: they reduce the integration surface, enforce consistent security models, and make agents first-class citizens in enterprise architecture rather than fragile prototypes held together with prompt engineering and custom glue code.
We will continue publishing implementation details from our production deployments. The 7-Layer Agentic AI Stack provides the broader architectural context for where MCP and A2A fit. If your organization is evaluating agent-to-tool or agent-to-agent integration patterns, reach out this is the infrastructure work we do every day.