How to Connect Clay MCP to Claude Code, Scoped to One Client (Not Your Whole Machine)

Here's the setup I actually have. I run Clay for more than one client. Each one is its own world: its own data, its own workspace, its own rules about what is allowed to touch it.

Clay scopes its MCP to one Clay instance. Fair enough. But the way it wants me to connect assumes I am one company wiring my one Clay into my one Claude. I am not. I don't want my Clay instance bolted into a client's setup, and I don't want my Claude bolted into theirs either. I want Clay live in one project folder and nowhere else. Open Claude in that folder and Clay is right there. Open it in any other folder and there is nothing. A wall, not a default.

And I want room to experiment in that one folder without Clay running in the background across everything else I touch.

Right now Clay gives you two doors: the ChatGPT connector and the native Claude connector. That is it. Neither one gives me the wall.

Getting there took a workaround. The short version: a local mcp-remote bridge, dropped into one project's .mcp.json. The longer version is the interesting one, because the workaround quietly opens two doors Clay never advertised, and it shows you who these connectors were actually built for.

Clay built this for one company, not your client list.

Look at what Clay ships and you can see who it pictured. Two connectors, ChatGPT and Claude, each a one-click login into your one workspace. That is the single-company setup: one team, one Clay, one seat, clicking around inside the product. It is a reasonable bet for most of their buyers. It is also not an agency, a consultant, or a freelancer who runs five clients in five scoped projects and cannot let any of them bleed into another. The connector is global by default because it assumes there is only one tenant to serve. You.

The Clay MCP server URL is not secret. It is just not printed where you're looking.

The endpoint the official connector talks to is https://api.clay.com/v3/mcp. It is even listed on the public MCP directories, with OAuth and setup blurbs for Claude Code, Cursor, and Codex. What is missing is inside Clay's own product: open the MCP settings and you get the two connector cards and no URL, because Clay pre-registers those two clients and hides the endpoint behind the button.

Confirm any MCP URL before you trust it with one request, straight out of Claude Code's troubleshooting page:

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  https://api.clay.com/v3/mcp

A 401 means the endpoint is live and wants authentication, which is exactly right. A 404 or a dead connection means you have the wrong URL. Clay returns 401. Ignore the directory entries pointing at mcp.clay.earth, because that is a different company's personal-CRM product, not the Clay you run outbound from.

Here is the catch that sets up the rest. That same directory tells you to run claude mcp add clay --transport http https://api.clay.com/v3/mcp. Copy it, run it, and it breaks.

Then Claude Code told me I was impersonating myself.

The command never reached the login. Claude Code reported:

Client name must not impersonate a known platform.

Here is the mechanism. Remote MCP servers use OAuth, and a brand-new client registers itself on the fly through Dynamic Client Registration. In that handshake the client states its name. The known weakness is that anything can self-assert a trusted name and phish you on the consent screen, so Clay's auth server rejects any registration whose name looks like a known platform. Claude Code registers under a name with "Claude" in it. Clay blocks it as impersonation. Claude Code cannot authenticate to a server precisely because it is called Claude.

The tell that cracked it: the same URL connects from Cursor in one line, because Cursor registers as "Cursor," which is not on the blocklist. So the endpoint and my account were fine the whole time. The only thing being rejected was the string on the registration. And underneath the bug is the reveal: the filter cannot picture a caller that is not the platform itself. Same assumption as the connector. One company, one known client, you.

You cannot fix it from the Claude Code side either, because it will not let you rename the client and it will not fall back to static credentials to skip registration (open issue). Dead end, head-on.

They did not build it for agents either. On purpose.

Notice which clients get a card and which do not. ChatGPT and Claude, the two chat apps where a person sits and types. Not your terminal, not n8n, not a local agent calling Clay as one tool inside a pipeline. That is not an oversight. Clay is a product, and a product wants you inside it, in the surface where the value and the retention live. Handing its functions to your own agent to orchestrate is the opposite of that. I don't blame them for it. They built for the buyer they can see. But it means the official path will never be the one an operator actually needs.

The fix routes around both.

Put a local process in the middle that does the OAuth under its own name and hands the finished connection to Claude Code over stdio. That is what mcp-remote is for. Claude Code talks to the bridge with no auth at all. The bridge talks to Clay, registers under a name that clears the filter, and refreshes the token. Claude Code never registers against Clay, so the brand filter never fires.

Drop this into .mcp.json at the root of the one client project it belongs to:

{
  "mcpServers": {
    "clay": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.clay.com/v3/mcp"]
    }
  }
}

First run opens a browser to Clay's login. Approve once and Clay's tools show up. Now the test that matters: open Claude in that folder and Clay is live. Open it in any other folder and Clay is not there. That is the wall I wanted, and it is a plain file in one repo, not a setting that reaches across my whole machine.

Housekeeping: if the token ever goes stale, delete the cached creds in ~/.mcp-auth/ and re-run. And watch the meter, because Clay's functions run roughly 20 to 100 credits a call with 500 free on first connect, so set a cap before you point anything automated at it.

What this actually unlocks.

Two doors, and they are the whole reason this is worth writing down.

-> Clay in your own agents. The bridge is just stdio and a URL, so it works anywhere that speaks MCP: n8n, a local agent, your own pipeline. You call Clay as one tool among many, orchestrated by you, instead of clicking inside Clay. The exact thing the product was built to keep you out of.

-> Clay scoped to a folder, not your whole Claude. Live in the project you opened, invisible everywhere else. Client A's Clay cannot fire while I am working in Client B's repo, because as far as that repo is concerned it does not exist.

Both come down to the same thing. Walls I set, instead of a connection running in the background I never scoped.

The wall is the whole point, not a detail.

Say I had taken the one-line install and let it run at user scope, the way the directory tells you to. Clay loads into every Claude Code project on the machine. Then I am in Client B's repo, Claude decides the job needs a contact, and it fires an enrichment against Client A's workspace. Credits on the wrong account. A tool acting on one client's data while I work for another. That is not an edge case. That is the default the easy path hands you. The boundary has to be something I set and can see. A connection you cannot scope is a connection you cannot govern.

This is the app-server moment for business tools.

We have watched this shape before. Demand for a technology surges before the process for deploying it is mature. App servers in the late 90s. Big data in the late 2000s. MCP connectors right now. In that window you cannot hand the work to arm's-length services, because it takes someone who knows what happens under the hood. Wiring Clay into an agent, past an OAuth filter, scoped to the right repo, is a small piece of exactly that gap.

The one difference this time: the connections act on their own. A stale one in the wrong folder is not a dead link you notice next week. It is an agent taking a live action against a real client before you catch it.

The dirty little secret: the credits are subsidized.

Twenty to a hundred a call, and a stack of free ones to get you moving. Early MCP pricing looks a lot like early rideshare pricing, cheap because someone is funding the introduction, not because the unit economics are settled. Sounds a lot like every pre-scale token subsidy, doesn't it. Two takeaways that point the same way: keep the connection observable so you know what it is spending, and keep it portable so you can rip it out when the price turns. You do not want the meter running inside a black box you do not own.

The N×M problem shows up the second you have two clients.

One client, one tool, scoped to its folder: clean. Now run five tools across five clients by hand. That is twenty-five connections, twenty-five walls to keep straight, twenty-five blast radii, every one a .mcp.json you edited at midnight. Put something in the middle and you are managing ten. That is the argument for a gateway, and it is arithmetic, not features.

This is the gap Camber Core closes. Each client is its own site behind its own fence, its tools scoped to it, nothing crossing by accident, and you read every site from one desk instead of driving to each one. At its core it is observability: who connected what, on which account, in what order. It is managed, there is a real person on the account, and you keep the code. You could stand up a rough version in a weekend. The standing job is keeping it fit while the ecosystem churns under you, which is why it is a service and not a download.

Clay gave you two doors. Both built for one company clicking inside one product.

The wall, the agents, the second client and the fifth: none of that was on the menu. It took a workaround to get it, and the workaround is the tell. The tools you run across clients were not drawn for how you work, so you draw the walls yourself. How are you scoping yours?

- Jaron