Skip to main content

code_mode_http_tools_from_executor

pmcp_server_toolkit::code_mode

Function code_mode_http_tools_from_executor 

Source 
pub fn code_mode_http_tools_from_executor(
    builder: ServerBuilder,
    config: &ServerConfig,
    base: HttpCodeExecutor,
    exec_config: ExecutionConfig,
    flavor: ValidationFlavor,
) -> Result<ServerBuilder>
Expand description

Register validate_code + execute_code on builder for the OpenAPI per-request Code-Mode path (Plan 90-10 / OAPI-03 / OAPI-05).

This is the per-request analog of code_mode_tools_from_executor. Where that helper takes a FIXED type-erased Arc<dyn CodeExecutor> (the SQL path, whose SqlCodeExecutor carries no per-request state), this helper takes the concrete HttpCodeExecutor base + ExecutionConfig so the [tool_handlers::ExecuteCodeHandler] can RE-DERIVE a request-scoped JsCodeExecutor per call via request_executor_from_extra — threading the captured inbound MCP token so an oauth_passthrough backend forwards it to the real backend.

The reason a per-request entry point is required: a JsCodeExecutor’s inner http field is private with no accessor, so a type-erased Arc<dyn CodeExecutor> cannot be re-derived per request. Holding the base HttpCodeExecutor (which IS Clone + has the with_inbound_token builder) makes the per-request rederivation possible WITHOUT changing the SQL path.

The validate_code handler is identical to the code_mode_tools_from_executor one; only execute_code differs (it carries the [tool_handlers::ExecSource::PerRequestHttp] source instead of [tool_handlers::ExecSource::Static]).

§Errors

Surfaces every error from validation_pipeline_from_config when config.code_mode.is_some() (R9 inline-secret rejection, secret-resolution / 16-byte-minimum failures). No-op (returns the builder unchanged) when config.code_mode.is_none().