MCP

Description

MCP (Model Context Protocol) is the interface layer that lets agents discover and use external capabilities in a structured way. It provides a common contract between an agent runtime and tool/context providers so the agent can call systems consistently without custom wiring per tool.

In Ikidna terms, MCP is the bridge between agent reasoning and operational surfaces like knowledge systems, issue trackers, telemetry, and control-plane actions.

Purpose

MCP exists to solve three recurring problems:

• Standardization: one protocol for many tool surfaces.
• Composability: new capabilities can be added without redesigning the harness.
• Governance: tool access can be routed, audited, and constrained consistently.

Without MCP (or an equivalent layer), each tool integration becomes bespoke, fragile, and harder to govern at scale.

Levels of MCP Scope

MCP can be introduced at different operational levels. These levels are complementary.

Local Task MCP

Scope: a single agent run or a narrow task context.

Use when an agent only needs temporary or highly specific capabilities for one workflow (for example, a single coding task, one retrieval pass, or one deployment action).

Characteristics:

• Fast to attach and remove.
• Minimal blast radius.
• Lowest coordination overhead.

Project-Level MCP

Scope: one repository, product area, or team workflow.

Use when multiple tasks in the same project repeatedly need the same tool surfaces, conventions, and guardrails.

Characteristics:

• Shared tool contracts across related tasks.
• Stronger consistency than local task MCP.
• Moderate governance and lifecycle overhead.

System-Level MCP

Scope: platform-wide or organization-wide control plane.

Use when capabilities should be available across many projects and agent types (for example, centralized observability, issue systems, policy services, knowledge connectors, or orchestration controls).

Characteristics:

• Highest reuse and standardization.
• Strong governance and audit requirements.
• Largest blast radius; requires strict access design.

MCP Server Types and Transports

MCP servers can be exposed through different runtime shapes. Choice depends on latency, hosting model, security boundaries, and operational constraints.

STDIO

Process-local communication over standard input/output.

Typical fit:

• Local or sidecar-style tools.
• Tight process coupling.
• Simple deployment footprint.

SSE (Server-Sent Events)

Streaming responses over HTTP using SSE semantics.

Typical fit:

• Remote MCP services.
• Long-running or incremental responses.
• Web-friendly transport patterns.

HTTP / Request-Response

Classic non-streaming HTTP interactions.

Typical fit:

• Stateless tool calls.
• Simpler network and proxy environments.
• Operationally familiar service patterns.

Other Runtime Patterns

Some environments also use message-bus or gateway-mediated MCP routing. These can be useful for cross-network boundaries, policy enforcement, and centralized audit.

Selection Heuristics

• Start with local task MCP when exploring a new capability.
• Promote to project-level MCP when reuse and consistency become recurring needs.
• Promote to system-level MCP when cross-project standardization, governance, and shared observability are required.

Transport choice should follow the same rule: start simple, then move to more distributed patterns only when scale, latency, or governance demands it.

Related Concepts

• Agent Architecture - Shows MCP as a core runtime integration surface.
• Harness - Harnesses execute MCP tool calls and enforce tool boundaries.
• Execution Ledger - MCP calls should be auditable as first-class execution events.
• Knowledge Base - MCP is a common bridge into KB connectors and retrieval systems.