MCP works in two directions

October 4, 2026 · Kishore Babu Gutta

"MCP support" can describe two different architectures.

They should not be collapsed into one feature.

Direction one: Runtime consumes MCP

A provider may expose an MCP server.

Engineering Runtime can eventually treat that as another way to reach the provider:

Intent
  ↓
Runtime
  ↓
MCP transport
  ↓
Provider

In that direction, MCP sits alongside REST, GraphQL, CLI or other provider interfaces.

Runtime still owns admission, policy, context, evidence and the execution contract.

Direction two: Runtime exposes artifacts through MCP

There is another possibility:

AI agent
  ↓
MCP
  ↓
Runtime capabilities / contracts / operations
  ↓
Runtime execution

Here MCP is an interface into Engineering Runtime.

An agent can discover governed capabilities or supported operations without becoming the executor itself.

Why the distinction matters

The first direction expands how Runtime can reach systems.

The second expands how reasoning systems can discover and invoke Runtime.

Those are related but separate architectural responsibilities.

I call this Two-Directional MCP:

1. MCP as an execution transport into providers.
2. MCP as an interface exposing governed Runtime artifacts to agents.

Keeping the directions separate makes it easier to preserve the Intent–Execution boundary.