[BUG] MCP tool names with hyphens fail when using native tool calling

[hori-so]

Problem (one or two sentences)

MCP tools with hyphens in their names fail to execute when using native tool calling.
This regression occurs starting from Roo Code v3.40.0 (v3.39.3 works correctly).

Context (who is affected and when)

This affects users whose MCP servers use tools with hyphenated names.
In my case, a tool originally named mcp--abcdefghij-kl-mnop-qrs-tuv--wxyz-abcd-efghijk-lmno is transformed into mcp--abcdefghij___kl___mnop___qrs___tuv--wxyz___abcd___efghijk__, resulting in Roo Code being unable to resolve the tool.
(Note: The tool name has been masked for confidentiality.)

Reproduction steps

1. Configure an MCP server that exposes a tool name containing hyphens (e.g., abcdefghij-kl-mnop-qrs-tuv--wxyz-abcd-efghijk-lmno).
2. Use Roo Code v3.40.0 or later with native tool calling.
3. Run a prompt that should invoke the MCP tool.
4. Claude outputs a malformed tool name such as:
   mcp--abcdefghij___kl___mnop___qrs___tuv--wxyz___abcd___efghijk__
5. Roo Code then reports that the tool does not exist.

Expected result

[Tool Use: mcp--abcdefghij-kl-mnop-qrs-tuv--wxyz-abcd-efghijk-lmno]

Actual result

[Tool Use: mcp--abcdefghij___kl___mnop___qrs___tuv--wxyz___abcd___efghijk__]

Variations tried (optional)

No response

App Version

v3.41.0 (regression occurs starting from v3.40.0; v3.39.3 works correctly)

API Provider (optional)

Amazon Bedrock

Model Used (optional)

anthropic.claude-sonnet-4-5-20250929-v1:0

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Date/time: 2026-01-16T01:21:05.506Z
Extension version: 3.41.0
Provider: bedrock
Model: anthropic.claude-sonnet-4-5-20250929-v1:0

ツール 'wxyz-abcd-efghijk__' はサーバー 'abcdefghij-kl-mnop-qrs-tuv' に存在しません。利用可能なツール: wxyz-abcd-efghijk-lmno

[roomote]

I've analyzed this issue and identified the root cause.

Root Cause:

In src/utils/mcp-name.ts, the buildMcpToolName function encodes hyphens in tool names as triple underscores (___) to preserve them through the model's tool calling process. However, when the resulting MCP tool name exceeds 64 characters, it's truncated using a simple slice(0, 64):

if (fullName.length > 64) {
    return fullName.slice(0, 64)
}

This truncation can cut in the middle of a ___ encoding sequence, leaving behind __ or _. When decodeMcpName tries to decode the name back, only complete ___ sequences are converted to hyphens, so the partial sequence remains corrupted.

Example:

• Original tool: wxyz-abcd-efghijk-lmno
• Encoded: wxyz___abcd___efghijk___lmno
• Full MCP name: mcp--server--wxyz___abcd___efghijk___lmno (may exceed 64 chars)
• After truncation: mcp--server--wxyz___abcd___efghijk__ (truncated mid-encoding)
• After decoding: wxyz-abcd-efghijk__ (partial __ not decoded)
• Lookup fails: Tool wxyz-abcd-efghijk__ not found

Proposed Implementation Plan:

1. Modify the truncation logic in buildMcpToolName to ensure it doesn't cut in the middle of a ___ sequence:

   • After truncating to 64 characters, check if the result ends with a partial _ or __ that could be part of a ___ encoding
   • If so, back up to the character before the incomplete encoding sequence

2. Add comprehensive tests for this edge case:

   • Test truncation with tool names containing hyphens near the 64-character boundary
   • Verify the round-trip: build -> truncate -> normalize -> parse correctly recovers the (truncated) tool name

The fix will ensure that even when truncation is necessary, the resulting name can still be properly decoded.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[mrubens]

@pdecat do you have any ideas on this one? Could it be related to #10644? Thank you!

[pdecat]

Never faced that issue yet, but like roomote I guess this is essentially caused by the fact that the tool name is already long, and the encoding makes it a bit longer, and it happens to leaves two underscores at the end.

I did not know there was a 64 characters limit for tool names, is that a hard limit?

[pdecat]

According to https://modelcontextprotocol.io/specification/2025-11-25/server/tools#tool-names :

Tool names SHOULD be between 1 and 128 characters in length (inclusive).

Also:

The following SHOULD be the only allowed characters: uppercase and lowercase ASCII letters (A-Z, a-z), digits (0-9), underscore (_), hyphen (-), and dot (.)

So having to encode hyphens should not be required in the first place, but I guess not all models respect the spec...

[pdecat]

@roomote Maybe we could hash the end of tool names instead of truncating them and thus loose information.

[roomote]

Thanks for the suggestion @pdecat! Using a hash suffix instead of simple truncation is an interesting approach that would preserve uniqueness while staying within the 64-character limit.

I'll explore implementing this - the idea would be to hash the full tool name and append a portion of that hash when truncation is needed, rather than just cutting off the end. This way we preserve the ability to uniquely identify tools even after shortening.

I'll open a PR with my attempt at this approach.

[roomote]

Opened PR #10770 with my attempt at implementing the hash suffix approach suggested by @pdecat.

The implementation:

• Computes a deterministic SHA-256 hash of the original server and tool names
• When truncation is needed, truncates to 55 chars and appends _ + 8-char hash suffix
• Registers the mapping in a registry so parsing can look up the original names
• All existing tests pass plus 15 new tests for the hash suffix behavior

Feedback welcome!