Clay MCP Review 2026: Features, Setup and Limitations

Key takeaways:

• Clay MCP puts Clay’s people search, waterfall enrichment and Ops-built Functions inside Claude, ChatGPT, Microsoft Copilot, Codex and Glean, so reps never open Clay itself.
• Reps connect through the Sales Rep permission type, which grants MCP access only and hides the Clay UI, tables, API keys and workflows.
• Credits behave identically over MCP and inside Clay. A Function that costs 12 credits in a table costs 12 credits from Claude, with no surcharge.
• The governance you actually need is plan-gated: credit controls need a paid plan, and Audiences controls are Enterprise only.

Does Clay have an MCP server? It does, and it was built for reps who never open Clay rather than for the ops team that runs it, which explains almost everything about how it behaves.

Clay built its server for sales reps who never log into Clay, which is why the setup work lands on an admin rather than on the person using it. An ops lead invites reps, sets a credit budget, decides which Functions are callable, and then sends a connection link. The rep opens Claude and asks for contacts at a target account.

This review covers what the server exposes, how to configure it properly, what it costs, and the limits worth knowing before you roll it out to a team. We publish a sales engagement platform with our own MCP server, so we will be direct about where Clay ends and execution begins.

What Clay MCP Actually Is

Clay MCP is Clay’s hosted server built on the Model Context Protocol, the open standard that lets AI assistants reach software they do not own. It exposes your Clay workspace as a set of tools an AI client can call in natural language.

The supported clients are Claude, ChatGPT, Codex, Microsoft Copilot and Glean. Clay maintains listings in Claude’s connector directory and the ChatGPT apps directory, so for most teams connection is a matter of finding Clay in a list rather than editing a config file.

Clay’s own framing on its MCP page is “give reps the best prospecting data in their AI tools,” and the product is built around that sentence. It brings data from Clay’s provider marketplace and Ops-managed workflows into the tool a rep already has open.

The rep-first design is what separates it from the CRM-shaped servers arriving in the same category. A server built over HubSpot’s MCP surfaces records a company already owns, while Clay’s is pointed outward at data it does not have yet. Those are different jobs, and a stack can reasonably run both.

How Clay MCP Differs From the Clay API

The two surfaces are not interchangeable, and the difference is commercial rather than technical. Clay API access sits on the Enterprise plan, alongside data warehouse syncs, SSO and RBAC. It is the programmatic surface for engineering teams building on Clay.

The server is the conversational surface, and it reaches further down the price list. A rep on a paid plan can query people and companies and invoke Functions without anyone writing code, which is the entire point of the release.

There is a governance distinction too. The API authenticates as a key with broad reach, while MCP access is bound to a named user, their permission type, and a credit ceiling an admin controls. For a team handing prospecting data to reps rather than to services, that is the safer of the two shapes.

What Clay MCP Can Do

The tool surface splits into four jobs, and the one that most defines it is the waterfall: a single request fanned across multiple vendors until one returns a usable result. Functions and Audiences are Clay-specific too, but the waterfall is what a generic data connector cannot reproduce.

Functions are the part worth dwelling on. An ops team builds an enrichment workflow once in Clay, toggles Enable for MCP, and every rep can then invoke it from Claude with a single prompt. The logic, the provider order and the spend stay under central control while the rep gets a plain-language interface to it.

That design solves a real problem in GTM tooling, which is that the person who understands the data plumbing is rarely the person who needs the output. Clay’s answer is to let the first group build and the second group call.

The waterfall deserves its reputation. Rather than querying one vendor and accepting a miss, Clay keeps trying the next provider in line, which is why hit rates hold up on harder segments. Most standalone AI prospecting tools resolve against a single database and simply return nothing when that database has a gap.

One behavior surprises teams on first use. The assistant decides which tool to call, so the phrasing of a request influences whether Clay runs a built-in search or one of your Functions. Reps get better results when they name the Function they want rather than describing the outcome and hoping the model routes correctly.

How to Set Up Clay MCP

Setup is admin-first. A rep cannot self-serve their way into a workspace, and the sequence below is the one that avoids the two common failures: reps connecting before a credit budget exists, and Functions that never get invoked because their names collide with Clay’s built-in tools.

Step 1: Invite Reps With the Sales Rep Permission Type

There are two routes to the same permission, and the second is faster when everyone you are adding is MCP-only.

1. Go to Settings → Team, click Invite, and set the permission type to Sales Rep in the invite dialog.
2. Alternatively, go to Settings → MCP users and click Invite users, which opens the same dialog with Sales Rep preselected.
3. Confirm the permission type before sending if the person also needs the Clay web app, because the MCP users page is a shortcut to the same invite rather than a separate kind of access.

The Sales Rep type is what makes this safe to hand out. It grants MCP-only access, and those users cannot see the Clay UI, tables, API keys or workflows.

Step 2: Set a Default Credit Limit Before Anyone Connects

Order matters here. The default credit limit applies automatically to every new MCP user at the moment they first connect, so setting it afterward leaves your earliest and most enthusiastic reps uncapped.

Open Settings → MCP users, click Set default limit, and choose a workspace-wide monthly budget. Individual reps can then be given a per-user override through the pencil icon next to their credit limit, and their consumption tracks against it live in the user table.

Credit spend resets on the first of each month at midnight UTC. A rep who hits their ceiling is hard-blocked from further enrichments and Functions until that reset, though raising their limit restores access immediately.

Step 3: Enable the Functions Reps Should Be Able to Call

Open the Functions tab, click into a function, and toggle Enable for MCP. Give it a name and description a rep would recognize, because that is what they see when browsing what is available.

Two configuration mistakes cause silent failures. A function without an enrichment or output column returns nothing, since toggling MCP and setting inputs alone does not produce data. And a function named too close to a built-in tool, such as “find contacts” or “enrich company,” may lose out to Clay’s default when the assistant picks which tool to invoke.

Step 4: Connect the AI Client

Reps connect Clay from inside their assistant rather than from Clay. In Claude, Clay appears in the connector directory; in ChatGPT it appears as an app. Copilot users install from the Microsoft marketplace, and Glean users enable the Clay connector.

Clay publishes a separate connection guide per client, which is what you send reps rather than walking each one through it. Once connected, the rep’s platforms show up as icons in the MCP users table, alongside their credit limit and live usage.

Watch that table for the first week. It shows which reps actually connected and what they are spending, and a rep showing No limit has neither a default nor an override applied, which usually means they connected before step two was done.

MCP consumption also rolls up into the main credit usage dashboard under Settings → Credit Usage, alongside the rest of your workspace spend. Clay’s admin surface is more mature than most AI GTM agent tools currently offer, so it is worth using rather than assuming the defaults are safe.

What Clay MCP Costs

There is no separate price for the connection, and no MCP surcharge. Credits work the same way through an AI client as they do inside Clay: if a Function that finds an email and phone number costs 12 credits in a table, it costs 12 credits when a rep triggers it from Claude.

What is gated is the governance around it, which matters more than the connection itself.

Clay’s list prices move with a credit slider, and its own pricing page currently states different Launch and Growth starting figures in the plan cards than in the FAQ beneath them. Treat the published numbers as a starting point and confirm your tier against the slider at the volume you actually need, because the headline figure is not the figure most teams pay.

The structural facts are steadier than the prices. A modern paid plan is the entry point for credit controls and usage monitoring, Audiences controls need Enterprise, and full Clay API access sits on Enterprise too.

Budget for the data rather than the connection. Because every enriched email, phone number and Function run draws from the same credit pool the rest of your workspace uses, a team of ten reps querying freely through Claude will move consumption faster than the same team clicking through tables. That is an argument for setting the default limit deliberately, not an argument against the server.

Comparing the all-in cost against a bundled alternative is worth doing before you commit. Platforms that ship a contact database inside the subscription price the data differently, and for teams whose enrichment needs are modest the per-credit model can end up the more expensive of the two.

Where Clay MCP Falls Short

Clay is candid about most of these in its own documentation, which is more than many vendors manage. They are still worth knowing before a rollout.

Revoking one rep’s connection is awkward. Admins cannot directly disconnect a rep’s MCP connection from the MCP users page. The documented options are to remove them from the workspace entirely, or set their credit limit to zero, which hard-blocks further actions without removing access. Neither is the clean per-connection revoke an IT team expects.

The rep experience degrades without Audiences. On non-Enterprise plans reps get people and company search plus Functions, which is genuinely useful, but they cannot query the accounts they own or pull opportunity data from the CRM. The account-aware experience Clay demonstrates is an Enterprise feature.

Audience sync is not instantaneous either. User ID syncing from Audiences runs incrementally every 15 minutes with a full sync weekly, so a territory change is not reflected the moment it happens.

There is also a category limit rather than a product flaw. Clay MCP is built to find, enrich and hand off. It is not a sequencing engine, and the deeper questions about deliverability, multichannel branching and reply handling sit outside what these tools answer.

Finally, the governance burden is real. The NIST AI Risk Management Framework puts a Govern function at the center of its four, covering the policies and accountability structures that surround an AI system rather than the model itself. Clay’s credit ceilings and permission types are exactly that kind of control, and they only work if someone configures them before reps connect rather than after.

Pairing Clay MCP With Reply MCP

Clay and Reply.io do not compete on this surface, which makes the pairing straightforward. Clay MCP is strongest at sourcing and enriching. Our server is built for what happens next, and the split falls cleanly along that line.

We should be plain about our own gap, because it is the mirror image of Clay’s strength. Nothing in our catalog sources data: there is no enrichment tooling and no way to find an address we do not already hold. The reply_search_contacts tool reads the workspace you have built. Sourcing a net-new list is Clay’s job, not ours.

The credit mechanics differ in a way worth planning around. Clay meters per rep with an admin-set monthly ceiling, while our tools split into three groups: some always consume Reply.io credits, such as pulling contact statistics or sequence click data, and others never do, including starting a sequence, pausing one, or adding contacts to it. Enrolling a hundred prospects costs nothing on our side, which changes where the expensive step in a combined workflow actually sits.

That combination reflects how modern outbound is assembled. Reps spend only about 28% of their week actually selling according to Salesforce research, and the rest disappears into the tab-switching that both of these servers exist to remove. Sourcing in one tool and executing in another is only worth it if neither step drags the rep back into a UI, which is precisely what a pair of MCP servers prevents.

Teams already running both stacks can connect them directly, and we maintain a Clay integration for exactly that handoff. You can also run the pairing entirely through the two MCP servers, with the assistant orchestrating both.

Who Clay MCP Is For

Clay MCP fits teams with an ops function and reps who should not be in Clay. If you have someone building enrichment workflows and a sales team that needs the outputs, this is a well-judged product with governance built in from the start.

Solo operators get less from it, since the Sales Rep permission type and credit ceilings are overhead protecting them from themselves. It also underdelivers below Enterprise if your reps expect the CRM-aware experience, because that depends on Audiences.

For a fuller picture of the platform behind the server, our Clay review covers the tables, waterfalls and Claygent surface that Functions are built on. The MCP server inherits that platform’s strengths and its pricing model alike, so the two are worth reading together.

Ready to put the execution half in the same assistant? Start a free trial and run our server next to Clay.