[shashank-tomar-glean]

Summary

On Glean deployments that serve Glean search as enterprise_search, the plugin has no search tool. The remote tool filter matches exact names and its allowlist only has search, so enterprise_search is silently dropped. Without it, document questions detour through find_skills_and_tools and run_tool, or through chat.

This change lists enterprise_search under the name search. Calls need no change: the Glean server dispatches a search call to enterprise_search on deployments that serve that name. Keeping the name search means the bundled skills and references, which all call search, stay accurate on every deployment, whichever name it serves.

Changes

• shared/glean/mcp/src/tools/remote-passthrough.ts: when filtering the remote tool list, map enterprise_search to search, and list search only once if a server ever serves both names.
• shared/glean/mcp/tests/remote-passthrough.test.ts: cover the rename and the both-names case.

The alternative is to add enterprise_search to REMOTE_TOOLS_ALLOWLIST. That works without a mapping, but the tool's name would then vary by deployment, and the skills that say search would name a tool that isn't listed.

Testing

• npm run typecheck:bundle, npm run test:bundle (434 tests), and npm test (build plus validate for claude, cursor, and codex) all pass.
• End to end with Codex CLI 0.160.1 and a local build of this branch, against a Glean deployment that serves enterprise_search:
  • Without this change, the plugin lists chat, employee_search, memory, memory_schema, read_document, and user_activity, plus its own setup, find_skills_and_tools, and run_tool. With it, the list also has search.
  • A search call through the plugin returns results. The server routes it to enterprise_search.
  • Asked to find an internal design doc, Codex without this change made nine tool calls: find_skills_and_tools twice, two run_tool searches whose top results were product documentation, then chat and read_document. With it, Codex made three direct search calls and found the doc.
  • Combined with #31, calendar prompts still go to meeting_lookup rather than search.

[steve-calvert-glean]

Thanks for tracking this down, @shashank-tomar-glean. The local server needs to match whatever the remote serves. Deployments serve this tool as either search or enterprise_search, depending on rollout, and we have to support both.

Right now the tool is renamed to search in tools/list, and the call still goes out as search. That works today because the server also accepts the other name, but that's a compatibility fallback, and the plugin shouldn't depend on it.

Instead, can we use whichever name the remote uses, on every surface?

• Remote serves search: list search, dispatch search.
• Remote serves enterprise_search: list enterprise_search, dispatch enterprise_search.

dispatchRemoteTool already forwards the called name unchanged, so I think this comes down to adding enterprise_search to REMOTE_TOOLS_ALLOWLIST and removing the mapping. This also matches what hosts connected directly to the remote already see, so a deployment shows the same name either way.

On the skills: the ones that say search already name a missing tool on enterprise_search deployments, so this change doesn't make that worse. I'll follow up with a pluginpack partial that describes the tool as search or enterprise_search, so the alias wording lives in one place and is easy to update when the rollout finishes.

Tests I'd like to see:

• A remote serving search lists and dispatches search.
• A remote serving enterprise_search lists and dispatches enterprise_search.

[steve-calvert-glean]

Follow-up for the skills side is up in #33. It adds a pluginpack partial that says search and enterprise_search are the same tool, and includes it in each skill and rule that names the tool. That covers both names in the skills, so this PR only needs the pass-through change.