Skip to content

MCP Interoperability Mapping

MCP <-> MIG Interoperability Mapping (v0.1)

Section titled “MCP <-> MIG Interoperability Mapping (v0.1)”
  • Status: Draft
  • Last Updated: 2026-02-24
  • Depends On: /docs/concepts

This document defines a practical interoperability contract between:

  • MCP clients/servers (JSON-RPC based)
  • MIG providers/consumers (transport-neutral core protocol)

It covers discovery, invocation, streaming/progress, events, cancellation, errors, and context propagation.

An adapter accepts MCP JSON-RPC requests and translates them into MIG core operations.

An adapter accepts MIG operations and calls MCP methods on an upstream MCP server.

Both directions MAY be implemented by one bidirectional gateway.

  • MIG semantics are canonical for capability identity, error model, and telemetry.
  • MCP method names are mapped to MIG operations through deterministic rules.
  • Adapter behavior MUST preserve auth context, tenant context, and trace context.
  • Adapter SHOULD preserve streaming semantics where the source protocol supports it.
MCPMIGNotes
initialize requestHELLOsupported_versions and requested features derived from MCP client capabilities
initialize responseHELLO response (+ optional DISCOVER)MCP server capabilities are synthesized from MIG capabilities
notifications/initializedSession activationMAY trigger warm discovery cache and heartbeat scheduling
n/aHEARTBEATExposed internally; optional MCP-level keepalive notification
  • Adapter MUST reject incompatible major versions.
  • Adapter SHOULD advertise supported MIG versions in MCP initialization metadata.
MCP MethodMIG OperationMapping
tools/listDISCOVERFilter MIG capabilities where adapter surface is tool
Tool schemaCapability schema URIsAdapter resolves/embeds schema into MCP tool input schema
MCP MethodMIG OperationMapping
resources/listDISCOVERFilter surface resource
resources/readINVOKEInvoke mapped read capability with uri payload
MCP MethodMIG OperationMapping
prompts/listDISCOVERFilter surface prompt
prompts/getINVOKEInvoke mapped prompt capability with arguments
MCP MethodMIG OperationNotes
tools/callINVOKETool name maps to capability ID via adapter manifest
JSON-RPC request idmessage_idAdapter SHOULD keep reversible correlation map
Tool argumentspayloadPass-through object
JSON-RPC cancel semanticsCANCELCancellation target is correlated MIG message ID

MCP may communicate progress and partial results through notifications.

  • MIG stream frames of type response with end_stream=false map to MCP progress notifications.
  • Terminal MIG stream frame maps to final tools/call result.
  • MIG stream errors map to JSON-RPC error response.
SourceTargetMapping
MIG SUBSCRIBE event streamMCP notificationsAdapter emits namespaced notification, e.g. notifications/mig/event
MCP event-like notificationsMIG PUBLISHOptional; only when configured

MIG topics SHOULD remain namespaced (domain.system.event). MCP notifications SHOULD include full topic in payload to avoid collisions.

MIG Error CodeJSON-RPC CodeNotes
MIG_INVALID_REQUEST-32600Invalid request
MIG_NOT_FOUND-32601Method/capability not found
MIG_UNAUTHORIZED-32001Server-defined auth error
MIG_FORBIDDEN-32003Permission denied
MIG_TIMEOUT-32008Timeout
MIG_RATE_LIMITED-32009Throttled
MIG_BACKPRESSURE-32010Capacity pressure
MIG_UNAVAILABLE-32011Temporary unavailability
MIG_INTERNAL-32603Internal error
MIG_VERSION_MISMATCH-32012Protocol mismatch
MIG_UNSUPPORTED_CAPABILITY-32601Unsupported capability

Adapters MUST preserve JSON-RPC error.code and error.data in MIG details.

Recommended mapping:

  • -32600 -> MIG_INVALID_REQUEST
  • -32601 -> MIG_NOT_FOUND
  • -32602 -> MIG_INVALID_REQUEST
  • -32603 -> MIG_INTERNAL
  • -32000 to -32099 -> MIG_UNAVAILABLE unless a stronger mapping exists

Adapter MUST carry:

  • tenant_id
  • session_id (if available)
  • traceparent (if available)
  • authenticated subject identity
  • meta.mcp.client_name
  • meta.mcp.client_version
  • meta.mcp.request_id
  • meta.mcp.method
  • meta.mig.binding
  • MCP transport authentication context MUST be mapped to MIG auth principal.
  • MIG auth scopes MUST be checked before exposing a capability via MCP discovery.
  • Adapter MUST NOT leak capabilities across tenants.

Adapters SHOULD use an explicit manifest to avoid implicit or brittle name translation.

Example:

version: 0.1
mappings:
tools:
- mcp_name: observatory_infer
mig_capability: observatory.models.infer
mode: unary
resources:
- mcp_uri_pattern: observatory://artifact/{id}
mig_capability: observatory.artifacts.read
mode: unary
prompts:
- mcp_name: summarize_incident
mig_capability: observatory.prompts.incident_summary
mode: unary
policy:
allow_streaming_tools: true
emit_event_notifications: true

Manifest schema v0.2 MAY additionally include:

  • tools[*].policy_tags: policy classification hints for adapter-side checks.

An interoperable adapter implementation MUST:

  • Implement initialize, tools/list, and tools/call mapping.
  • Provide deterministic capability name mapping.
  • Preserve correlation IDs across translations.
  • Preserve retryability semantics through error mapping metadata.
  • Support CANCEL mapping for in-flight invocations.

An implementation SHOULD:

  • Support resources and prompts mapping.
  • Support stream/progress translation.
  • Support event bridging.
FeatureRequired for Interop v0.1
Handshake (initialize <-> HELLO)Yes
Tools discovery/invoke mappingYes
Error translationYes
Correlation ID preservationYes
Cancel mappingYes
Resources mappingRecommended
Prompts mappingRecommended
Event bridgeRecommended
Streaming bridgeRecommended
  1. Deploy adapter in tool-only mode (tools/list, tools/call).
  2. Add resource/prompt mappings through manifest updates.
  3. Enable streaming and event bridge for high-volume workflows.
  4. Move clients from MCP-native endpoints to MIG-native bindings over time.
  • Standard metadata schema for MCP surface typing in MIG descriptors.
  • Shared replay cursor format for event bridges.
  • Standard cancellation notification format for MCP streams.