[BUG] Claude Desktop fails to register MCP tools with names >64 characters, while Claude Code (VS Code) handles them correctly

Resolved 💬 3 comments Opened Mar 16, 2026 by sujanmurahari Closed Mar 19, 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?

Actual behavior:
Claude Desktop throws tools.71.FrontendRemoteMcpToolDefinition.name: String should have at most 64 characters and the tools are unusable.

Workaround:
Use Claude Code in the VS Code extension instead of Claude Desktop to access the same MCP server and tools.

What Should Happen?

When connecting to an MCP server that exposes tools with names exceeding 64 characters, Claude Desktop throws a validation error and the tools become unusable. Claude Code in VS Code handles the same MCP server and tools without any issues.

Error message:

tools.71.FrontendRemoteMcpToolDefinition.name: String should have at most 64 characters
Environment:

Claude Desktop (macOS)
Claude Code VS Code extension (same machine, works correctly)
MCP Server: mcp-remote proxying to https://mcp.ai.synamedia.com/mcp
Server name in config: "s" (already minimized to reduce prefix length)
Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
"mcpServers": {
"s": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.ai.synamedia.com/mcp"
],
"env": {
"NODE_EXTRA_CA_CERTS": "/path/to/cert.pem"
}
}
}
}
Root cause:
Claude Code generates tool names in the format mcp__{server_name}__{tool_name}. Even with the shortest possible server name ("s"), some tool names exposed by the MCP hub (e.g. GitHub and Lightstep tools) exceed the 64-character limit imposed by the Claude API.

Claude Code (VS Code extension) appears to handle this gracefully — likely by truncating or hashing long tool names before sending them to the API. Claude Desktop does not apply the same handling, instead surfacing the raw API validation error and failing to register the affected tools entirely.

Steps to reproduce:

Configure an MCP server in Claude Desktop that exposes tools with long names (>56 characters in the tool name portion, since mcp__s__ accounts for 8 characters)
Launch Claude Desktop
Attempt to use any of those tools
Observe the validation error
Expected behavior:
Claude Desktop should handle long tool names the same way Claude Code (VS Code) does — either by truncating, hashing, or otherwise normalizing names that exceed the 64-character limit.

Actual behavior:
Claude Desktop throws tools.71.FrontendRemoteMcpToolDefinition.name: String should have at most 64 characters and the tools are unusable.

Workaround:
Use Claude Code in the VS Code extension instead of Claude Desktop to access the same MCP server and tools.

Error Messages/Logs

tools.71.FrontendRemoteMcpToolDefinition.name: String should have at most 64 characters
Environment:

Steps to Reproduce

Steps to reproduce:

Configure an MCP server in Claude Desktop that exposes tools with long names (>56 characters in the tool name portion, since mcp__s__ accounts for 8 characters)
Launch Claude Desktop
Attempt to use any of those tools
Observe the validation error
Expected behavior:
Claude Desktop should handle long tool names the same way Claude Code (VS Code) does — either by truncating, hashing, or otherwise normalizing names that exceed the 64-character limit.

Actual behavior:
Claude Desktop throws tools.71.FrontendRemoteMcpToolDefinition.name: String should have at most 64 characters and the tools are unusable.

Workaround:
Use Claude Code in the VS Code extension instead of Claude Desktop to access the same MCP server and tools.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.1.6679 (f8f4ff) 2026-03-13T18:26:03.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗