Connecting a client

There are two URLs to choose between, and every client below takes either one. Both sign in through your browser the first time they are used, and nothing else has to be configured on either side.

Which URL#

https://exeora.dev/mcp is the same for everyone and covers several projects at once. When you authorize a client on it, the consent screen asks what it may reach: all your projects, including the ones you add later, or only the ones you tick. The client uses list_projects to see them and names the project on each tool call whenever more than one is available.

With all projects chosen, you add the URL once and it keeps working as projects come and go: a project is given to that client the moment it is created, from the dashboard or from a machine. With a chosen list, a project you add later stays out of reach until you give it to the client, either while adding the project in the dashboard or under Clients. Taking one project away from a client that had all of them turns it into a chosen list.

Either way, what a client is given is a project, not a machine. It reaches that project in every location it lives in, and list_projects shows it those locations and the state of each.

https://exeora.dev/p/<project>/mcp, which exeora project add prints, is one project and nothing else. The project is in the URL rather than in anything the client sends, so a client on it has no way to name another project: the separation is structural rather than something the model is asked to respect. That is the stronger guarantee, and the cost is one entry per project in every client.

Ticking a single project on the account URL gives you the same reach as a project URL, and you can change which projects a client reaches, or cut it off entirely, from the dashboard under Clients. The two are separate consents: a client authorized both ways keeps whichever you do not take away.

The steps below use https://exeora.dev/mcp; a project URL goes in the same place. Menus move between releases, so each section names the setting as the client's own documentation does today.

Claude Code#

claude mcp add --transport http exeora https://exeora.dev/mcp

Then run /mcp inside Claude Code, or claude mcp login exeora, to sign in through the browser. Add --scope project to share the entry through the repository's .mcp.json, or --scope user for every project.

Claude#

Customize → Connectors → + → Add custom connector, paste the URL and choose Add, then Connect. On Team and Enterprise an owner adds it first, under Organization settings → Connectors, and members connect to it from Customize. The free plan allows one custom connector.

Claude speaks the 2025 protocol today, which matters only for confirmation prompts: see confirming a change.

ChatGPT#

For the MCP connection plus guided skills and setup, download the Exeora plugin. That page explains local installation and the separate connection flow for ChatGPT web.

Custom MCP servers are part of developer mode, on the web, on Plus, Pro, Business, Enterprise and Education. Turn it on under Settings → Security and login → Developer mode, then open chatgpt.com/plugins, add an app with the URL, and choose OAuth. In a chat, pick it from the + menu under Developer mode. On Business and Enterprise a workspace admin may have to allow developer mode first.

Same note about the protocol revision as Claude.

Cursor#

Add the server from Cursor's MCP settings, or write it to ~/.cursor/mcp.json for every project or .cursor/mcp.json for one:

{
  "mcpServers": {
    "exeora": { "url": "https://exeora.dev/mcp" }
  }
}

Cursor registers itself and opens the sign-in when the server is first used.

VS Code#

Run MCP: Add Server from the command palette, choose HTTP, paste the URL, and pick Workspace or Global. The same entry in .vscode/mcp.json:

{
  "servers": {
    "exeora": { "type": "http", "url": "https://exeora.dev/mcp" }
  }
}

GitHub Copilot#

In VS Code, Copilot's agent mode uses the servers above: add Exeora as in VS Code and sign in from the Auth action shown over the entry. In JetBrains IDEs, open Copilot Chat in agent mode, choose the tools icon, then Add MCP Tools, and add the server to the mcp.json it opens; OAuth there is still in preview.

{
  "servers": {
    "exeora": { "url": "https://exeora.dev/mcp" }
  }
}

On Copilot Business and Enterprise, an administrator has to enable the MCP servers in Copilot policy first; it is off by default. Copilot's cloud agent on github.com does not support servers that sign in with OAuth, so it cannot use Exeora today.

Devin#

Customize → MCPs → Add MCP → Add custom MCP. Choose the HTTP transport, paste the URL, set the authentication method to OAuth, save, and choose Connect. Organization access shares one connection with everyone; Personal has each member sign in as themselves, which is usually what you want, since the grant is to your Exeora account. Adding a server takes the Manage MCP Servers permission.

Antigravity#

From the … menu at the top of the agent panel, open MCP Servers → Manage MCP Servers → View raw config, and add the server to mcp_config.json. Antigravity reads the address from serverUrl; url is not supported.

{
  "mcpServers": {
    "exeora": { "serverUrl": "https://exeora.dev/mcp" }
  }
}

Then choose Authenticate for it under Agent Settings → Customizations.

Amp#

amp mcp add exeora https://exeora.dev/mcp

Or in ~/.config/amp/settings.json. Amp registers itself and opens the browser to sign in the next time it starts.

{
  "amp.mcpServers": {
    "exeora": { "url": "https://exeora.dev/mcp" }
  }
}

Zed#

Settings → AI → MCP Servers → Add Server → Add Remote Server, or in settings.json. With no Authorization header configured, Zed asks you to sign in with OAuth.

{
  "context_servers": {
    "exeora": { "url": "https://exeora.dev/mcp" }
  }
}

OpenCode#

In opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "exeora": { "type": "remote", "url": "https://exeora.dev/mcp", "enabled": true }
  }
}

OpenCode signs in by itself on first use; opencode mcp auth exeora starts the sign-in by hand.

Grok#

On grok.com, open Connectors → New Connector → Custom, paste the URL and complete the sign-in. On Business and Enterprise a team admin adds the connector first. xAI's documentation does not yet say whether custom connectors register themselves with OAuth; if the sign-in never completes, that is the part missing on Grok's side, and nothing on Exeora's can change it. The Grok API's remote MCP tool takes only a bearer token, so it cannot sign in to Exeora.

Perplexity#

Account Settings → Connectors → Custom connector → Remote. Paste the URL, choose OAuth for authentication and Streamable HTTP for transport. Custom connectors are on the Pro, Max and Enterprise plans, and on Enterprise an admin has to allow members to add them.

More clients#

• Codex: codex mcp add exeora --url https://exeora.dev/mcp, then codex mcp login exeora.
• Gemini CLI: gemini mcp add --transport http exeora https://exeora.dev/mcp, then /mcp auth exeora.
• Windsurf: add the server to Cascade's mcp_config.json with serverUrl, as for Antigravity.

Anything else#

Any client that speaks MCP over Streamable HTTP with OAuth 2.1 will work; there is nothing Exeora-specific to implement. To try one by hand:

bunx @modelcontextprotocol/inspector@2.1.0

If a call fails immediately#

LOCAL_EXECUTOR_OFFLINE means a machine of yours is off, or exeora connect is not running on it: the machine that holds the workspace the call named, or the default location when it named none. Nothing is queued, on purpose. EXECUTOR_WAKING means an instance on Exeora Cloud was asleep and did not come up in time, or the instance of the project root is being made, and the call is worth sending again. See troubleshooting.