Module dispatch 

Transport-neutral dispatch — the shared core of ATD-speaking servers.

SP-streamable-http §4.3 + §6.3: the body of atd-server::connection.rs’s per-request switch moves here so the Unix-socket listener and the Streamable-HTTP listener (atd-server-http) drive the same dispatch state machine over the same Arc<Registry>. The wire shape returned is byte-identical regardless of which transport delivered the request — this property is exercised by atd-server-http’s UDS↔HTTP parity test.

Two entry points:

1. dispatch_request — handles the full Request enum (Ping / Hello / ToolList / ToolSchema / RunTool). UDS uses this from handle_connection’s read loop; capability set + caller identity are mutated in place because Hello rewrites both for the lifetime of the connection.

2. run_tool — the RunTool arm extracted for HTTP. HTTP requests derive their CapabilitySet and caller_id fresh from a Bearer-token lookup per request (SP-streamable-http §4.3), so there is no connection state to carry forward — the listener calls run_tool directly with the freshly-derived inputs.

Both routes share the same audit emission, capability gate, semaphore permit, token-broker resolution, binding-dispatch, middleware, and error mapping. Any future SP that adds a third transport (vsock, quic, …) should reach for these two entry points rather than re-implementing the switch.

Structs

ServerState

Shared dispatch state. Listener crates own one Arc<ServerState> and hand the clone to per-connection / per-request dispatch.

SharedServerConfig

Transport-neutral configuration shared across listeners.

Functions

dispatch_request

Run the full Request state machine and produce a Response.

run_tool

Execute one RunTool request against the shared dispatch state.

run_tool_continue

SP-pagination-v1 §4.4 — handle a Request::RunToolContinue.