Docs Proxy

The action MCP server adds one tool — typically named docs or <server>_docs — whose entire job is to forward queries to the canon-server with the action server's own repo URL pinned as the knowledge_base_url parameter.

• Inputs: query (required), audience (optional, server-defined enum), depth (optional 1|2|3 — snippet, full top doc, top + next two)
• Returns: { answer, sources[], deeper[], governance_source }
• Failure: graceful degradation when the canon-server is unreachable — { answer: null, sources: [], governance_source: "minimal", error } rather than a hard error that blocks consumer flow

The proxy tool knows exactly two URLs: this server's canon repo and the canon-server's MCP endpoint. It holds zero domain semantics. It does not parse, rank, filter, score, or reframe results. It is a pinned forwarding layer.

If the proxy ever grows a domain-flavored taxonomy or a scoring tweak, that taxonomy moves into governance documents in the canon repo (which the canon-server retrieves through the same proxy), not into the tool's implementation. Domain logic in the proxy is a vodka-boundary leak.

Without the pattern, every consumer pays a wire-two-MCPs tax: one MCP for actions, a second MCP for canon retrieval, configured with the action server's repo as knowledge_base_url. Consumers who do not pay the tax lose canon-in-flow access at the moment they need it most. The pattern absorbs the tax once, server-side, for every present and future consumer.

This pattern is orthogonal to canon/principles/consistency-same-pattern-every-time, which covers the same-server-many-knowledge-bases axis. This pattern covers many-servers-one-knowledge-base. Both are real; both deserve canon coverage.

Without this pattern: per-consumer onboarding friction; canon drifts from living context to web-search-of-last-resort; the canon-as-living-context value proposition silently degrades because consumers never wire it.

With the pattern: one MCP wired, both surfaces accessible; canon stays in-flow as designed.

• PTXprint-MCP v1.2 §3 docs tool. Added in session 13 (2026-04-29), reversing v1.0's "no retrieval in MCP server" decision with explicit rationale: downstream agents like BT Servant want one MCP wiring. Vodka boundary preserved.
• (Future receipts: each server adopting the pattern adds one row — server, tool name, date adopted, link to spec section.)