fix: truncate MCP tool names exceeding 64 characters

[Br1an67]

Issue for this PR

Closes #3523

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

MCP tool names are generated by concatenating the MCP server name and tool name ({server}_{tool}). When this combined name exceeds 64 characters, the OpenAI API rejects it and OpenCode silently stops processing requests.

The fix truncates the combined tool name to 64 characters and logs a warning when truncation occurs. This matches what mcphub.nvim does (referenced in the issue).

Changed packages/opencode/src/mcp/index.ts — the tool registration loop now checks length and truncates with a log warning.

How did you verify your code works?

Verified the logic by reviewing the code path. The change is a simple conditional truncation on the name string before using it as the tool registry key.

Screenshots / recordings

N/A — no UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[georgeglarson]

Hi @Br1an67 — I filed #24871 yesterday for #3523 and missed that this PR was already open with green checks. Apologies for the duplication; you got there first.

Your fix is the right shape. One small follow-up note (not a blocker for this PR) for whenever a maintainer reviews:

name.slice(0, 64) will collide if two <server>_<tool> strings share the first 64 chars after concat. Two distinct tools end up writing to the same result[name] key, and the second silently overwrites the first. Edge case — it requires the same MCP server with two long tool names sharing a 55+ char prefix (since _ adds one and the server name eats the rest). But because the value is silently dropped instead of erroring, it's the same shape as the original bug (silent failure, no signal to the user).

A content-derived suffix preserves uniqueness:

if (name.length > 64) {
  const hash = Hash.fast(name).slice(0, 8)
  name = name.slice(0, 64 - hash.length - 1) + "_" + hash
}

Posted this here rather than as a competing PR. If the maintainer prefers the truncate-only path you have, that's a fine call — collisions are rare and the warning log surfaces them. Closing #24871. Happy to PR the suffix as a follow-up after this lands if it's wanted.

[rekram1-node]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.