Expand description
Construct MCP server — exposes Construct’s built-in tools over the MCP Streamable HTTP transport (JSON-RPC 2.0 + SSE) so external CLIs (Claude Code, Codex, OpenCode, Gemini CLI) can share one local backend.
The MCP server runs as an in-process tokio task inside the main construct
daemon (see src/gateway/mod.rs::run_gateway). External clients discover
it through ~/.construct/mcp.json, written by the gateway as soon as the
MCP task finishes binding to its ephemeral port.
This module contains the router, session store, tool registry, and
ProgressSink that publishes notifications/progress events onto the
originating SSE stream.
Design notes:
- One daemon, many sessions; sessions are in-memory only.
- Auth is a
session_id+bearer tokenpair; no persistence. - MCP keeps its own ephemeral port and its own auth pair — it does NOT share the gateway’s listener or pairing model.
- Tools are enumerated once at startup via
registry::build_tools_with_runtime(config-aware + wired to live runtime handles) so every tool the gateway can run is also exposed to MCP clients.registry::build_default_toolsandregistry::build_tools_with_configare retained as the degraded fallback and the test entry point.
Re-exports§
pub use runtime::RuntimeHandles;pub use server::McpServerHandle;pub use server::run_daemon;pub use server::serve_on;pub use session::ProgressEvent;
Modules§
- progress
ProgressSinkimplementation that publishes MCPnotifications/progressJSON-RPC messages onto a per-request channel. The HTTP handler wires the receiver end into an SSE stream that ships events back to the client.- progress_
wrap - Thin wrapper that adds
start+finishprogress notifications around an underlying tool’sexecute()body. - registry
- Tool registry used by the MCP daemon.
- runtime
- Runtime handles the MCP server may optionally receive from the main daemon.
- server
- Axum-based MCP daemon.
- session
- Session state for the MCP daemon.
- skills_
tools - Skill meta-tools exposed by the in-process MCP server.