MCP agent.run_subagent cannot dispatch integrations_agent, leaving MCP-driven brains no route to Composio toolkits

[nocstah]

Summary

The MCP server's agent.run_subagent hard-rejects integrations_agent ("does not yet support … toolkit binding"), so an MCP-driven brain (e.g. the claude-code provider) has no route to Composio toolkits at all — Gmail/Calendar/Notion tasks delegated over the bridge dead-end after wasted tool-call round-trips.

Problem

What happened vs expected: the MCP surface deliberately exposes delegation instead of raw composio_* tools (a sound design — the specialists own the prompts and approval contracts). But the one delegate that can reach a toolkit, integrations_agent, is explicitly stubbed in run_subagent_tool (src/openhuman/mcp/server/tools/dispatch.rs):

agent.run_subagent does not yet support `integrations_agent`; first-level MCP support is currently limited to standalone agents that do not require toolkit binding

Observed consequence with a claude-code brain: the model tries tools_agent (composio-blind by design — its own docs route integrations to integrations_agent), gets "Composio tools are not available", tries integrations_agent, gets the hard reject, then burns further turns probing for alternate routes (including shelling toward the core's RPC port, which the Seatbelt jail correctly blocks). Net: an expensive multi-minute failure for a task the in-core orchestrator handles in one delegate call.

Steps to reproduce:

1. Claude Code provider as the brain; a connected Composio toolkit (e.g. Gmail, direct mode).
2. Ask for anything toolkit-bound ("list my recent emails").
3. Watch the delegation chain fail: tools_agent (no composio tools) → agent.run_subagent {agent_id: integrations_agent} → InvalidParams hard-reject.

Version/platform: v0.63.x, any platform, MCP server surface.

Solution (optional)

Design decision for maintainers rather than a drive-by patch — a naive fix (attaching raw composio tools to the bridge's plain Agent::run_single path) would create exactly the "second, weaker route to the same capability" the tools_agent docs warn against, bypassing the typed spawn's prompt-context integration, fuzzy tool filter, and scope gating. Options that keep one route:

1. Accept an optional toolkit param on agent.run_subagent and dispatch through the typed spawn path (subagent_runner::ops::runner::run_subagent), establishing the parent-execution context the MCP surface currently lacks.
2. Expose the orchestrator's own delegate_to_integrations_agent synthesized tool over the MCP surface (it already carries the toolkit argument and the right contract).

Either way, the current schema (agent_id + prompt only, additionalProperties: false) plus the listed sub-agents inviting integrations_agent by name makes the dead end discoverable only at call time; if support stays out, agent.list_subagents could at least flag it as not-dispatchable over MCP.

Acceptance criteria

• Repro gone — an MCP-driven brain can complete a toolkit-bound task through a single supported delegation route.
• Regression safety — a test covers toolkit-bound delegation over the MCP surface (or pins the advertised list to exclude non-dispatchable agents).
• Diff coverage ≥ 80% — the implementing PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/ci-lite.yml).

Related

Sibling report: the memory_tree substring-search footgun surfaced in the same investigation. Related mode-awareness report: #5732.