Plugin MCP tool names are config-dependent: support server name aliases or runtime discovery

Problem

MCP tool names in agent/skill frontmatter and body instructions are constructed as mcp__<server-name>__<tool-name>, where <server-name> is whatever the user named the MCP server in their local config. Plugins have no way to know this at authoring time.

In practice this means the same plugin uses different hardcoded prefixes depending on who wrote which agent:

| Prefix | Where used |
|--------|-----------|
| mcp__atlassian__ | Most agents (manually configured MCP) |
| mcp__plugin_atlassian_atlassian__ | Plugin-installed MCP |
| mcp__claude_ai_Atlassian__ | Some agents on different configs |

When the hardcoded prefix doesn't match the user's registered server name, tool calls silently fail — the agent gets no error, just no tool, and either skips the step or hallucinates.

The tools: frontmatter allowlist makes this worse: if mcp__atlassian__getJiraIssue is listed but the user's server is named plugin_atlassian_atlassian, the tool is both disallowed and non-existent — double failure.

Workaround attempted

Listing all known name variants in tools: frontmatter and telling agents to "use whichever prefix is available" — but this is unreliable because it depends on Claude correctly introspecting its available tools at runtime from a prose instruction.

Requested feature

One of:

1. Server name aliases — let users (or plugin manifests) declare a canonical alias: atlassian = plugin_atlassian_atlassian. Agents reference the alias; the runtime resolves it.
2. Abstract tool references in frontmatter — tools: atlassian:getJiraIssue without needing to know the server name.
3. Runtime tool discovery — a built-in way for agents to query "which tools matching *getJiraIssue* are available to me right now" before making calls.

Any of these would let plugin authors write agents that work across different user MCP configurations without hardcoding a server name that may differ per installation.