Context
mcp_serve.py registers 9 canvas tools (canvas_list, canvas_open, canvas_add_node, canvas_move_node, canvas_update_node, canvas_delete_node, canvas_link_nodes, canvas_delete_edge, canvas_search) shipped under #56 — those make devagentic's canvas surface available to any MCP-aware client (Claude Code, Cursor, Codex) as tools.
The just-shipped devagentic-docs plugin (#12 / PR #19+#20+#23) has no MCP equivalent. The slash-command surface works inside hermes sessions, but a federated agent talking to hermes over MCP can't writeDoc / searchDocs / forkContext / decorateContext / renderContext even though hermes itself has all the wire-format scaffolding ready.
Scope
Mirror the canvas-tools pattern from mcp_serve.py:907- (_register_canvas_tools):
_resolve_docs_client() — file-path import of plugins/devagentic-docs/client.py, sibling to _resolve_canvas_client() at line 880._register_docs_tools(mcp) — register at minimum:
doc_search(query, limit, tag) → search_docsdoc_write(content, tags, source) → write_docdoc_show(doc_id) → get_docfork_open(parent_id, goal, tags) → fork_contextfork_decorate(ctx_id, key, value, weight) → decorate_contextfork_get(ctx_id) → get_contextfork_render(ctx_id) → render_context
- Each tool: return JSON string.
{"error": "..."} on failure (mirrors canvas tools' contract — never raise). All errors thread through last_error_text() so MCP clients see the specific cause.
Transport caveat
These tools depend on devagentic exposing /graphql over HTTP. Until #21 is resolved upstream, they'll silently return {"error": "not found at <url>/graphql ..."} against the canonical devbox deployment. That's the correct behavior — same loud-error semantics as the slash commands — and the MCP wiring is independently testable.
Out of scope
fork_close / fork_pin analogs — those depend on the local $HERMES_HOME/docs-fork-active marker, which is session-local state. An MCP client doesn't share session state with the hermes process; "active fork" is a slash-command concept that doesn't translate to MCP's stateless tool model. Mirror the canvas plugin's choice (it exposes canvas_open but not canvas-active marker management over MCP).
Filed by hermes-maintainer (PowerCreek). PR incoming.
Context
mcp_serve.pyregisters 9 canvas tools (canvas_list, canvas_open, canvas_add_node, canvas_move_node, canvas_update_node, canvas_delete_node, canvas_link_nodes, canvas_delete_edge, canvas_search) shipped under #56 — those make devagentic's canvas surface available to any MCP-aware client (Claude Code, Cursor, Codex) as tools.The just-shipped devagentic-docs plugin (#12 / PR #19+#20+#23) has no MCP equivalent. The slash-command surface works inside hermes sessions, but a federated agent talking to hermes over MCP can't
writeDoc/searchDocs/forkContext/decorateContext/renderContexteven though hermes itself has all the wire-format scaffolding ready.Scope
Mirror the canvas-tools pattern from
mcp_serve.py:907-(_register_canvas_tools):_resolve_docs_client()— file-path import ofplugins/devagentic-docs/client.py, sibling to_resolve_canvas_client()at line 880._register_docs_tools(mcp)— register at minimum:doc_search(query, limit, tag)→search_docsdoc_write(content, tags, source)→write_docdoc_show(doc_id)→get_docfork_open(parent_id, goal, tags)→fork_contextfork_decorate(ctx_id, key, value, weight)→decorate_contextfork_get(ctx_id)→get_contextfork_render(ctx_id)→render_context{"error": "..."}on failure (mirrors canvas tools' contract — never raise). All errors thread throughlast_error_text()so MCP clients see the specific cause.Transport caveat
These tools depend on devagentic exposing
/graphqlover HTTP. Until #21 is resolved upstream, they'll silently return{"error": "not found at <url>/graphql ..."}against the canonical devbox deployment. That's the correct behavior — same loud-error semantics as the slash commands — and the MCP wiring is independently testable.Out of scope
fork_close/fork_pinanalogs — those depend on the local$HERMES_HOME/docs-fork-activemarker, which is session-local state. An MCP client doesn't share session state with the hermes process; "active fork" is a slash-command concept that doesn't translate to MCP's stateless tool model. Mirror the canvas plugin's choice (it exposes canvas_open but not canvas-active marker management over MCP).Filed by hermes-maintainer (PowerCreek). PR incoming.