Claude Desktop

Claude Desktop reaches a remote server two ways, and which one you use decides whether you handle a credential yourself. Read the first section before you pick.

Which route you are on

Custom connectors are Claude's built-in support for remote servers. You paste the Wexa URL into Settings, Claude discovers the authorization server, runs OAuth in a browser window, and stores the resulting token itself. Nothing touches a configuration file and no API key exists to leak. This is the route to prefer whenever it is available to you.

The local bridge is a small program Claude Desktop launches on your machine, which speaks the protocol over standard input and output to Claude and over HTTP to Wexa. It is configured in claude_desktop_config.json, works regardless of what the account offers, and is the route to use when you want a long-lived API key rather than an interactive login — for a shared machine, or an account that signs in as a service rather than a person.

Route A — custom connector

You need the project's connect URL, which carries the project identifier:

https://fabric.wexa.ai/mcp/{projectId}

Open Claude Desktop's settings — Ctrl+, or the menu icon, then File → Settings — and choose Connectors in the sidebar. Click Add, then Add custom connector, and paste that URL.

Claude then does the authorization on its own. It registers itself with Wexa dynamically, so there is no client identifier for you to create or paste anywhere, and it opens Wexa's consent screen in a browser. You sign in, confirm the organization, department and project, and approve. Because the URL you pasted was project-scoped, the consent screen binds to that project rather than offering you a picker.

When the browser hands you back, the connector is listed and Wexa's tools are available under the attachment menu at the bottom-left of the message box. Open the connector's own entry to switch individual tools off — worth doing, because the server advertises every tool it has registered whether or not your credential may call it.

Route B — the local bridge

Claude Desktop launches local servers from a JSON file. The file lives at:

• macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows — %APPDATA%\Claude\claude_desktop_config.json

Settings → Developer → Edit Config opens it, creating it if it does not exist. The bridge program itself is mcp-remote, run through npx, so you need Node.js installed but nothing installed globally.

With an API key, which is the reason most people choose this route:

{
  "mcpServers": {
    "fabric-acme": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://fabric.wexa.ai/mcp/proj_abc123",
        "--header",
        "Authorization:Bearer ${FABRIC_API_KEY}"
      ],
      "env": {
        "FABRIC_API_KEY": "fab_sk_..."
      }
    }
  }
}

Or without one, in which case the bridge runs the same OAuth flow a custom connector would, opening a browser on first launch and caching the token under your home directory:

{
  "mcpServers": {
    "fabric-acme": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://fabric.wexa.ai/mcp/proj_abc123"]
    }
  }
}

Quit Claude Desktop completely and reopen it. A restart is not enough on macOS if the application stays in the dock — quit it. The connector then appears under Manage connectors with Wexa's tool list.

Minting an API key takes one request and an administrator role on the project. The secret is shown once and stored only as a hash, so a key you lose is a key you replace rather than recover.

Check it worked

Ask Claude something only Wexa can answer, and watch which tool it reaches for. A good first request is one that exercises the documentation tool, because it works on every deployment and needs no data in your project:

Using Wexa, tell me what my current scope and quota are.

Claude should call docs, and the answer should name your organization, department and project identifiers, your grants, and your quota windows. If it names a project you did not expect, the connector is pointed at the wrong URL.

When it does not connect

Claude Desktop writes its logs to ~/Library/Logs/Claude on macOS and %APPDATA%\Claude\logs on Windows. mcp.log carries connection failures; a bridge server also gets its own mcp-server-<name>.log. The three answers you are most likely to find there:

410 Gone, with endpoint_moved. The URL has no project in it. https://fabric.wexa.ai/mcp is permanently retired; the working form is /mcp/{projectId}. This will not start working again, so fix the URL rather than retrying.

403, "this credential belongs to a different project than the one in the URL". The key or token is for one project and the URL names another. One of the two is a copy-paste error.

401, invalid_token. The key is wrong or revoked, or the OAuth token expired and could not be refreshed. Remove and re-add the connector to force a fresh authorization; on the bridge route, clear its cached credentials under ~/.mcp-auth.

A tool that connects but then refuses a specific call is a different thing entirely — that is Wexa's governance answering, and the message says which grant or policy stopped it. Policy decisions and approvals covers the ones that wait for a person.

Where to go next