What MCP Really Is (and What It Is Not)

MCP standardizes how agents execute tool calls. It does not decide what should be done.

Explainer

The Model Context Protocol (MCP) is a standard interface that allows AI agents to discover and invoke external tools in a consistent way. It defines how tools are described, how schemas are exposed and how calls are executed.

Before MCP, integrations between AI systems and enterprise services were built and controlled by developers. Tool usage was encoded in application logic. Security reviews focused on APIs, credentials and access scopes before deployment.

MCP changes this model. Agents now decide which tools to invoke at runtime, based on context and intermediate results. MCP simply provides a uniform execution layer.

Architecture

Dev aspects: how MCP is actually integrated

Step 1: Run or install an MCP server

Most MCP servers are lightweight processes exposing a set of tools.

npx @modelcontextprotocol/server-github --token $GITHUB_TOKEN

At this point, the server exposes tools like list_repos, create_issue, get_pull_requests.

Step 2: Register MCP server with the agent runtime

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "****"
      }
    }
  }
}

No application code changes are required. Tools become visible to the agent immediately.

Step 3: Agent constructs tool calls at runtime

{
  "tool": "create_issue",
  "arguments": {
    "repo": "payments-service",
    "title": "Customer-reported outage",
    "body": "Extracted from support ticket #48291"
  }
}

This call is generated dynamically by the agent, not pre-wired by developers.

Before and After MCP: Same AI App, Different Execution Model

MCP shifts decision-making from build time to runtime.

What MCP Actually Improves

MCP improves reliability and integration hygiene, not correctness.

• Consistent schemas for tools
• Centralized execution and logging
• Reduced glue code
• Faster experimentation across agents

But MCP does not fix poor agent reasoning. A bad plan still produces a bad outcome.

The Hidden Cost: Schemas Are the Real Work

MCP assumes schemas exist. In many enterprises, they don’t.

MCP works best when tools already have clean, stable schemas. This is common in modern SaaS APIs. It is not common in internal systems or security tooling.

Security platforms, legacy services and internal scripts often lack meaningful schemas. MCP adoption forces teams to invent abstractions.

{
  "name": "disable_user",
  "description": "Disable a user account",
  "parameters": {
    "user_id": "string"
  }
}

Behind this may live:

• Multiple approvals
• Directory updates
• Audit logging
• Human review

MCP hides this complexity. That abstraction is powerful, but costly to design correctly.

Failure Modes We See Repeatedly

These risks already exist in AI systems. MCP changes how quickly they surface, how widely they propagate, and how hard they are to detect.

MCP does not introduce entirely new classes of failure. What it does is lower the friction between reasoning and execution. As a result, existing AI risks move from being mostly theoretical or localized to being operational and scalable.

Three patterns show up consistently in real MCP-based deployments.

Content injection with executable blast radius

User-generated data influences agent reasoning in ways that trigger real tool execution. What would previously have resulted in a questionable response can now cause the agent to invoke tools across multiple systems. The failure is not malicious. The outcome is simply broader and harder to unwind.

Supply-chain exposure through MCP servers

MCP changes how integrations are distributed. Teams install community-maintained MCP servers that execute with real credentials and expose tools dynamically. Trust is implicit. A compromised or poorly scoped server does not need an exploit to cause damage. Every call can be valid and fully authorized.

Over-execution enabled by dynamic tool chaining

Agents are often given broad goals such as “resolve this issue end-to-end.” With MCP, agents can chain tools opportunistically at runtime. Each individual action is allowed. The combined effect crosses unintended boundaries. From logs alone, the behavior looks correct.

Across all three cases, the defining characteristic is the same. Nothing breaks loudly. Permissions are respected. Logs look clean. The failure is contextual, not technical.

This is why many MCP-related incidents are discovered late, during audits or post-hoc reviews, rather than through traditional security alerts.

Why Static Security Reviews Break Down

Static reviews cannot validate dynamic systems.

Pre-production security reviews assume execution paths are enumerable. MCP-based agents do not behave that way.

Tool sequences depend on:

• Live data
• Intermediate outputs
• Agent reasoning

Security teams are asked to approve systems whose behavior cannot be fully known in advance. When failures occur, teams appear ineffective. In reality, the model is mismatched to the system.

This leads to friction, delays and eventual bypass.

Runtime Security at the MCP Layer

If decisions happen at runtime, security must operate at runtime.

A practical pattern is runtime enforcement around MCP execution, after tool selection but before tool execution.

A runtime layer can:

• Inspect tool calls in context
• Enforce per-user authorization
• Apply approval or dry-run semantics
• Capture high-fidelity audit trails
• Limit blast radius

This does not correct bad plans. It makes them observable and controllable.

Dev aspects: what runtime enforcement actually sees

{
  "agent": "support-agent",
  "user": "alice@company.com",
  "tool": "export_customer_data",
  "parameters": {
    "customer_id": "12345"
  },
  "context": {
    "source": "support_ticket",
    "risk_level": "high"
  }
}

This is where policy decisions belong. Not in prompts. Not in static reviews.

Why This Matters for Enterprises

Runtime control removes the false choice between speed and safety.

Static controls slow teams down or create blind spots. Runtime enforcement enables scale without losing auditability. Organizations that understand this early extract real business value from AI. Others retreat after the first serious incident.

Closing Thought

MCP is not magic. In some sense, it does not remove complexity. It relocates it.

Organizations that treat MCP as a serious platform decision invest in schemas, runtime controls and ownership. Others adopt quickly, hit hidden costs and lose confidence in agentic systems altogether.

The difference is not tooling. It is the willingness to confront reality.