Interoperability

EEP is designed to co-exist and interoperate with the Model Context Protocol (MCP), A2A, OpenAPI, ActivityPub, AT Protocol, and existing enterprise API gateways. EEP fills the identity + event buslayer that established protocols need but don't provide.

EEP and MCP

MCP defines the agent-to-tool layer — how an LLM accesses tools, resources, and prompts from a server. EEP operates at the entity-to-agent network layer — how entities publish state and control access. The two protocols are complementary, not competing.

Aspect	MCP	EEP
Layer	Agent-to-tool	Entity-to-agent (network)
Discovery	Tool list from server	`/.well-known/eep.json`
Authentication	No native DID auth	DID-based cryptographic identity
Payments	Not supported	x402 + on-chain proofs
Real-time events	Not native	Layer 2 SSE + Webhooks
Bilateral negotiation	Not native	Layer 3 WebSockets + commerce state machine

Example: An agent uses MCP for local web-search and code-runnertools, and uses EEP to subscribe to a financial data publisher's real-time price feed — paying via x402 and verifying the publisher's EEP Conformance Credential.

EEP and OpenAPI

OpenAPI documents what an endpoint does for human developers. EEP documents how agents discover, authenticate, and access the entity. An entity can be fully OpenAPI-documented and EEP-compliant simultaneously.

Aspect	OpenAPI	EEP
Audience	Human developers	Autonomous agents
Access control	API keys / OAuth	DID proofs, VCs, payments (machine-resolved)
Events	Not native	Layer 2 SSE + Webhooks

EEP and ActivityPub / AT Protocol

ActivityPub (Mastodon) and AT Protocol (Bluesky) are human-centric social communication protocols. EEP is agent-centric. Publishers can expose EEP endpoints alongside their existing feeds — their content becomes available to agents in structured form without abandoning their social presence.

Capability	ActivityPub	AT Protocol	EEP
Machine-readable structured data	Partial	Partial	✅ TOON/JSON/Markdown
Real-time event stream	External (WebSub)	Firehose	✅ Native SSE
DID-based identity	❌	✅ (PLC)	✅ W3C DIDs
Gated access (payment, credential)	❌	❌	✅
Autonomous commerce	❌	❌	✅ Layer 3 WS

EEP and Enterprise API Gateways

Organizations running Kong, Apigee, or AWS API Gateway do not need to replace them. EEP can be implemented as a thin middleware that wraps existing infrastructure. A company with an existing API can become EEP Core-conformant in a single sprint.

The minimal EEP compatibility layer must:

Expose /.well-known/eep.json at the gateway root
Add Link: <...>; rel="eep" response headers
Validate EEP gate proofs before forwarding requests
Transform backend events to CloudEvents format for SSE/Webhook delivery

yaml

# Kong Gateway — add EEP Link headers
plugins:
  - name: response-transformer
    config:
      add:
        headers:
          - "Link: <https://api.example/.well-known/eep.json>; rel=\"eep\""
          - "Link: <https://api.example/eep/subscribe>; rel=\"subscribe\""

Interoperability

EEP and MCP

EEP and OpenAPI

EEP and ActivityPub / AT Protocol

EEP and Enterprise API Gateways

Next steps