Agent capability reach map with search/call discovery

[JustYannicc]

Agents keep missing app capabilities one at a time. The proposal in #8433 describes the goal as "anything a human can control in T3, an AI agent can control too". A reach map could catch omissions when an RPC is added.

Recent requests cover archiving a thread, provider usage, pinned state, auto-settle opt-out, notifications, compaction, and process control. Each can be solved separately, but a new app operation can still ship without an agent-access decision.

Would you consider a small reach map first, followed by a derived read runner if the direction fits?

The map mirrors RPC_REQUIRED_SCOPES: every WsRpcGroup method and client-dispatchable command must declare whether agents can reach it, it is exempt with a reason, or it is an open gap. Adding an RPC without a decision fails typecheck. Existing dedicated tools can stay first-class.

For generic access, app_search matches capability descriptions and returns methods with their input, result and error schemas. For example, searching provider cost finds the usage summary. app_call validates the input and uses the generated RPC client against the existing handler and authorization layer. It encodes results and domain errors with the RPC's schemas. The authenticated connection supplies the grant; the agent cannot supply scopes in tool arguments. Reads check that the calling agent is still active. Mutations stay unavailable until their MCP mode checks are wired. This avoids adding a separate tool for every RPC, especially given the schema-bloat report in #19190.

Working demo

Branch: https://github.com/JustYannicc/t3code/tree/proposal/337-generic-agent-parity-20261018

Candidate: aaa40357f27b86811e30500a7cc8eb2617a30167, based on upstream 9c161462c94f7d9d6d9169da5c841457cbadf213.

The backend demo includes a complete RPC/command decision map and a two-tool MCP toolkit. Its test calls app_search and app_call through the checked MCP handler layer into a generated in-memory RPC client and the production authorization middleware. It also checks invalid payloads/results, payload-dependent filesystem scope denial, and expired callers. A test deliberately overstates the preflight grant and verifies that the connection's actual authorization still refuses the call.

Run from the branch:

vp i --frozen-lockfile
vp test run apps/server/src/mcp/AgentParityDemo.test.ts --maxWorkers=2

Validation: 15 demo tests passed on this candidate, including the checked MCP-to-RPC path. The existing RPC authorization suite passed 24 tests. Server typecheck, focused lint and formatting, and git diff --check passed.

This is a read-only prototype, with explicit gaps for mutations and streaming subscriptions. It is not registered in the shipped MCP server. Human approval/secret answers and final OAuth steps are exempt. Destructive actions remain unavailable until a human decision gate exists. The demo does not claim complete agent parity or solve provider tool discovery.

If this shape is useful, I would split the work into the reach map and coverage test, the derived runner and search/call exposure, then individual gap fixes. I am asking about that direction before opening a feature PR.

Prepared with GPT-6.1 Sol in the Codex harness.

[capitaharlock]

The small reach map first, with a read runner derived from it later, sounds like the right split. Could that initial map record read-runner eligibility separately from agent reachability, so “agents can reach this” doesn't also mean “the generic read runner may call this”?

That would give the follow-up runner an explicit default-deny selection rule: only entries marked eligible are callable through it, and missing eligibility admits nothing. I'm asking about one metadata decision in the first PR, not bringing the runner implementation into scope.

[JustYannicc]

Agreed. The demo at aaa40357 currently uses kind: "derived" both to describe reachability and to select generic calls. Those should be separate decisions.

For the proposed map-only first change, I would record explicit read-runner eligibility alongside agent reachability. The follow-up runner would admit only an explicit eligible value; missing eligibility would deny the call. Dedicated tools could remain agent-reachable without becoming generically callable. Eligibility would not replace RPC authorization or MCP mode limits.

The first change would contain the map and coverage tests, with a check that reachability alone grants no runner eligibility. The runner implementation would remain a separate follow-up. This is still a proposal awaiting maintainer direction and scope approval.