Connect other MCP hosts

A ggui server is a plain remote MCP server. Any host that can be pointed at an MCP HTTP URL can use it — Claude Desktop is just the most polished today. This page is the “everything else” companion to Connect Claude Desktop, which stays the deep-dive for that one client.

Hosted endpoint — coming soon

The examples below show the hosted mcp.ggui.ai URL for brevity. That managed endpoint is part of the GGUI Preview cloud — coming soon, not live yet. Today, run your own server with ggui serve --oauth --public-base-url https://<your-tunnel> and substitute https://<your-tunnel>/mcp wherever you see mcp.ggui.ai below — every host flow is identical, only the URL changes. See Connect Claude Desktop → connect your own server for the self-hosted walkthrough.

Each section below covers WHAT to paste, WHERE to paste it, the expected OAuth flow, and any inline-rendering caveat. If your host isn’t listed but speaks MCP over HTTP, jump to Other / static-key fallback.

claude.ai (web)

Anthropic’s web client gained MCP Apps support late 2025; the flow mirrors Claude Desktop exactly.

1. Settings → Connectors → Add custom connector.
2. Paste https://mcp.ggui.ai. Leave auth blank.
3. On first tool call, claude.ai opens an OAuth tab to console.ggui.ai/oauth/consent. Approve.

Inline rendering works — generated UIs appear directly in the chat.

Tip

The OAuth ceremony is identical to Claude Desktop. See OAuth on mcp.ggui.ai for the RFC-by-RFC breakdown.

Cursor

Cursor reads MCP server config from ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project, takes precedence).

{
  "mcpServers": {
    "ggui": {
      "url": "https://mcp.ggui.ai"
    }
  }
}

Restart Cursor. The first time the agent calls a ggui tool, Cursor opens the browser OAuth flow. Approve at console.ggui.ai/oauth/consent and the agent picks up the minted token automatically.

Caution

Cursor’s MCP Apps inline-rendering support is partial and moves quickly — verify against your installed build. If your build doesn’t render inline, the tool call still succeeds and returns a ui://ggui/render/<sessionId> resource, but there is no URL to open manually — the session round-trip works, the UI just can’t be mounted.

VS Code Copilot (and Cline, Continue, Codeium)

VS Code’s native MCP support shipped in 2025. Drop into either .vscode/mcp.json (per-project) or your User Settings JSON:

{
  "servers": {
    "ggui": { "type": "http", "url": "https://mcp.ggui.ai" }
  }
}

Reload the window. Copilot triggers OAuth on first tool call.

Cline, Continue, and Codeium are VS Code extensions that ship their own MCP config surfaces. The JSON shape is the same mcpServers-style object with minor key naming differences per extension — drop the same URL into whichever mcp.json the extension reads:

• Cline — extension settings → MCP Servers → Edit config.
• Continue — ~/.continue/config.json under mcpServers.
• Codeium — extension settings → MCP integration.

Consult each extension’s docs for the exact path; the URL itself is unchanged.

Note

Inline-rendering support across these extensions varies. The transport works everywhere; only the MCP Apps capability negotiation determines whether you get an embedded UI or a link to open.

Goose

Block’s open-source agent has full MCP Apps support, so inline rendering works in the Goose Desktop UI out of the box.

goose configure

Choose Add extension → Remote MCP Server, give it a name (ggui), and paste:

https://mcp.ggui.ai

Goose drives the OAuth ceremony in the terminal flow — it prints a URL, you sign in at console.ggui.ai, and Goose stores the resulting token.

Windsurf

Codeium’s IDE supports remote MCP servers via Settings → MCP Servers → Add. Paste https://mcp.ggui.ai and save; OAuth runs on first tool call.

The config-file location varies by OS and Windsurf build. Settings UI is the safest path.

Caution

Verify against your current Windsurf build — MCP Apps capability advertisement and inline-rendering behavior have changed across releases.

Other / static-key fallback

Any host that can be pointed at an MCP HTTP URL with a bearer token can hit mcp.ggui.ai. For hosts that don’t yet implement OAuth 2.1 + DCR — most CLI agents and home-grown clients — use a static API key instead:

1. Sign in at console.ggui.ai/keys/connector.

2. Click Mint. Label it after the client.

3. Configure the host to send the key as a bearer header:

   Authorization: Bearer ggui_user_xxxxxxxxxxxx

That’s the full setup. See ggui keys create for minting a connector key from the terminal instead of the console.

Note

Inline rendering depends on MCP Apps capability negotiation in the host. Hosts without that capability still get a working ggui_render — it returns the render as an MCP-Apps resource (resourceUri); the host just can’t mount it inline. The session round-trip itself is unaffected.

Things every host needs

Everything on this page also works against a self-hosted ggui serve — substitute your server URL; add --oauth for hosts that drive the browser ceremony, or use a pair-minted bearer for the static-key path.

For a working connection:

• MCP over HTTP — mcp.ggui.ai is HTTP-only. Stdio-only hosts can’t connect directly.
• Bearer authentication — either via the OAuth flow below, or a static ggui_user_* key in an Authorization header.

For the seamless one-click flow:

• OAuth 2.1 + Dynamic Client Registration (RFC 7591, RFC 8414, RFC 9728, PKCE). The host discovers, registers, and exchanges tokens with zero manual client_id paste. Details: OAuth on mcp.ggui.ai.

For inline rendering:

• MCP Apps capability — the host advertises that it can render ui:// resources in-line. Without it, the render is still produced (as a ui://ggui/render/<id> resource) but can’t be mounted; with it, generated UIs appear inside the chat or agent surface. Details: MCP Apps capability.

Anything else: see Troubleshooting.