MCP tool names collide when multiple servers report the same serverInfo.name, producing unstable _2/_3 prefixes

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.127.0
- OS Version: Windows 11

Steps to Reproduce:

1. In `mcp.json`, configure two or more stdio MCP servers under **distinct keys** (e.g. `svc-a`, `svc-b`) that each launch a backend which reports an **identical** `serverInfo.name` in its `initialize` response. Real-world example: the [Azure DevOps MCP server](https://github.com/microsoft/azure-devops-mcp), run as one instance per organization — every instance reports `serverInfo.name = "AzureDevOps.Mcp"` regardless of which organization it targets.
2. Reload the window and let VS Code discover tools.
3. Observe the exposed tool names: `mcp_azuredevops_2_*`, `mcp_azuredevops_3_*`, … `mcp_azuredevops_m_*` — **not** `mcp_svc_a_*` / `mcp_svc_b_*`.
4. Reload again and note the `_N` suffix→server assignment can change; there is no config-readable way to know which suffix corresponds to which `mcp.json` entry.

---

### Summary

When several configured MCP servers (each under a **distinct key** in `mcp.json`) report the **same** `serverInfo.name`, VS Code disambiguates their tools with numeric/letter suffixes (`mcp__2_*`, `_3_*`, … `_m_*`). That suffix→server mapping is **not stable across reloads** and is **not derived from the unique `mcp.json` server key**, so an agent/client cannot reliably route a tool call to a specific server by tool name.

### Expected

Each server's tools get a **stable, self-describing** prefix derived from its unique `mcp.json` server key (which is guaranteed unique), giving every configured server its own predictable tool namespace regardless of what `serverInfo.name` the backend reports.

### Actual

The tool prefix is derived from the backend-reported `serverInfo.name`. When several servers report the same name, they collide and VS Code appends disambiguation suffixes (`_2`, `_3`, … `_m`) that are unstable across reloads. A client must **probe** each server (call a tool and inspect the response) to discover which suffix maps to which server — and a wrong guess can send a call (including a write) to the wrong backend instance.

### Impact

Any setup that runs multiple instances of the same MCP server — e.g. one per account/organization/tenant — cannot be addressed deterministically by tool name. This is common for multi-tenant backends. Agents that need to target a specific instance must add a probing step, and mis-routing risks silent no-ops against the wrong instance.

### Proposed fix

Derive the tool namespace/prefix from the unique `mcp.json` server **key** rather than the backend-reported `serverInfo.name` (or otherwise guarantee a stable, key-based per-server prefix even when `serverInfo.name` values collide).