An refrakt_validate MCP tool returning structured findings
The MCP surface has plan_validate and no content equivalent — which is exactly the gap an agent falls into. It can check the plan graph it just edited, and not the content.
The MCP surface has plan_validate and no content equivalent — which is exactly the gap an agent falls into. It can check the plan graph it just edited, and not the content.
Tracking started Sep 20 — check back for trends.
This project's author population is unusual: the plan directory is agent-authored and the documentation is agent-edited. An agent that can check its own content in a second, with structured findings rather than scraped stderr, is a materially different authoring loop from one that must run a build and parse text.
It is also the third caller of the same validation function — build, CLI, MCP — which is the shape SPEC-135 D5 exists to produce.
refrakt_validate is registered on the MCP server with typed inputs mirroring the CLI: site, only, deepdeep adds cross-page checks, so a caller can choose knowinglyrefrakt.* tools in CLAUDE.md's substitution tableThin over WORK-578. The work is the binding and the input schema, not the validation.
Return findings, not the CLI's output. A tool that returns formatted text is a worse CLI — the point of the tool is that a caller can filter, count and act on individual findings. This is SPEC-135 D6, and it is the one thing here worth being strict about.
Worth deciding while implementing: what happens on a site with hundreds of findings. A cap with a "and N more" count is probably right; unbounded output is not.
plugins/plan/src/mcp-bindings.ts — the binding pattern to followpackages/mcp/ — the server this registers on