Custom MCP connectors in Cowork use UUID as server name — display name not passed to model

Problem

When custom MCP connectors are configured in Claude Code's Cowork UI with user-defined display names (e.g., "EDS QA", "EDS Dev", "EDS Local"), the model only sees the raw UUID as the server identifier in tool names:

mcp__fc0bcea5-192d-4dcb-885c-7313fec172d5__execute
mcp__96a300b4-f8ea-421e-8836-cb72a2426929__execute

The display name set in the Cowork connector configuration ("EDS QA") is not passed through to the model in any discoverable way — not in the tool name, tool description, server metadata, or via any resource/introspection API.

Impact

When a user connects multiple instances of the same custom MCP server pointing at different environments (e.g., QA, Dev, Local), the model has no way to distinguish them. All instances expose identical tool names (get_context, execute, describe, etc.) under different UUIDs. The model must:

1. Call get_context on each UUID and try to infer the environment from data differences (unreliable)
2. Ask the user which UUID maps to which environment every session

This defeats the purpose of having named connectors in the UI.

Expected Behavior

The display name configured in the Cowork UI should be discoverable by the model — either:

• Used as the server name in tool prefixes (e.g., mcp__eds-qa__execute) like was done for first-party connectors in #22276
• Exposed via a metadata field in tool descriptions
• Available through ListMcpResourcesTool or similar introspection

Context

Issue #22276 fixed this for first-party managed connectors (Slack, Linear, Notion) by using deterministic short names. But custom connectors still use raw UUIDs, so the fix didn't fully address the problem.

Environment

• Claude Code (Cowork mode)
• Multiple custom HTTP MCP connectors pointing at different environments of the same service