>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3611991. --> Reported by: [stmh](https://www.drupal.org/user/35538) Related to !5 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>MCP tools exposed by <code>mcp_server_tool_bridge</code> are advertised with a<br> wire name of <code>tool_api.&amp;lt;config_id&amp;gt;</code> (e.g.<br> <code>tool_api.my_module_get_thing</code>). The <code>.</code> separator comes from<br> <code>mcp_server</code>'s <code>DotDerivativeDiscoveryDecorator</code>, and it is<br> valid per the MCP SDK's own <code>NameValidator</code><br> (<code>^[a-zA-Z0-9._\/-]{1,64}$</code>), so the server registers and serves the<br> tools without complaint.</p> <p>However, some MCP clients apply a stricter tool-name rule. Anthropic's Claude<br> web and desktop connectors validate every tool name against<br> <code>^[a-zA-Z0-9_-]{1,64}$</code> (their <code>FrontendRemoteMcpToolDefinition</code><br> schema), which does <strong>not</strong> permit <code>.</code>. As a result, every<br> bridged tool is rejected and the connector surfaces an error such as:</p> <blockquote><p><code>tools.31.FrontendRemoteMcpToolDefinition.name: String should match pattern '^[a-zA-Z0-9_-]{1,64}$'</code></p></blockquote> <p>The Claude Code CLI tolerates the names only because it silently rewrites<br> <code>.</code> to <code>_</code>; the web and desktop clients do not, so the tools<br> are unusable there.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Install and enable <code>mcp_server</code>, <code>mcp_server_tool_bridge</code><br> (and OAuth as needed).</li> <li>Create at least one enabled <code>McpToolConfig</code> entity so a<br> <code>tool_api.&amp;lt;id&amp;gt;</code> tool is derived.</li> <li>Add the site's <code>/mcp</code> endpoint as a custom connector in the Claude<br> web app or desktop app and enable it.</li> <li>Observe the validation error referencing the pattern<br> <code>^[a-zA-Z0-9_-]{1,64}$</code>; the affected tool(s) cannot be enabled.</li> </ol> <p>Length is not the trigger &mdash; the dotted names are well under 64 characters. The<br> only offending character is the <code>.</code> separator.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Use <code>_</code> instead of <code>.</code> for the emitted <strong>wire<br> name</strong> only. In<br> <code>McpToolConfigDeriver::createDerivativeDefinition()</code>, build the<br> definition id as<br> <code>$base_plugin_definition-&amp;gt;id() . '_' . $derivative_id</code>.</p> <p>This is safe because the dotted string is only required as the plugin<br> <em>lookup key</em>, which is produced and decoded independently by<br> <code>DotDerivativeDiscoveryDecorator</code>. Plugin resolution (and therefore<br> <code>tools/call</code> dispatch, which binds the handler instance to the tool at<br> registration time) is unaffected &mdash; only the public <code>id()</code> that<br> <code>McpServerFactory</code> emits as the MCP wire name changes. The resulting<br> names (<code>tool_api_&amp;lt;id&amp;gt;</code>) satisfy both the MCP SDK validator and the<br> stricter Claude client pattern.</p> <p>The list builder's displayed <code>wire_name</code> column<br> (<code>McpToolConfigListBuilder::buildRow()</code>) is updated to match, so the UI<br> shows the actual served name.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Review the wire-name change and confirm no other consumer relies on the<br> dotted <code>id()</code> value (as opposed to the dotted lookup key).</li> <li>Add/adjust test coverage asserting the emitted wire name uses<br> <code>_</code> while the plugin lookup key remains dotted.</li> <li>Consider whether <code>mcp_server</code> core should offer a shared<br> client-safe naming helper so other bridges avoid the same trap.</li> <li>Decide on an upgrade path for existing integrations that referenced the old<br> dotted names (the name change is effectively an API change for clients).</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>The "Wire name" column on the MCP Tool Config list now shows<br> <code>tool_api_&amp;lt;id&amp;gt;</code> instead of <code>tool_api.&amp;lt;id&amp;gt;</code>,<br> matching what is actually served.</p> <h3 id="summary-api-changes">API changes</h3> <p>The MCP wire name of every bridged tool changes from<br> <code>tool_api.&amp;lt;id&amp;gt;</code> to <code>tool_api_&amp;lt;id&amp;gt;</code>. Clients that<br> hard-coded the dotted name will need to update. Internal Drupal plugin IDs (the<br> lookup keys) are unchanged.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None. No schema, entity, or configuration changes; <code>McpToolConfig</code><br> entities are untouched.</p> <hr> <p><em>This issue was investigated and drafted with the help of AI (Anthropic<br> Claude, via Claude Code), including the root-cause analysis and the proposed<br> patch.</em></p>