Skip to main content

Module application

Module application 

Source
Expand description

Application layer: one module per use case.

Each handler declares the narrow port trait it consumes, inline, in its own module. A handler returns domain error types, never a third-party one: adapters map their own failures into domain errors at the boundary, so no infrastructure error type ever appears in a signature here.

Populated by T06 (negotiation), T08 (codecs), T09 (JSON-RPC routing), T10 (session engine), T11 (dynamic registry), T12 (server and client APIs) and T14 (the idempotency store a retried tools/call is deduplicated through).

Modules§

a2a
A2A’s application layer — use cases the wire codec routes into.
acp
ACP’s application layer — use cases the wire codec routes into.
bridge
The bridge use case.
client
Client — the calling side of a negotiated session.
idempotency
The port a peer-observable side effect is deduplicated through.
jsonrpc
Routing a decoded JSON-RPC message to a method, without naming one.
mcp
Protocol-specific application logic shared by more than one entry point.
oauth
OAuth 2.1 authorization, as MCP’s revisions specify it.
registry
The use case: a set of tools, resources, templates and prompts that changes while sessions are using it.
server
The server API: what a handler is given, and what it is allowed to ask for.
session
The session engine: one use case, assembled from a lifecycle and three ports.