Skip to content
AIPDocs
AIP 1.055 pagesSpecification reference
Release status
DocumentationAIP 1.0Specification referenceProtocol Standard

AIP Compatibility Profiles

This is a supporting implementation reference. Section 21 of the AIP 1.0 Specification defines the normative compatibility boundary; profile-specific schemas, version matrices, and conformance suites define the exact foreign-protocol wire behavior.

AIP compatibility profiles map existing protocols and delivery mechanisms into the AIP semantic core without importing implementation code from those systems.

Implemented profiles:

  • aip.mcp.compat.v1
  • aip.a2a.compat.v1
  • aip.http.webhook.v1
  • aip.native.nats.v1
  • aip.sse.stream.v1
  • aip.websocket.stream.v1

MCP Profile

The MCP profile maps MCP JSON-RPC methods into native AIP capabilities, resources, and task views. The implementation is intentionally split across separate crates:

  • aip-profile-mcp: pure DTOs and semantic mapping.
  • aip-mcp-server: AIP-backed MCP server lifecycle.
  • aip-mcp-client: outbound bridge for external MCP servers.
  • aip-transport-mcp-stdio: newline-delimited stdio framing.
  • aip-transport-mcp-streamable-http: Streamable HTTP request and SSE helpers.
  • aip-mcp-conformance: embeddable compatibility checks.

aipd exposes the profile at /mcp, /mcp/v1, and /aip/v1/mcp.

Implemented methods:

  • initialize
  • notifications/initialized
  • ping
  • notifications/cancelled
  • notifications/progress
  • tools/list
  • tools/call
  • notifications/tools/list_changed
  • resources/list
  • resources/read
  • resources/templates/list
  • resources/subscribe
  • resources/unsubscribe
  • notifications/resources/list_changed
  • notifications/resources/updated
  • prompts/list
  • prompts/get
  • notifications/prompts/list_changed
  • completion/complete
  • logging/setLevel
  • notifications/message
  • roots/list
  • notifications/roots/list_changed
  • sampling/createMessage
  • elicitation/create
  • notifications/elicitation/complete
  • tasks/list
  • tasks/get
  • tasks/result
  • tasks/cancel
  • notifications/tasks/status
  • draft-aware server/discover parsing in the profile only; stable endpoints do not advertise or emit draft discovery messages

tools/call is translated into a native AIP Action and executed by the same gateway/runtime path used by native HTTP and NATS. JSON-RPC errors are derived from typed AIP ProtocolError values. MCP-specific lifecycle, request correlation, sessions, roots, sampling, elicitation, prompts, completions, and task views stay outside aip-core.

Streamable HTTP behavior:

  • POST accepts JSON-RPC requests, notifications, and client responses.
  • GET opens an SSE discovery stream.
  • DELETE removes the MCP session state.
  • MCP-Protocol-Version, MCP-Session-Id, and Last-Event-ID are parsed by the transport helper crate.
  • Origin checks, bearer token parsing, protected-resource metadata, and WWW-Authenticate bearer challenges are exposed as transport-level helpers so deployments can enforce MCP HTTP authorization without moving policy into aip-core.

stdio behavior:

  • one JSON-RPC message per newline-delimited frame;
  • request, notification, and response frames are decoded into typed MCP DTOs;
  • process lifecycle remains host-controlled so embedders can enforce their own sandboxing policy.

A2A Profile

The A2A profile maps Agent Card discovery and task-oriented JSON-RPC operations into native AIP manifests, actions, cancellations, and action results. aipd exposes Agent Card discovery at /.well-known/agent.json and /a2a/agent-card; JSON-RPC is exposed at /a2a, /a2a/v1, and /aip/v1/a2a.

Implemented A2A 1.0 operations:

  • SendMessage
  • SendStreamingMessage
  • GetTask
  • ListTasks
  • CancelTask
  • SubscribeToTask
  • CreateTaskPushNotificationConfig
  • GetTaskPushNotificationConfig
  • ListTaskPushNotificationConfigs
  • DeleteTaskPushNotificationConfig

The profile includes current Agent Card interfaces, extensions, skills, security schemes, ProtoJSON roles and task states, message parts, artifacts, history, and push notification resources. Message operations execute through a native AIP Action; cancellation translates into native AIP Cancel; task state projects from the durable native action read model. Push configuration and delivery cursors use the generic durable profile-state contract. Credentials are encrypted at rest, payloads are signed, callback destinations use the same SSRF policy as native callbacks, and delivery is lease-fenced and retryable. Legacy v0.3 method names are input aliases only and are never advertised as the current wire surface.

Native NATS Profile

The native NATS profile uses subject routing plus the native AIP envelope:

aip.v1.{trust_domain}.{service}.{version}.{message_type}

Daemon implementations subscribe to the service wildcard:

aip.v1.{trust_domain}.{service}.{version}.>

Request/reply payloads may be encoded either as the canonical TransportMessage wrapper or as a raw native Envelope. Implementations MUST return a native Envelope response wrapped in TransportMessage when replying through the Rust transport helpers. Standard headers include AIP version, message type, message id, session id, and correlation id when present.