6.2 Request lifecycle

For a typical remember call:

  1. Client sends POST /mcp with Authorization: Bearer JWT and JSON-RPC envelope.
  2. Tomcat dispatches to MCPServer.service(), which delegates to Kiss’s MCPServerBase.
  3. authenticate() validates the JWT via Kiss’s BearerTokenValidator: signature against the AS’s JWKS, iss against OAuthAuthorizationServer, aud against the resource identifier, exp against the clock, and any configured OAuthRequiredScopes. Validated tokens are cached for 60 seconds keyed by their SHA-256 hash so a chatty MCP session doesn’t re-verify the same JWT on every call. Failure: 401 with an RFC 6750 / RFC 9728 WWW-Authenticate challenge pointing at /.well-known/oauth-protected-resource.
  4. The base class parses the JSON-RPC envelope and calls the appropriate handler — doRemember, doRecall, etc.
  5. The handler validates inputs against the tool’s schema, runs SecretScanner for write paths, normalizes tags, and calls MemoryService.
  6. MemoryService opens a fresh Connection from MainServlet.openNewConnection(), optionally invokes the EmbeddingProvider (one HTTP call out to OpenAI or whatever’s configured), and runs the SQL via MemoryRepository. The connection is closed with closeConnection(db, success), which commits on success=true and rolls back on false.
  7. The result is wrapped as a tool result and shipped back as JSON-RPC.

Recall is structurally similar but read-only: one embedding call for the query text, one vector-similarity SELECT, no transaction commit.