🎃 Add "Open in MCP Inspector" to the MCP server page

Start in packages/frontend/src/app/mcp-server/[id]/page.tsx, reading the aiClients, renderModalContent, endpointUrl, and handleCopy references in the issue; check the Inspector README and v1-to-v2 migration guide for the flags. Add the auth-mode-specific command and link, then test both modes with the specified Playwright e2e spec and npm run test:e2e. Done includes the integration doc linked from the README and recording the tested Inspector version in the PR.

Part of the October Challenge #846.

Why

MCP Inspector is the standard tool for checking an MCP server by hand: list its tools, call one, look at the raw JSON. Users who want to know whether a problem is AnythingMCP or their AI client currently have to work out the Inspector flags themselves, and one detail trips them up. Inspector v2 only infers the transport from URLs that end in /mcp or /sse. Our per-server URL /mcp/<serverId> matches neither, so npx @modelcontextprotocol/inspector --server-url … stops with "Transport type not specified". A ready-made command on the server page removes that.

Self-hosted vs Cloud

• Self-hosted: enabled in Community and Business. On LAN installs over plain HTTP the command still works; the Inspector runs on the user's machine.
• Cloud (DEPLOYMENT_MODE=cloud): enabled. The Inspector runs locally and calls https://cloud.anythingmcp.com/mcp/<id>. The server makes no outbound request, so there is no SSRF risk and nothing cross-tenant. Cloud runs MCP_AUTH_MODE=oauth2 (docker-compose.cloud.yml:111), so OAuth is the default there.
• Who can use it: anyone who can open the MCP server page (the server must belong to the caller's org; mcp-servers.controller.ts:100-104). The button builds client-side text and needs no new endpoint.

What to build

1. Add an "MCP Inspector" tile to aiClients (mcp-server/[id]/page.tsx:366-376) with a matching case 'inspector' in renderModalContent (:438). Group it visually as a debugging tool, separate from the AI clients.
2. The modal shows a copyable command (primary) using the existing handleCopy (:210, which records client_config_copied with client: 'inspector'):
   • OAuth (oauth2/both): npx -y @modelcontextprotocol/inspector@2 --transport http --server-url <endpointUrl>. The Inspector does discovery + dynamic client registration in the browser. Its loopback redirect (http://127.0.0.1:…/oauth/callback) is allowed by redirect-uri.util.ts (http to loopback is accepted).
   • API key (legacy/both): the same command plus --header "X-API-Key: $AMCP_MCP_API_KEY". Use a placeholder env var, never a real key, and keep it out of shell history. Link to the API Keys section on the same page. Explain that per-user mcp_… keys work on /mcp/<id> in every auth mode (mcp-combined-auth.guard.ts:64).
   • Read the mode with server.info() (lib/api.ts:964), as settings/page.tsx:47-49 does. If it is both, show both variants.
3. Secondary: "Already running the Inspector? Open it with this server". This is a link to http://localhost:6274/?serverUrl=<encodeURIComponent(endpointUrl)>&transport=http. Inspector v2 accepts these params but only auto-connects with its per-launch token, so the link prefills and does not connect. Say that in the UI. Do not try to pass autoConnect.
4. Pin the major version (@2): v1 used different deep-link params (transport=streamable-http). Add a one-line warning that the Inspector stores OAuth tokens in the OS keychain or ~/.mcp-inspector/secrets.json.
5. Check every flag against the Inspector README and docs/v1-to-v2-migration.md at the version you test, and record that version in the PR.

Where to look

• packages/frontend/src/app/mcp-server/[id]/page.tsx:98-102 (apiUrl), :270 (endpointUrl), :366-376 (aiClients), :438-590 (renderModalContent, including claude-code at :532 as the copy-command pattern and linkAction at :428).
• packages/backend/src/auth/redirect-uri.util.ts:23-60: loopback redirect rules.
• packages/backend/src/auth/mcp-combined-auth.guard.ts:57-100: which headers /mcp/<id> accepts.
• packages/backend/src/health/health.controller.ts:57-70: mcpAuthMode, oauthEndpoints.

Acceptance criteria

• The command connects and lists tools against a local instance in both MCP_AUTH_MODE=legacy (with a real key exported) and oauth2 (describe the manual steps in the PR).
• The command always includes --transport http, and the URL is the per-server endpoint.
• No API key, session token or JWT is ever written into the command or the link.
• Playwright spec under packages/frontend/tests/e2e/ (stub /api/mcp-servers/<id> and /health/server-info like mcp-server-assignments.spec.ts) opens the tile and checks the command text for each auth mode. Run with cd packages/frontend && npm run test:e2e.
• New docs/integrations/mcp-inspector.md (short: command, OAuth vs key, the transport gotcha), linked from the README "Use it from Claude, ChatGPT…" section.

Out of scope

• Embedding or hosting the Inspector inside AnythingMCP.
• Inspector support for the shared /mcp endpoint (it exposes only the anythingmcp_* meta-tools on Cloud).
• Generating API keys from the modal.

Size

S (a few hours)

How to claim

Comment "I'd like to work on this" and we'll assign you. Rules in #846.