Orchestrator never delegates to the MCP and skill sub-agents: their hand-off tools are withheld by tool packs

[M3gA-Mind]

Summary

The orchestrator never hands off to the built-in MCP and skill sub-agents (MCP Setup Agent, MCP Agent, Skill Setup Agent, Skill Executor Agent), even though all four are enabled in Settings → Agents. Any request that needs one of them fails: installing or running a skill, using an already-connected MCP server, or adding a new one. In 11 live turns on a real account, the orchestrator called setup_skills, run_skill, use_mcp_server or setup_mcp_server zero times.

Class of task broken

Every request whose right execution shape is a hand-off to a specialist that lives inside a tool pack, rather than on the orchestrator's belt. Today that is at least the four MCP/skill specialists; the same mechanism also withholds do_crypto, build_workflow and discover_workflows.

Evidence (live, 2026-09-15/16)

Same account, same prompts, on v0.63.28 (release 1a60c7480) and on main 494b187d7 (after #6288, #6289, #6291, #6294, #6298):

Scenario	Result on both builds
"Find the dynamic-workflow skill and install it, then run it"	Nothing installed. Orchestrator called use_skill skills/skill_registry_search itself, then guessed use_skill skills/install_skill → "not allowed in the current session" → stopped.
"Install the benchmark skill from gstack"	Same: search itself, guessed install_skill, stopped.
"Install a code review skill"	Searched itself 3×, halted by the repeat guard.
"Use the connected UUID MCP server to generate a UUID"	Server connected and working (a direct mcp_clients_tool_call returned a UUID). Orchestrator looped use_skill integrations + mcp_registry_installed_list/_status; never called use_mcp_server.
"Set up the weather MCP server and use it"	Looped mcp_registry_search/_status; tried use_skill mcp_setup (invalid pack); never called setup_mcp_server.

The connection/install plumbing itself works: registry search, SKILL.md download, MCP install, connect and tools/call all succeed when called directly.

Root cause

1. The hand-offs are withheld from the orchestrator's belt. Tool packs (perf(agent): cut the Master Agent's fixed token floor by 26% (envelope de-duplication + 50-token description cap) #5666, 2026-08-21) put use_mcp_server + setup_mcp_server in the integrations pack and run_skill + setup_skills in the skills pack (tools/toolpacks/registry.rs). The orchestrator is not an owner, so strip_packed_from_visible removes them. Its live belt is 28 tools: research, run_code, review_code, retrieve_memory, delegate_to_integrations_agent are direct; the four MCP/skill hand-offs are not. orchestrator/agent.toml still describes delegates as first-class entries in the function-calling schema, and DELIBERATELY_UNPACKED_FLEET_TOOLS keeps the frequently used delegation family off packs, but these four were not on it. collapsed_delegation.rs itself argues delegation should not be packed ("putting a round trip in front of it would tax the single most common thing it does").
2. The pack listing exposes raw tools the orchestrator may call. integrations shows use_mcp_server next to nine mcp_registry_* tools; skills shows setup_skills/run_skill next to skill_registry_*. The model uses the raw tools itself instead of handing off.
3. The prompt steers away from the hand-off. prompt.md is direct-first: rule 3 "Solvable with a direct tool — do it yourself" precedes rule 4 "Needs a specialist", and rule 4 routes weather/live asks to web tools or research. There is no routing row for skills or MCP.
4. Contradictory text. The generated ## Capabilities not in your tool list correctly says to reach use_mcp_server through use_skill, but the hand-written ## Connected MCP Servers block (format_connected_mcp_block) says "you MUST delegate with use_mcp_server" as if it were callable. ## Installed Skills names no hand-off.
5. Recovery points nowhere. An unknown or invented tool name inside use_skill gets "Tool x is not allowed in the current session" (tool_policy.rs, session allowlist checked before existence) with no hint; the model reads it as "installs are forbidden".

Decision

Of three options (keep withheld + better legend; make the four hand-offs direct tools; switch on the unwired delegate_to collapse for all delegates), the chosen fix is making the four hand-offs direct tools. It reuses the pattern research/run_code already use successfully and limits blast radius to MCP/skill routing. Switching on delegate_to is a separate token-cost change that needs a routing-quality eval first; out of scope here.

Scope

1. use_mcp_server, setup_mcp_server, setup_skills, run_skill are advertised on the orchestrator's belt (not withheld by packs). Every other packed family stays packed.
2. The raw mcp_registry_* and skill_registry_* tools are not callable by the orchestrator (owners/specialists keep them), so the hand-off is its route.
3. The ## Connected MCP Servers and ## Installed Skills sections are derived from what the orchestrator can actually call, and the routing rules name the hand-offs: find/install a skill → setup_skills; run one → run_skill; use a connected server → use_mcp_server; add one → setup_mcp_server; prefer a connected MCP server for requests it can satisfy (e.g. weather) over web tools.
4. An unknown/invented tool name inside a pack names the pack's real tools or the owning hand-off instead of a permission denial.

Acceptance

• Agent-level e2e: a scripted turn reaches each of the four specialists through its hand-off tool, revert-proven.
• Tool-schema cost delta measured and stated (prompt dump .tools.json).
• Live re-run of the five scenarios above on a real account: a skill lands on disk via Skill Setup, runs via Skill Executor, and a connected MCP server's tool is called via the MCP Agent.

[tinysweeper]

Orchestrator never delegates to MCP and skill sub-agents because their hand-off tools are withheld by tool packs

Labelled priority: p1.