feat: support separate model-visible aliases and MCP wire tool names

[suxiaoshao]

• I have looked for existing issues (including closed) about this

Feature Request

Allow an RMCP tool's model-visible name to differ from the server-advertised MCP tool name used for tools/call.

Rig's RMCP adapter currently uses rmcp::model::Tool::name both as the registered/model-visible tool name and as CallToolRequestParams::name. This works while both identities are identical, but it prevents clients from safely applying provider-compatible aliases or resolving collisions across MCP servers.

Motivation

MCP tool names are protocol identities owned by the server and must be preserved when calling the server. The name exposed to a language model may need to differ:

• A provider may impose a stricter tool-name character set or length limit than MCP.
• Two MCP servers may advertise the same tool name, such as fetch.
• Sanitization can make distinct MCP names collide.
• A client may namespace tools so the model can route calls unambiguously.

Changing Tool::name to the model-visible alias makes the model declaration valid, but Rig then sends that alias in CallToolRequestParams::name. The MCP server receives an unknown tool name.

This affects Rig 0.41.0 and the current main implementation in crates/rig-agent/src/tool/rmcp.rs: McpTool::name() and McpTool::execute_mcp() both derive their name from the same definition.name.

Proposal

Add a public RMCP registration path that accepts a model-visible name separately from the raw MCP definition, while preserving the existing methods as shorthand where both names are identical.

For example, the API could accept a registration value with:

pub struct RmcpToolRegistration {
    pub model_name: String,
    pub definition: rmcp::model::Tool,
    pub client: rmcp::service::ServerSink,
    pub timeout: Option<Duration>,
}

The exact public shape can follow Rig's current tool architecture, but it should preserve these invariants:

• Provider tool definitions and toolset lookup use model_name.
• MCP tools/call always uses the original definition.name.
• The existing timeout, cancellation, _meta, structured-content, raw-result, and error behavior remains available.
• Existing rmcp_tool(s) and rmcp_tool(s)_with_timeout behavior remains unchanged when no alias is supplied.
• Tests cover a sanitized alias and two servers exposing the same raw tool name.

Alternatives

• Mutating rmcp::model::Tool::name before registration makes the provider-facing name valid but corrupts the MCP wire identity.
• Wrapping every MCP tool in a generic dynamic tool can separate the names, but each Rig consumer must duplicate the RMCP adapter's timeout, cancellation, metadata, structured-result, and error handling.
• Requiring MCP servers to rename tools does not solve collisions across independently owned servers and makes provider-specific restrictions a server concern.

[linear-code]

RIG-1437