Docs cookbook proposal: deterministic project handoffs with Doc Bridge MCP

Docs cookbook proposal: deterministic project handoffs with Doc Bridge MCP

What problem would this cookbook solve?

Giving a coding agent access to documentation does not necessarily tell it which document is authoritative, where a change is allowed, or which checks apply. In larger repositories, the agent can still spend time searching broadly or guess the wrong edit boundary.

I would like to contribute a focused Continue cookbook showing a workspace-local Doc Bridge MCP setup. The example would let a Continue user ask for a package handoff and receive explicit fields such as startHere, editRoots, checks, and the matching human documentation before making a change.

Why this may be useful to Continue users

• The MCP server is read-only and requires no credential of its own.
• The configuration pins the released npm package and does not add a dependency or lockfile to the user's project.
• The workflow is model-provider independent; the MCP contract does not depend on a specific LLM vendor.
• The example would use a small synthetic repository, so the behavior is reproducible without relying on private code or product-specific assumptions.

Validation already completed

I tested @agentskit/doc-bridge@1.2.6 with @continuedev/cli@1.5.47 in a disposable workspace using --readonly and Continue's documented MCP configuration. Continue registered all eight Doc Bridge tools and successfully called registry.topology with an empty object. The fixture received no package manifest, lockfile, or stored credential. The test used OpenRouter's free router only to exercise the client/tool loop.

Proposed contribution, if this fits the docs roadmap

The PR would be limited to:

1. one MCP cookbook following the structure of the existing Continue cookbooks;
2. a workspace-local configuration example pinned to Doc Bridge 1.2.6;
3. a synthetic walkthrough covering handoff resolution and topology inspection;
4. concise troubleshooting for missing Doc Bridge configuration; and
5. the corresponding navigation entry.

It would not change Continue code or make the cookbook promotional. I would also run the documentation checks required by the repository before opening the PR.

Would this be useful in the current cookbook collection? If so, is there a preferred location or naming convention beyond the existing MCP cookbook pattern?

Start by reviewing the existing Continue cookbooks and their navigation entries, then check the repository's documented documentation checks. The contribution is done when it includes the workspace-local Doc Bridge MCP configuration pinned to 1.2.6, the synthetic handoff and topology walkthrough, troubleshooting guidance, navigation, and passing documentation checks.