MCP connector tools are exposed under an opaque, unstable UUID instead of the connector name

## Summary

Tools from an MCP connector reach the model under an **opaque UUID prefix**:

```
mcp__a0468d2d-xxxx-xxxx-xxxx-xxxxxxxxxxxx__getJiraIssue
mcp__a0468d2d-xxxx-xxxx-xxxx-xxxxxxxxxxxx__getConfluencePage
```

In the UI the same server is listed by its display name (in my case "Atlassian Rovo"). The user and the model are looking at the same connector with **no shared identifier**: the user cannot say "use Rovo" in a way the model can act on, and the model cannot report which server it is using in terms the user recognises.

## Why this is more than cosmetic

1. **Nothing the model writes down stays valid.** A persistent note saying "use `mcp__a0468d2d-…`" becomes wrong as soon as the id changes, and the model starts guessing again in the next session. I corrected the same note several times and the problem returned identically, because the only identifier available to me was the unstable one.

2. **Where several connectors cover the same product, the name misleads.** I have two Atlassian servers: one literally named `atlassian` that covers only site B, and the one that covers site A (the one I actually need) exposed under a UUID. The model naturally tries the server *named* after the product first — and that is the wrong one.

3. **The resulting error points away from the fix.** Using the wrong server returns:

> `Cloud id: isn't explicitly granted by the user`

That reads as a permission the user must grant, and sends the model to ask the user for something that will not help. The real cause is "wrong server, use another one", which the message does not suggest.

## Suggested fixes, in order of effectiveness

- **Put the connector's display name in the tool prefix** (e.g. `mcp__atlassian_rovo__getJiraIssue`), or at minimum include it in each tool's description, so the model can name the server the user sees.
- **Make the identifier stable** across sessions and updates, so a persistent note keeps working.
- **Improve the cloudId error**: when the requested `cloudId` does not belong to this server but another configured server covers it, say so — "this server covers site B; for site A use connector **".

## Steps to reproduce

1. Configure two Atlassian connectors for different sites, one of them named `atlassian`.
2. In a fresh session, ask to read an issue from the site covered by the **other** connector.
3. The model tries the similarly named server, gets the cloudId error, and has to discover by trial and error which UUID corresponds to the right connector. Reproducible in every new session.

## Environment

Claude Code desktop app, Windows.

Start by tracing how MCP connector tools are registered and how their prefixes are generated, then inspect the cloudId error path for connector selection. Compare the exposed identifier with the connector display name across fresh sessions and multiple configured servers; done means the model can reliably identify the user-visible connector and distinguish a wrong-server cloudId error.

Written by the indexing model from the issue text.