Integrations · Cursor
Add RichAPI's hosted MCP server to Cursor and call enrichment endpoints from the Composer window while you are writing the code that will call them. Waterfall endpoints (email_finder, email_verifier, phone_finder) cost nothing on a miss; every other endpoint bills on a 2xx, including an empty one.
Last updated September 22, 2026
Create a RichAPI account at app.richapi.ai/signup and copy your API key.
25 free credits, no card.
Put the key in your shell environment as RICHAPI_KEY so it never lands in a file you might commit.
Add the server to ~/.cursor/mcp.json for every project, or .cursor/mcp.json for one repo.
Cursor uses the same mcpServers key as Claude, so the mcp-remote shim config is identical.
Open Cursor Settings → MCP and confirm richapi shows a green dot and a tool list.
A red dot almost always means npx could not run or the key env var was empty when Cursor launched.
In Composer, ask for one call against real input and read the response before you write a single line of parsing code.
Copy, paste, edit the brackets, run.
Why it matters
Most enrichment bugs are shape bugs: you wrote the parser against a response you imagined. With the MCP server in Cursor the model can call the live endpoint, read what actually came back, and write the type from that instead of from the docs.
RichAPI runs a hosted MCP server. Connect it to Cursor and the agent that is writing your enrichment code can also run it, against live data, while it writes. The bug you keep shipping in enrichment code is not a logic bug. It is a shape bug: you wrote `response.data.email` against the example in a README, the real response nests it one level deeper on a partial hit, and you find out in production on row 4,000.
Create an account at `app.richapi.ai/signup`, copy your key, and export it before launching Cursor: ```bash export RICHAPI_KEY="rk_..." ``` Cursor reads MCP servers from `~/.cursor/mcp.json` for every project, or `.cursor/mcp.json` inside a single repo. It uses the same `mcpServers` object as Claude, so the config is the one from the [Claude integration](/integrations/claude): ```json { "mcpServers": { "richapi": { "command": "npx", "args": [ "mcp-remote", "https://mcp.richapi.ai/mcp", "--header", "x-api-key: ${RICHAPI_KEY}" ] } } } ``` Recent Cursor builds also accept a remote server directly, with a `url` and a `headers` object instead of a command. That shape is cleaner when it works and version-dependent enough that we will not print it as the recommended path. The shim above works on every version that supports MCP at all. Then open Settings → MCP. `richapi` should show green with its tools listed. Red usually means one of two things: `npx` was not on the PATH Cursor inherited, or `RICHAPI_KEY` was empty because you exported it in a terminal opened after Cursor. If you put `.cursor/mcp.json` in a repo, keep the `${RICHAPI_KEY}` reference rather than the literal key, and commit it only if your team is happy with that file being read by everyone with clone access. The key stays in the environment either way.
The tools map one-to-one onto the REST endpoints, so anything you can curl, Composer can call: - [`email_finder`](/api/email-finder) and `email_verifier` — the pair most enrichment pipelines are built around. - `phone_finder` — a mobile from a LinkedIn URL, or name plus company. - [`enrich_profile`](/api/person-enrichment) and `enrich_company` — both take a LinkedIn URL, not a domain. This trips people up often enough that it is worth having the agent discover it by calling the endpoint rather than by reading your assumption back to you. - `people_search` — profiles filtered by industry, headcount, title, location. - `web_tech_stack` — what a domain runs. Three things worth asking for by name: > Call `email_finder` once with this input and write the TypeScript interface from the actual response, including every nullable field. > My fixtures in `test/fixtures/` were hand-written. Replace them with real responses from `enrich_profile` for these three URLs. > Run `email_verifier` against our seed list and tell me which of my status branches are never hit by real data. The last one is the one that saves a weekend. Handwritten fixtures encode your assumptions, so the tests pass and production does not.
An empty call could mean the providers ran and found nothing, or it could mean something broke. The `execution_log` on waterfall responses separates the two. It shows who ran and what each returned, and a `billed` field sits beside it. We do not publish the provider roster, because it changes as providers are added and dropped. The per-call log is the honest version of that answer.
Billing is prepaid credits from one pool shared between MCP and REST. Rates: each tool above bills its published per-call rate, with `people_search` priced per result, which makes any cost estimate meaningless unless you state the result count. See [/pricing](/pricing) for the current rate tiers, or run numbers through the [waterfall cost calculator](/tools/waterfall-cost-calculator). On `email_finder`, `email_verifier` and `phone_finder`, a call that finds nothing costs zero. Providers ran, nobody found data, you were not charged. Everywhere else a 2xx bills, including a 2xx with an empty body. We would rather put that limit on this page than have you meet it on an invoice. Now the agent-mode part. Cursor's agent can loop. A prompt like "enrich every domain in this CSV" will do exactly that, one call at a time, without asking you again. Nothing in the catalog sends email or writes to a CRM, so the worst case is spent credits rather than a message to a customer. Try it on the 25 free credits before you fund anything, and keep bulk loops in code where you can see the iteration count.
There is no prospecting UI, no sequencer, no CRM app. If you want a grid you can click through, that is [Clay](/integrations/clay), and scheduled runs belong in n8n rather than an editor session. Cursor is for the stage where you are still deciding what the pipeline should do.
**Is this an official Cursor integration?** No. It is a standard MCP server and Cursor is a standard MCP client. There is no marketplace listing to install. **Does Cursor's config differ from Claude's?** The `mcpServers` shape is the same, so the shim block above works in both. The file location differs (`~/.cursor/mcp.json` or `.cursor/mcp.json`), and Cursor's native remote-server support has moved between releases, which is why we default to the shim. **Will my key end up in the repo?** Not if you reference `${RICHAPI_KEY}` as shown. Never paste the literal key into `.cursor/mcp.json` in a tracked repo. **Can I use the same key from code?** Yes. One key, one credit pool, `https://api.richapi.ai/api/v1/{endpoint}` with an `x-api-key` header. Prove the call in Composer, then ship the version that worked. **Why not just curl it?** You can, and for one call you should. The gain is that the model reads the response too, so the code it writes matches what came back instead of what the docs implied.
25 free credits, no card. Add the config, restart Cursor, and have it write your response type from a real call instead of a guess. Other clients on the [integrations hub](/integrations): [Claude](/integrations/claude), [VS Code](/integrations/vs-code), [Windsurf](/integrations/windsurf).