pub struct AprMcpServer { /* private fields */ }Expand description
MCP server exposing the apr CLI as tools.
M1: initialize, tools/list, tools/call with apr.version.
M3: notifications/cancelled routed to in-flight apr.run workers.
Implementations§
Source§impl AprMcpServer
impl AprMcpServer
Sourcepub fn handle_request(&mut self, request: &JsonRpcRequest) -> JsonRpcResponse
pub fn handle_request(&mut self, request: &JsonRpcRequest) -> JsonRpcResponse
Dispatch a single JSON-RPC request synchronously.
This is the in-process test entry point. It does NOT exercise the
threading / cancellation machinery — apr.run runs inline with a
dummy never-firing cancel receiver and NO notification sink is
attached, so apr.finetune silently falls back to its synchronous
path even if the request carries params._meta.progressToken. Use
Self::run_stdio for the full M3 dispatcher or
Self::handle_request_with_sink to drive FALSIFY-MCP-PROGRESS-001
in tests.
The dispatcher enforces two protocol-level invariants before routing:
FALSIFY-MCP-005 (jsonrpc must be exactly "2.0" or the response is
-32600 Invalid Request) and FALSIFY-MCP-007 (an initialize whose
params.protocolVersion mismatches ours returns -32602 Invalid Params
instead of advancing to tools/list).
Sourcepub fn handle_request_with_sink(
&mut self,
request: &JsonRpcRequest,
sink: &NotificationSink,
) -> Option<JsonRpcResponse>
pub fn handle_request_with_sink( &mut self, request: &JsonRpcRequest, sink: &NotificationSink, ) -> Option<JsonRpcResponse>
Dispatch one request with an explicit notification sink (test entry point for FALSIFY-MCP-PROGRESS-001).
The sink is only exercised for tools/call dispatches where
(a) the client supplied params._meta.progressToken on the original
request AND (b) the target tool supports progress streaming
(currently apr.finetune and apr.run). Other methods ignore the
sink.
handle_request_with_sink returns None for notifications (methods
prefixed with notifications/) because notifications have no id and
MUST NOT receive a response per JSON-RPC 2.0. All other methods
return Some(response).
Sourcepub fn tool_definitions(&self) -> Vec<ToolDefinition>
pub fn tool_definitions(&self) -> Vec<ToolDefinition>
All tool definitions registered on this server.
Sourcepub fn register_in_flight(
in_flight: &Arc<Mutex<HashMap<Value, CancelHandle>>>,
id: Value,
) -> Receiver<()>
pub fn register_in_flight( in_flight: &Arc<Mutex<HashMap<Value, CancelHandle>>>, id: Value, ) -> Receiver<()>
Register a new in-flight request and return its cancel receiver.
Exposed for testing the cancellation routing without spawning a real
worker. Production code calls this from Self::run_stdio.
Sourcepub fn cancel_in_flight(
in_flight: &Arc<Mutex<HashMap<Value, CancelHandle>>>,
id: &Value,
) -> bool
pub fn cancel_in_flight( in_flight: &Arc<Mutex<HashMap<Value, CancelHandle>>>, id: &Value, ) -> bool
Route a notifications/cancelled to the matching in-flight request.
Idempotent: repeated cancels for the same id after the first are
silently dropped. References to completed / unknown ids are no-ops.
Returns true iff a live handle was signalled.
Sourcepub fn run_stdio(&mut self) -> Result<()>
pub fn run_stdio(&mut self) -> Result<()>
Run the server over stdio (blocking).
Reads one JSON-RPC message per line from stdin. initialize,
tools/list, and unknown methods dispatch inline. tools/call
spawns a worker thread so a subsequent notifications/cancelled
message can flow through the main loop and signal the worker’s
cancel channel. Workers write their responses directly to stdout
(guarded by a mutex) so the main loop never has to wait on them.
§Errors
Returns an error if stdin/stdout I/O fails.
Sourcepub fn in_flight_handle(&self) -> Arc<Mutex<HashMap<Value, CancelHandle>>>
pub fn in_flight_handle(&self) -> Arc<Mutex<HashMap<Value, CancelHandle>>>
Handle for tests that want to inspect the in-flight registry.