[BUG] Re-opening #51138 / #57033 class of bug: claude.ai-hosted MCP tools still not indexed by ToolSearch, closed "not planned" but actively recurring

Status Closed — not planned
Maintainer reply None cached
Activity 1 comment · opened Sep 24, 2026 · closed Sep 27, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The bug tracked in #51138 (closed as not planned, stale) and duplicated from #57033 ("ToolSearch does not index tools from claude.ai-hosted MCP servers") is still live and actively affecting production use, months after that tracking issue was closed without a fix. This report provides a fresh, concrete reproduction with real business impact, and cross-references newer reports of the same underlying class (#93697, #86909) that show this was never actually resolved — only the original tracking thread went stale.

What Should Happen?

  • Surface: Claude Desktop (chat, not Claude Code CLI)
  • Connector: Adobe Workfront MCP (claude.ai-hosted, OAuth-connected, shows ✓ Connected in Settings → Connectors)
  • Account type: Enterprise/Team org

Error Messages/Logs

- Surface: Claude Desktop (chat, not Claude Code CLI)
- Connector: Adobe Workfront MCP (claude.ai-hosted, OAuth-connected, shows ✓ Connected in Settings → Connectors)
- Account type: Enterprise/Team org

Steps to Reproduce

  1. Connect the Adobe Workfront MCP connector via Settings → Connectors. Confirm it shows Connected.
  2. In a chat session, successfully call multiple tools from this same connector (confirmed working: insights_get_current_user, insights_find_workfront_data, planning_get_workspace, comment-stream_get_comments_count, and ~35 others across the connector's documented tool set).
  3. Attempt to discover two specific, documented tools from the same connector: workflow_search_any_object and workflow_resolve_field_names_any_object (both listed on Adobe's own current MCP tools reference: https://experienceleague.adobe.com/en/docs/workfront/using/basics/workfront-mcp-server/workfront-mcp-server-tools).
  4. Tool-search queries under multiple phrasings (exact tool name, category description, both names together) return zero matches for these two tools specifically, across 4+ separate attempts in the same session.
  5. A direct call to the tool by its exact expected name (bypassing discovery) returns "Tool not found" — confirming this is not merely a search-ranking issue but a full absence from the callable tool set for this session.
  6. The connector's own raw registry entry (via search_mcp_registry) confirms a much larger tool set is registered for this connector than what tool_search or direct invocation can reach — consistent with the "tools fetched but never registered with the deferred-tool index" root cause described in #57033.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This blocked a specific, legitimate admin/config-auditing task (retrieving Layout Template configuration data) for an entire extended work session. The only suggested remediations available to the end user — restarting the chat session, disconnecting/reconnecting the connector — are workarounds for a platform-side indexing defect, not something the end user should need to manage repeatedly in normal use. Given #51138 was closed as "not planned" rather than fixed, and this exact failure mode is still reproducible today, closing that issue does not appear to have reflected an actual resolution.

Ask

  • Re-triage this as a live, unresolved defect rather than relying on the stale/closed status of #51138.
  • If there is a genuine reason workflow_search_any_object / workflow_resolve_field_names_any_object specifically are excluded from indexing (e.g., a staged rollout), surface that to the user/model explicitly rather than returning an indistinguishable "not found."

Related issues: #51138 (closed, not planned), #57033 (duplicate, consolidated into #51138), #93697 (recurring, 2 weeks old), #86909 (recurring, related self-report/naming confusion)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗