Problem
newClankerMCPServer registers ~30 tools but zero MCP resources and zero prompts. The HTTP transport is created WithStateLess(true) (mcp.go:160), which precludes resource subscriptions and any per-session run state. The plan/apply tools are blocking RPCs: clanker_cloud_apply_plan posts to /api/maker/apply via client.CallAPI and returns a single final JSON blob (mcp.go:526-555) — the backend's streaming apply progress (events, per-command success/failure) is never surfaced to the MCP client, so an MCP-driven agent cannot watch or react to an in-flight apply. Generated Maker plans are returned inline as tool output rather than registered as addressable MCP resources (e.g. clanker://plans/{id}) that can be referenced, diffed, or re-applied. Maker checkpoints/run history are likewise invisible over MCP.
Where
cmd/mcp.go:169-428cmd/mcp.go:316-326cmd/mcp.go:526-555cmd/mcp.go:159-162
Root cause
MCP was implemented as a flat tool gateway (one request → one result) rather than as a stateful agent server. The mcp-go server supports resources, prompts, and notifications, but none are used, and stateless HTTP rules out streaming/subscriptions.
How to fix
Add MCP resources for plans, maker runs/checkpoints, and the infra snapshot (server.AddResource with clanker://plans/{id}, clanker://runs/{id}). For apply, either return a runId resource the client can poll/subscribe to, or use the streamable-HTTP server's notification/progress channel to emit per-command events instead of buffering. Register a few prompts (e.g. 'plan-and-review-change') so MCP hosts get guided flows. Drop WithStateLess(true) (or offer a stateful mode) so resource subscriptions work.
Acceptance criteria
An MCP client can read a generated plan as a resource, apply it, and receive incremental progress events (not just a terminal blob), and can list prior maker runs over MCP.
Severity: medium · from holistic hardening review.
Problem
newClankerMCPServerregisters ~30 tools but zero MCP resources and zero prompts. The HTTP transport is createdWithStateLess(true)(mcp.go:160), which precludes resource subscriptions and any per-session run state. The plan/apply tools are blocking RPCs:clanker_cloud_apply_planposts to/api/maker/applyviaclient.CallAPIand returns a single final JSON blob (mcp.go:526-555) — the backend's streaming apply progress (events, per-command success/failure) is never surfaced to the MCP client, so an MCP-driven agent cannot watch or react to an in-flight apply. Generated Maker plans are returned inline as tool output rather than registered as addressable MCP resources (e.g.clanker://plans/{id}) that can be referenced, diffed, or re-applied. Maker checkpoints/run history are likewise invisible over MCP.Where
cmd/mcp.go:169-428cmd/mcp.go:316-326cmd/mcp.go:526-555cmd/mcp.go:159-162Root cause
MCP was implemented as a flat tool gateway (one request → one result) rather than as a stateful agent server. The mcp-go server supports resources, prompts, and notifications, but none are used, and stateless HTTP rules out streaming/subscriptions.
How to fix
Add MCP resources for plans, maker runs/checkpoints, and the infra snapshot (
server.AddResourcewithclanker://plans/{id},clanker://runs/{id}). For apply, either return arunIdresource the client can poll/subscribe to, or use the streamable-HTTP server's notification/progress channel to emit per-command events instead of buffering. Register a few prompts (e.g. 'plan-and-review-change') so MCP hosts get guided flows. DropWithStateLess(true)(or offer a stateful mode) so resource subscriptions work.Acceptance criteria
An MCP client can read a generated plan as a resource, apply it, and receive incremental progress events (not just a terminal blob), and can list prior maker runs over MCP.
Severity: medium · from holistic hardening review.