MCP connector: a single invalid tool name in tools/list rejects the entire connector with an opaque "conversation could not be found" error
(filing here as the public Anthropic tracker — this is about the claude.ai web app's MCP connector validation, not Claude Code CLI. Please route as needed.)
Summary
When a custom MCP connector returns a tools/list containing one tool whose name does not match ^[a-zA-Z0-9_-]{1,64}$, claude.ai rejects the entire tools array and the conversation cannot be created. The user-visible failure is two toasts:
tools.N.FrontendRemoteMcpToolDefinition.name: String should match pattern '^[a-zA-Z0-9_-]{1,64}$'This conversation could not be found
No tool list is shown, no chat works, and there is no indication in the UI that the connector itself is the cause — users see "conversation not found" and assume claude.ai is broken.
Reproduction
- Connect a custom MCP server to claude.ai (Settings → Connectors → Add custom).
- Have the server return a tools list with at least one entry whose name contains a
{,},.,:,/, or exceeds 64 chars (easy to trigger if your server aggregates other backends and one of them exposes a FastAPI catch-all route like/tools/{tool_name}whose path-template literal leaks into the tool name). - Open a new chat with that connector enabled.
- Conversation creation fails. All other tools — including unrelated connectors — are unusable in that chat.
Expected behavior
One of:
- Drop invalid tools individually with a logged client warning, keep the rest of the connector working.
- Reject only the offending connector, with an explicit toast naming the connector and tool, not "conversation could not be found".
- Validate at connector-registration time so the bad state can never reach a chat session.
Actual behavior
Array-level fail-closed at conversation create time, with a generic "not found" message that gives no actionable info. The user has to inspect network requests in devtools to see the real validation error.
Why it matters
A single misbehaving backend (often unrelated, e.g. a FastAPI server registered through an aggregator) takes down the entire claude.ai chat experience for that connector. Defensive code on the user side fixes one instance but the failure mode is brittle by design — discovery of the bad name only happens at the worst possible time.
Concrete instance
Connector aggregating multiple MCP backends. One legacy backend exposed a generic /tools/{tool_name} FastAPI catch-all whose path-template leaked through the aggregator as a tool literally named browser_{tool_name}. Workaround: defensive regex check on the aggregator side, dropping tools whose names don't match ^[a-zA-Z0-9_-]{1,64}$ before they reach claude.ai.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗