Documented MCP import from Claude Desktop fails due to tool name length validation
meta: This GitHub issue was created using Claude Desktop with the same MCP_DOCKER server that fails in Claude Code, demonstrating that the MCP server works correctly in Claude Desktop.
Documented MCP import from Claude Desktop fails due to tool name length validation
Environment
- Platform: Anthropic API
- Claude CLI version: 1.0.31
- Operating System: Mac 15.3.2
- Terminal: iTerm2
Bug Description
The documented process for importing MCP servers from Claude Desktop to Claude Code fails when using the GitHub Official MCP Server. Claude Code rejects the import due to a tool name exceeding 64 characters, while Claude Desktop accepts and works with the same MCP server configuration without issues.
Documentation reference: https://docs.anthropic.com/en/docs/claude-code/mcp#import-mcp-servers-from-claude-desktop
Steps to Reproduce
- Install Docker Desktop:
brew install --cask docker - In Docker Desktop, add GitHub Official MCP Server to MCP Toolkit (requires GitHub personal access token)
- In Docker Desktop, connect Claude Desktop to MCP Toolkit
- Verify the MCP server works correctly in Claude Desktop
- Follow documented process:
claude mcp add-from-claude-desktop - Select and import the MCP_DOCKER server
- Start Claude Code:
claude - Attempt any interaction
Expected Behavior
As per the documentation, MCP servers that work in Claude Desktop should be importable and functional in Claude Code. The documented workflow should work without errors.
Actual Behavior
The documented import process succeeds, but Claude Code fails to function:
➜ mcp-servers claude mcp add-from-claude-desktop
╭─────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ Import MCP Servers from Claude Desktop │
│ │
│ Found 1 MCP server in Claude Desktop. │
│ │
│ Please select the servers you want to import: │
│ │
│ ❯ MCP_DOCKER ✔ │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────╯
Successfully imported 1 MCP server to local config.
➜ mcp-servers claude
╭───────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code! │
│ │
│ /help for help, /status for your current setup │
│ │
│ cwd: /Users/steven/mcp-servers │
╰───────────────────────────────────────────────────╯
> hello
⎿ API Error: 400
{"type":"error","error":{"type":"invalid_request_error","message":"tools.17.custom.name:
String should have at most 64 characters"}}
Root Issue
This represents a lack of parity between Claude Desktop and Claude Code:
- Claude Desktop: Accepts and works with the GitHub Official MCP Server
- Claude Code: Rejects the same MCP server due to API validation constraints
The documented workflow promises seamless migration between the two tools, but this fails in practice.
Current Workaround
claude mcp remove MCP_DOCKER
This defeats the purpose of the documented import feature and breaks the expected unified experience across Anthropic's tools.
Additional Context
- Same MCP server configuration works perfectly in Claude Desktop
- Error indicates tool
#17has a name longer than 64 characters - This affects the GitHub Official MCP Server specifically (51 tools total)
- The 64-character limitation appears to be an API constraint in Claude Code that doesn't exist in Claude Desktop
4 Comments
I found a workaround, change the MCP server name to something shorter so that the tool name stays within 64 characters, for example, use
ghinstead ofgithub:Then the longest tool would stay within 64 characters:
This should be fixed! Tool names can now be up to 128 characters.
Thanks for making this specific change so quickly it helped me out. I also agree that the bug itself still exists in the presence of a tool name long enough that it will freeze up claude code from working. Does it matter and is it realistic to fix? Probably not. 🖖
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.