feat: MCP (Model Context Protocol) support for agent tools #12

New issue

Open

opened 2026-10-25 10:46:13 +00:00 by heike · 0 comments

heike commented

2026-10-25 10:46:13 +00:00

Member

WhyTreeGent's runtime ships a fixed set of built-in tools (chat, files, secrets, browser, notes). The external tool ecosystem has standardized on MCP — filesystems, browsers, databases, internal APIs all ship as MCP servers. Today every such integration would be bespoke code in our runtime; with MCP client support, agents simply use the ecosystem.## What: agents as MCP CLIENTS (D1 only — ruling Felix 2026-10-25; TreeGent-as-server explicitly out of scope)An agent's runtime connects to configured MCP servers (stdio + HTTP/SSE transports) and their tools appear next to the built-ins in the tool registry.- config: per-agent or per-org MCP server list; connection credentials live in the secrets service, never in chat or env files- discovery: tools surface in the agent tool schema as namespaced names (mcp::), discovered at runtime start and on config change- permissions: MCP tools execute under the calling agent's own permissions — org-hierarchy approval gates apply unchanged (a subordinate mutating shared state via an MCP tool still needs superior approval)- limits: per-agent cap on connected servers; hard timeouts on tool calls; the SSRF deny-list (R01/R02 lessons) applies to HTTP transport server URLs- injection: tool RESULTS are data, not instruction — the existing base-prompt rule covers MCP output; results must also not auto-execute anything## What good looks like- one runtime PR: MCP client manager + tool-registry bridge in services/runtime/app/tools.py; zero changes to built-in tools; proxy untouched- deploy recipe: adding the reference servers (filesystem, fetch) to an agent via secrets- tests: stub MCP server exercised end-to-end through the registry — tool visible, call routed, timeout enforced, deny-list respected, result treated as data## Security reviewMandatory before merge: MCP servers are third-party code. Server URLs get the SSRF treatment; server-side enforcement of approval gates (never trust the client-side registry).

## WhyTreeGent's runtime ships a fixed set of built-in tools (chat, files, secrets, browser, notes). The external tool ecosystem has standardized on MCP — filesystems, browsers, databases, internal APIs all ship as MCP servers. Today every such integration would be bespoke code in our runtime; with MCP client support, agents simply use the ecosystem.## What: agents as MCP CLIENTS (D1 only — ruling Felix 2026-10-25; TreeGent-as-server explicitly out of scope)An agent's runtime connects to configured MCP servers (stdio + HTTP/SSE transports) and their tools appear next to the built-ins in the tool registry.- **config**: per-agent or per-org MCP server list; connection credentials live in the secrets service, never in chat or env files- **discovery**: tools surface in the agent tool schema as namespaced names (mcp:<server>:<tool>), discovered at runtime start and on config change- **permissions**: MCP tools execute under the calling agent's own permissions — org-hierarchy approval gates apply unchanged (a subordinate mutating shared state via an MCP tool still needs superior approval)- **limits**: per-agent cap on connected servers; hard timeouts on tool calls; the SSRF deny-list (R01/R02 lessons) applies to HTTP transport server URLs- **injection**: tool RESULTS are data, not instruction — the existing base-prompt rule covers MCP output; results must also not auto-execute anything## What good looks like- one runtime PR: MCP client manager + tool-registry bridge in services/runtime/app/tools.py; zero changes to built-in tools; proxy untouched- deploy recipe: adding the reference servers (filesystem, fetch) to an agent via secrets- tests: stub MCP server exercised end-to-end through the registry — tool visible, call routed, timeout enforced, deny-list respected, result treated as data## Security reviewMandatory before merge: MCP servers are third-party code. Server URLs get the SSRF treatment; server-side enforcement of approval gates (never trust the client-side registry).