[Bug]: T3 MCP tools stay inactive when the Pi provider uses OmO#32322

Before submitting

• Searched existing issues and pull requests for builtin:tool-search and OmO MCP; no duplicate of this identifier mismatch was found. Related optional-discovery work: #17220.
• Included enough detail to reproduce or investigate.

Area

apps/server: Pi provider integration in packages/provider-pi.

OmO and Pi context

OmO Native (omo-ai) is a standalone coding agent built on Senpi (@code-yeongyu/senpi), a Pi fork exposing Pi's extension and RPC interfaces. It runs here through T3 Code's existing Pi provider.

OmO Native is separate from oh-my-pi (omp), another Pi fork. Runtime verification for this report covers OmO 5.1.62 with Senpi 2026.11.5-1; omp was not tested.

Steps to reproduce

1. Configure an existing OmO installation as the Pi provider executable in T3 Code and start a thread.

2. Ask the agent to inspect the Browser panel using mcp__t3-code__preview_status.

3. Search for that tool with tool_search, or call it from OmO's eval tool.

4. Inspect the registered tool_search metadata:

   ts

   1	pi.getAllTools().find((tool) => tool.name === "tool_search")?.sourceInfo.path
   2	// "<builtin:tool-search>"

The Browser, Device, and HTML preview schemas are registered, so this is not a missing MCP connection.

Expected behavior

T3 recognizes OmO's builtin tool search. Optional T3 tools remain discoverable and become callable through normal lazy activation, without a separate user activation extension.

Actual behavior

The bridge recognizes only builtin:tool-search. OmO reports <builtin:tool-search>, so the bridge treats the builtin as a replacement and changes optional tools from deferred to direct exposure.

In the reproduced OmO session those tools remain inactive and no longer appear in the deferred extension catalog:

Device and HTML tools have the same exposure problem.

Impact

Major degradation: the affected T3 tool integrations cannot be used from OmO; ordinary coding remains available.

Version or commit

Reproduced against T3 Code main at 4cb6945dc60e.

Environment

• macOS, Darwin 27, Apple Silicon.
• OmO/Senpi runtime 2026.11.5-1.
• Bun 1.4.2.
• Also reproduced in a fresh real OmO SDK session without a model request.

Investigation and verification

Accepting both exact builtin source identifiers restores the existing discovery path.

• Existing bridge suite: 27 tests passed before coverage was extended.
• Added the OmO source-path row to existing discovery coverage and exercised it in the existing permission case: two cases failed before the fix.
• Corrected bridge: 28 focused tests passed.
• vp run check:changed: format, lint, both knip checks, typechecks for nine affected packages, and 30 tests passed.
• Real OmO: tool search found the T3 tools; Browser navigation/screenshot/close and HTML preview/render succeeded.
• Device invocation reached T3's existing disabled-access guard. Device UI was not tested, and access was not enabled.

Workaround

No user-installed activation extension should be necessary. The compatibility fix belongs in T3's Pi MCP bridge.

Proposed fix

PR #32321 restores discovery by recognizing both exact builtin tool-search identifiers.