Skip to main content

7. Model Context Protocol (MCP)

This section defines how MCP is used within the architecture, what problems it is intended to solve, and where its responsibilities explicitly end.

7.1 Role of MCP in the Architecture​

Within this architecture, MCP serves a capability exposure and control layer, not a business logic layer.

MCP is used to:

  • Describe available capabilities and their contracts in a machine-readable form
  • Enable consistent invocation by AI agents, workflows, and systems
  • Provide a single abstraction over deterministic and AI-assisted executors

MCP is not:

  • A replacement for APIs or integration platforms
  • A workflow engine
  • A persistence or orchestration layer

Its value lies in standardising how outcomes are requested and governed, regardless of how they are executed.

7.2 MCP Tool Definition Standards​

Each MCP tool corresponds to a single capability version.

A tool definition includes:

  • Capability name and version
  • Purpose and outcome description
  • Input and output schemas
  • Supported execution modes
  • Required context fields
  • Confidence and provenance expectations

Standards:

  • Schemas must be explicit and strict
  • Optional fields are minimised
  • Behavioural guarantees are documented outside the tool definition

Tool definitions are treated as contracts, not documentation.

7.3 MCP vs Direct API Invocation​

Direct API invocation and MCP invocation coexist intentionally.

Direct API invocation is preferred when:

  • The consumer is tightly coupled to a known system
  • Deterministic behaviour is required
  • Latency and cost must be minimised

MCP invocation is preferred when:

  • Consumers are dynamic or AI-driven
  • Capabilities may be fulfilled by multiple executors
  • Discovery, governance, or substitution is required

The architecture does not mandate MCP everywhere; it uses MCP where it adds structural value.

7.4 MCP Discovery and Composition​

MCP supports capability discovery through:

  • Published tool registries
  • Versioned capability metadata
  • Policy-filtered visibility based on identity and context

Composition occurs when:

  • An invoker selects multiple capabilities to achieve a higher-order outcome
  • Sequencing and dependency are explicit
  • Each invocation remains independently observable

MCP enables composition but does not perform orchestration.

7.5 MCP Security Considerations​

MCP is a security boundary, not a bypass.

Security controls include:

  • Strong authentication and authorisation at invocation time
  • Capability-level permissioning
  • Input and output validation
  • Rate limiting and cost controls

AI-driven invocations are subject to:

  • Additional policy checks
  • Constrained execution environments
  • Mandatory provenance capture

MCP reduces risk by narrowing what can be invoked, not by expanding access.