Sessions and revocation
A protocol session holds state needed to continue a conversation with a stateful MCP server. Operational correlation is different: a stateless request can be audited without creating a protocol session.
Revocation changes what can run
Scroll the diagram sideways to see the full flow →
Read the full explanation
- A stateful session starts only after identity, policy, and runtime readiness checks.
- Active session metadata tracks the route and affinity outside the worker process.
- Drain stops admission of new stateful sessions while existing work has a bounded completion window.
- Revocation invalidates affected access. Expired, missing, or revoked state cannot authorize a new call.
Keep state outside the worker
Section titled “Keep state outside the worker”Amelfi tracks session metadata outside individual workers. PostgreSQL provides durable truth and Valkey supports active session indexing. Routing checks the session state and affinity before forwarding a request.
Missing, expired, or revoked state must fail closed. A reconnect must not silently recreate access that was revoked.
Drain allows bounded completion
Section titled “Drain allows bounded completion”During an upgrade, drain rejects new stateful sessions while allowing existing work to end or complete within the configured timeout. It is an operational action, not a grant of continued access after a security revocation.
Revocation removes access
Section titled “Revocation removes access”Revocation can affect an identity, agent, credential binding, or resource. Verify the affected target and active sessions, then test a new call using the revoked authority. Both the configuration change and runtime outcome belong in the investigation.
Do not treat the diagram as the exact API enum: it explains the lifecycle. Consult the schemas for accepted state values.
Continue with managing sessions or incident containment.
Implementation reference
Section titled “Implementation reference”Amelfi documentation · Space Grotesk / Geist Mono