Tool Search Belongs in the Agent Harness, Not Every MCP Server

·https://x.com/rhyssullivan/status/2093174363847819322?s=46&t=uRyCCtjktRI5TQXbSKdTLw
articleaimcpagent-harnessestool-discoverycode-modearchitecture

joelclaw's Executor-backed MCP path should keep auth, policy, and audit in Executor while capable agent harnesses own cross-server tool discovery.

Rhys Sullivan built the thing he’s warning the ecosystem not to copy. Executor is a code-mode Model Context Protocol gateway that compresses a large tool catalog into one execute surface. Max Stoiber, who works on plugins, MCP, and skills at OpenAI, argued that search and execute belong in clients such as ChatGPT and Codex. Rhys agreed.

Executor’s pitch shows why the pattern exists. Exposing 1,640 tool schemas would consume about 278,800 prompt tokens in its example. Its single code-mode tool consumes about 1,044. The model calls tools.search(), loads one schema through tools.describe.tool(), then executes it. That’s clever compression when a client dumps every schema into context.

The shape gets fucky when the client already has dynamic tool search across its MCP servers. Now each server has built a protocol inside the protocol. The model must learn how that server searches before it can find the actual tool. Atlassian’s Rovo MCP preview shows the split: common tools are exposed directly, while a second catalog hides behind custom discover and execute calls.

Rhys’s own MCP essay says context bloat is a client implementation problem because modern clients can lazy-load tools. For joelclaw, that gives Executor a sharper boundary: normalize MCP, OpenAPI, and GraphQL; keep credentials out of model context; enforce policy; sandbox execution; and record calls. The harness should search and compose tools once. The server should expose the tools it owns.

Key Ideas

  • Tool search is strongest at the client layer because the client can rank tools across every connected server.
  • Executor’s 1,640-tool example cuts schema context from about 278,800 tokens to about 1,044 by exposing one code-mode tool.
  • MCP already separates discovery through tools/list from invocation through tools/call.
  • A server-specific discover and execute facade creates a second routing dialect that models must learn before they can use the underlying tools.
  • Atlassian Rovo MCP mixes direct primary tools with a hidden discovery catalog, which makes the duplicated discovery layer concrete.
  • Executor still earns its place through shared authentication, policy, integration normalization, sandboxing, and audit logs even if the harness owns tool selection.
  • joelclaw should treat tool discovery as a harness capability, not make Executor’s search dialect its permanent system boundary.

Links

← All discoveries