Model Context Protocol, or MCP, is being positioned as a standard way to connect AI assistants and agents to tools, systems, and data sources. The idea is attractive because the integration problem is real. Every AI-native enterprise needs agents that can work with repositories, ticketing systems, databases, document stores, cloud platforms, business applications, and internal knowledge sources. Without a common integration layer, every AI system becomes a custom connector project.

MCP tries to solve that connector problem. It gives clients and servers a common way to expose tools, resources, prompts, and context. It reduces integration friction. It helps developers connect AI systems to external capabilities faster.

But that is exactly where the problem begins.

MCP is useful as plumbing, but it is the wrong foundation for enterprise agent architecture. The reason is simple: enterprise AI does not primarily need easier tool invocation. It needs governed execution.

The core enterprise question is not, “Can the agent call this tool?” The real question is, “Should this agent, acting for this user, in this business context, with this risk level, be allowed to perform this action, on this system, using this data, and can we prove exactly what happened afterward?”

MCP does not make that question the center of the design. It standardizes connectivity before it standardizes governance. It makes capability easier before it makes responsibility native. That is why MCP itself becomes the problem when organizations treat it as the architectural center of enterprise agents.

MCP Solves the Easier Problem First

The official MCP specification defines MCP as a JSON-RPC-based protocol with standard transports including stdio and Streamable HTTP. In the stdio model, the MCP client launches the MCP server as a subprocess and exchanges messages through standard input and output. Streamable HTTP supports client-server communication over HTTP, and the specification also allows custom transports in a pluggable way.

This design is practical for developer tooling. A local AI assistant can launch a filesystem server, a Git server, or another helper process and communicate with it through a simple protocol. A remote server can expose tools over HTTP. For demos, prototypes, and controlled developer workflows, this can be convenient.

But enterprise agent execution is not only a protocol problem. It is an operating model problem.

An enterprise agent that can read Jira, inspect GitHub, query a database, create a pull request, write a comment, generate a migration, or trigger a workflow is no longer just retrieving context. It is participating in business execution. That requires identity, authorization, policy, approval, audit, evidence, rollback, risk classification, environment boundaries, data classification, and human accountability.

MCP does not make those controls the primary abstraction. It gives the ecosystem a common way to expose and invoke tools, while leaving many of the hardest enterprise controls to individual clients, servers, platforms, or implementation-specific extensions.

That is not enough for serious enterprise AI.

The Wrong Center of Gravity

The biggest issue with MCP is not that it has no value. The issue is that it puts the center of gravity in the wrong place.

A protocol-centered model starts with tool exposure. A server advertises tools. A client discovers them. The model or agent decides which tool to call. The server executes the call. The result returns to the client.

That flow looks clean from an integration perspective. But from an enterprise governance perspective, it starts too late and controls too little.

A governance-centered model starts with the work itself. What is the user trying to accomplish? What business process does this belong to? What systems are in scope? What data may be accessed? Which actions are read-only? Which actions are write-capable? Which actions are reversible? Which actions require approval? Which tools are approved for this agent? Which model is allowed for this workload? What evidence must be captured? What happens if the agent makes a mistake?

That is the model enterprise AI needs.

MCP can be part of that model as an adapter layer, but it should not be the model itself. If MCP becomes the foundation, enterprises risk building agent systems around callable tools instead of governed work.

This distinction matters because AI agents are not traditional deterministic applications. They interpret natural language. They may infer intent. They may select tools dynamically. They may act on incomplete context. They may be influenced by retrieved content, tool descriptions, user prompts, or malicious instructions. That makes the action layer much more sensitive than a normal API integration layer.

Tool Discovery Without Governance Creates Capability Sprawl

One of MCP’s attractive features is that clients can discover tools exposed by servers. But in enterprise environments, tool discovery is not enough. Enterprises need governed capability registration.

A tool is not just a function. It is an authority boundary.

A tool that reads documentation is different from a tool that reads internal strategy files. A tool that lists database tables is different from a tool that queries customer records. A tool that opens a Jira ticket is different from a tool that comments on a customer escalation. A tool that creates a branch is different from a tool that modifies production infrastructure.

From a protocol perspective, these may all look like callable tools. From an enterprise perspective, they represent very different risk classes.

A mature enterprise should know the owner of every tool, what data it can access, what side effects it can create, which agents can use it, which users can invoke it, which environments it can touch, which approvals are required, what logs must be retained, and how the tool can be disabled in an emergency.

MCP does not make a governed tool registry the center of the operating model. It enables tools to be exposed and called. That difference creates risk.

Without a central control plane, organizations can drift into MCP server sprawl. Different teams may install different MCP servers. Some may be maintained well. Others may not. Some may enforce permissions correctly. Others may use broad credentials. Some may log enough detail. Others may not. Some may have clear ownership. Others may be experimental utilities that quietly become production dependencies.

That is not a hypothetical concern. Security research has already identified risks in the MCP ecosystem, including malicious MCP servers, tool poisoning, rug pulls, and insufficient audit mechanisms on aggregation platforms. One systematic study described MCP as an emerging standard that expands the attack surface for LLM agent systems and showed that malicious MCP servers could be uploaded to aggregation platforms and later trigger harmful behaviors in local environments.

The implication is clear: once tool servers become easy to create and distribute, enterprises need stronger governance, not only easier discovery.

Tool Metadata Becomes an Attack Surface

MCP-based systems depend heavily on tool descriptions and metadata. That creates a specific AI-era security problem: the model may use tool descriptions not only as documentation, but as behavioral guidance.

Security researchers have identified attack classes such as tool poisoning, shadowing, and rug pulls. In tool poisoning, malicious instructions are hidden in tool descriptors. In shadowing, trusted tools may be indirectly affected through contaminated shared context. In rug pulls, tool definitions can change after approval to manipulate later behavior. Research on MCP-integrated systems has argued that threats embedded in tool metadata can manipulate model behavior and that defenses focused only on prompt injection are insufficient.

This matters because MCP makes tool descriptors part of the interaction surface between tools and models. In a traditional API system, documentation does not usually influence runtime decision-making directly. In an AI agent system, tool descriptions may shape the model’s tool-selection and execution behavior.

That changes the security model.

A malicious or compromised tool description can do more than mislead a human developer. It can influence an AI agent at runtime. If the model trusts the descriptor, the descriptor becomes part of the control channel.

This is why MCP’s abstraction is risky. It treats tool descriptions as a practical part of tool interoperability, but in agentic systems those descriptions are also semantic inputs to a probabilistic decision-maker.

A serious enterprise architecture would require signed tool manifests, immutable versions, semantic validation, tool-risk classification, change approval, and runtime monitoring. Those controls should be foundational, not optional add-ons.

The Database Use Case Proves the Problem

The clearest practical example is an AI agent connected to a database through MCP.

Imagine an enterprise team wants an AI engineering agent to help troubleshoot application failures. The agent has access to Jira for tickets, GitHub for source code, and a database MCP server for schema inspection and query execution. At first, this looks useful. The agent can read the bug report, inspect relevant code, check the database schema, identify the likely cause, and propose a fix.

Now consider a realistic user request:

“Find why customer exports are failing and fix the issue.”

The agent reads the Jira issue. It inspects code. It looks at database tables. It may run queries. It may inspect export history. It may generate a migration. It may modify code. It may open a pull request. It may comment back in Jira with its findings.

From a workflow perspective, this is exactly what AI-native software delivery wants: faster diagnosis and execution.

From a governance perspective, this is a minefield.

The database server may expose tools such as list_tables, describe_table, run_query, or execute_sql. These tools are not equivalent. list_tables may reveal sensitive schema names. describe_table may expose regulated data structures. run_query may retrieve customer data. execute_sql may alter or delete business records.

MCP can expose these capabilities as tools, but enterprise safety depends on controls that are outside the basic act of invocation. Which database environment is the agent using? Is it production, staging, or development? Is the agent read-only? Can it access personally identifiable information? Are sensitive columns masked? Are query results allowed to flow back into the model context? Can the agent include database findings in a Jira comment? Can it generate a migration? Can it run that migration? Who approves it?

These are not secondary details. These are the core enterprise requirements.

A safe architecture would treat database interaction as a governed data operation. It would classify the query. It would enforce least privilege. It would block production writes unless explicitly approved. It would mask sensitive fields. It would prevent regulated data from being included in model prompts or external comments. It would log query intent, query text, result classification, user identity, agent identity, model identity, approval state, and downstream actions.

MCP does not make that the default operating model. It makes database access look like another tool integration.

That is the problem.

In enterprise AI, database access should not be a generic callable tool. It should be a policy-controlled, auditable, risk-aware workflow.

The Software Delivery Use Case Shows the Enterprise Gap

Now extend the same pattern to a full software delivery workflow.

A product owner creates a Jira ticket asking for a new customer export feature. An AI agent reads the ticket, checks the repository, generates code, updates the database schema, creates tests, opens a pull request, and comments back in Jira.

Using MCP, the organization might connect a Jira MCP server, a GitHub MCP server, and a database MCP server. The AI agent can now interact with all three systems through a standardized interface.

That sounds efficient. But the enterprise problem is not solved. It has only moved to a more dangerous layer.

The AI agent needs to know which Jira projects it can read, which tickets are in scope, which repositories are approved, which branches it can create, whether it can push code, whether it can open pull requests, whether it can request review, whether it can update ticket status, whether it can write customer-visible comments, whether it can inspect database schemas, whether it can generate migrations, and whether those migrations can ever be executed.

A governed enterprise platform would not treat this as a set of independent tool calls. It would create a structured WorkOrder. The WorkOrder would define scope, systems, permissions, allowed tools, risk tier, approval checkpoints, test requirements, audit requirements, and rollback expectations.

The agent could read Jira, but only within the WorkOrder scope. It could inspect GitHub, but only approved repositories. It could generate code, but not merge it. It could propose a schema migration, but not execute it without approval. It could draft a Jira comment, but sensitive findings would be redacted or routed for review. It would produce evidence showing the prompt, model, retrieved context, tool calls, files changed, tests run, approvals received, and final outputs.

That is enterprise AI-native execution.

MCP can help wire the tools, but MCP does not provide the operating model. When organizations mistake the wiring for the architecture, they create fragile agent systems.

Local MCP Servers Create Shadow-IT Risk

The stdio transport is especially problematic in enterprise environments because it supports a local subprocess model. The client launches the server locally and communicates through standard input and output.

This is convenient for developers, but it also creates shadow-IT risk.

A local MCP server may run on a developer machine that has access to source code, SSH keys, environment variables, cloud credentials, configuration files, local documents, API tokens, and internal repositories. Even if the server is not malicious, it may be over-permissioned. It may have vulnerable dependencies. It may log too much. It may expose tools that were intended for convenience but become dangerous when invoked by an AI agent.

Traditional enterprise access is normally mediated through managed identities, endpoint controls, network policies, approved applications, logging, and security monitoring. A locally installed MCP server can bypass parts of that discipline unless the enterprise has additional controls.

The issue is not that local tools are always bad. Developers need local tools. The issue is that MCP’s developer-first transport model is being promoted into an enterprise-agent context, where local convenience can become unmanaged authority.

When an AI client can launch local servers that bridge model behavior to local credentials and files, the enterprise needs strict controls. Otherwise, MCP becomes another channel for uncontrolled access.

Remote MCP Improves Deployment, But Not Governance

Streamable HTTP helps move MCP from local subprocesses to remote services. That can improve operational manageability. A remote MCP server can be hosted centrally, monitored, patched, and protected behind enterprise infrastructure.

But remote transport does not solve the core problem.

An HTTP endpoint can still expose overly broad tools. It can still rely on static service credentials. It can still fail to mirror user permissions. It can still lack tool-risk classification. It can still log insufficient evidence. It can still allow a model to perform high-impact actions without approval. It can still pass sensitive outputs back into model context.

The official transport specification also includes security guidance for HTTP-based deployments, including validation of the Origin header to prevent DNS rebinding attacks, binding local servers to localhost when appropriate, and implementing proper authentication.

Those warnings are important, but they also reinforce the broader point: MCP deployments require serious security controls outside simple protocol connectivity.

Remote MCP changes the network shape. It does not turn MCP into an enterprise agent governance platform.

MCP Makes Capability Easy and Responsibility Optional

The strongest critique of MCP is that it makes agent capability easy while leaving agent responsibility optional or implementation-specific.

If an agent can read a file, there must be data governance. If it can query a database, there must be data classification and result controls. If it can write to Jira, there must be communication policy and audit. If it can change code, there must be review and traceability. If it can modify infrastructure, there must be approval and rollback. If it can act across multiple systems, there must be correlation across the full execution chain.

MCP standardizes the call path. It does not standardize the responsibility model deeply enough.

This imbalance matters because organizations adopt standards based on what the standard makes easy. If the standard makes tool exposure easy but governance external, the ecosystem naturally grows around tool exposure first. Governance then becomes something enterprises retrofit after risk appears.

That is backward.

Enterprise AI should begin with the control plane. Tools should be registered, risk-scored, permissioned, versioned, approved, observed, and revocable before agents use them. The control plane should decide which agent can use which tool, for which user, under which conditions, with which approvals, and with which evidence.

MCP can sit behind that control plane as an adapter. It should not replace the control plane.

The Better Architecture: Control Plane First, MCP Second

A better enterprise architecture starts with governed agent execution.

At the top is the work object: a task, request, incident, case, ticket, WorkOrder, or business process. That work object defines scope, owner, purpose, risk level, systems involved, data classification, allowed actions, and required approvals.

Below that sits an agent control plane. The control plane manages agent identities, user delegation, tool registration, policy evaluation, approval workflows, model routing, evidence capture, observability, kill switches, and runtime limits.

Only below that should tool protocols appear.

In this architecture, MCP can be one adapter among several. It can connect to a GitHub server, a Jira server, a database server, or a document server. But the agent should not call MCP tools directly just because they are available. Calls should pass through policy evaluation.

The control plane should ask: Who is acting? What are they trying to do? What tool is requested? What data will be touched? What side effects are possible? Is approval required? Has approval been granted? Is the output allowed to return to the model? What must be logged? What happens if the action fails?

That is the correct architecture for enterprise AI-native systems.

The protocol should serve the control plane. The control plane should not be an afterthought around the protocol.

What the Article Should Not Claim

To be precise, the argument should not be that MCP is useless. MCP is not useless. It solves a real integration problem.

The argument should not be that every MCP server is unsafe. Some MCP servers may be well designed, tightly permissioned, carefully audited, and safely deployed.

The argument should not be that JSON-RPC automatically creates insecurity. JSON-RPC is just a messaging mechanism. The better critique is that a generic RPC envelope is insufficient for enterprise agent execution unless surrounded by strong identity, policy, approval, audit, and runtime controls.

The argument also should not be that governance can never be added around MCP. It can. But if governance has to be added around MCP, then MCP should not be treated as the enterprise architecture. It should be treated as a lower-level integration adapter.

That is the more accurate position.

The Real Problem Statement

The most defensible critique is this:

MCP is useful plumbing, but it is the wrong center of gravity for enterprise AI agents.

It solves the connector problem better than it solves the governed-execution problem. It standardizes tool access while leaving critical enterprise controls outside the core abstraction. It encourages an ecosystem of callable tools before enterprises have a consistent model for tool approval, identity delegation, risk classification, audit evidence, and runtime policy enforcement.

That does not make MCP irrelevant. It makes MCP insufficient as the foundation.

Conclusion

MCP is a useful protocol for connecting AI systems to tools and data sources. But enterprise AI-native execution requires much more than connectivity.

When MCP is treated as plumbing, it can be valuable. When it is treated as the architecture, it becomes the problem.

The future of enterprise agents should not be built around a marketplace of loosely governed callable tools. It should be built around governed work execution, where every agent action is scoped, permissioned, risk-aware, approved when necessary, observable, auditable, and human-accountable.

MCP can help move messages between agents and tools. It can reduce integration friction. It can support interoperability.

But it should not define the enterprise operating model for agentic AI.

Enterprise AI does not need tools first.

It needs control first.

Only then should tools be connected.