A prompt handler that may, on a stateless (MRTR) draft request, ask the client for more input instead of returning a final result. See PromptResponse.
A tool handler that may, on a stateless (MRTR) request, ask the client for more input instead of returning a final result. See ToolResponse.
A resource template reader receiving the concrete URI, the captured {var} parameters, and the per-request RequestContext (so a template handler can log, observe cancellation, or elicit through the real request channel).
A tool handler receiving the parsed arguments and the per-request context.
The transport-agnostic core of an MCP server.
How a server manages per-connection state. The author chooses; stateless is the default. See the README "Statefulness" section for the full feature-gating matrix.
Match a concrete uri against an RFC 6570-style template containing {var} placeholders (each capturing a non-empty run up to the next literal). On success, fills params with the captured values and returns true.
The MRTR (input-required) machinery shared by ToolResponse and PromptResponse: the needsInput_/required_ state, the needsInput/inputRequests/requestState accessors, the two non-typed inputRequired factories, and withInputRequests/toJson. Both response types carry an InputRequiredResult required_ plus a result_ final result of their respective type; toJson switches on needsInput_. The mixin keeps these in lockstep so MRTR edits land on both. The genuine divergences — forVersion (throw vs return on a non-MRTR peer) and ToolResponse's typed complete(T)/inputRequired(T) helpers — stay per-struct.
The outcome of a prompts/get call: either the final GetPromptResult, or — on a stateless (MRTR) draft request — a set of InputRequests the client must satisfy and resubmit. This mirrors ToolResponse for the prompts path: the draft schema types GetPromptResultResponse.result as GetPromptResult | InputRequiredResult, so a prompt handler that needs more input ends the request with inputRequired(...) and the client opens a fresh prompts/get carrying the matching inputResponses (and any requestState).
A registered prompt: descriptor + handler producing its messages. The handler always returns a PromptResponse; the GetPromptResult-returning registration overload is adapted to one that always completes.
A registered direct resource: descriptor + reader producing its contents.
A registered resource template: descriptor + reader receiving the concrete URI, the captured {var} parameters, and the per-request context.
A registered tool: its descriptor plus the handler that executes it. The handler always returns a ToolResponse; the CallToolResult-returning registration overloads are adapted to one that always completes.
The outcome of a tool call: either the final CallToolResult, or — on a stateless (MRTR) request — a set of InputRequests the client must satisfy and resubmit. There is no suspension or shared state: inputRequired simply ends this request, and the client opens a fresh one carrying the answers.