Playbooks · Recipe
Connect the MCP server once, then research an account by asking for it. Claude picks the endpoints, runs them, and hands back the execution_log receipt for each call. Only the email and phone waterfall calls are miss-free; the enrichment and search calls bill on a 2xx.
Last updated September 22, 2026
Pattern: One prompt → enrich_company → linkedin_company_employees_search → email_finder → email_verifier, chosen and sequenced by the assistant, run against your key and your credit pool.
Credit math: One account, done properly: enrich_company 1 credit per call + linkedin_company_employees_search 0.1 credits per result × 5 results = 0.5 + enrich_profile 1 credit per call × 2 + email_finder 5 credits per call × 2 + email_verifier 2 credits per call × the ones that hit. Twelve accounts before a Monday pipeline review lands in the low hundreds of credits, and the finder misses inside that cost zero.
ROI math: Compare against the hour a rep spends with fifteen browser tabs open per account, and against the per-seat sales-intelligence licence that rep would otherwise need. Credits are pooled, not per-seat. See /pricing.
Owned internally by: The person doing the research. No engineer required after setup, which is the point.
Best for: AEs and founders prepping a small number of named accounts, and anyone who would rather type a sentence than build a script for a job they do twice a week.
// Claude Desktop / Claude Code MCP config — same key as the REST API,
// same credit pool. Full setup at /integrations/claude.
{
"mcpServers": {
"richapi": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.richapi.ai/mcp",
"--header",
"x-api-key: ${RICHAPI_KEY}"
]
}
}
}
Research acme.com for a first meeting on Thursday.
1. Enrich the company from its LinkedIn company page URL: headcount,
industry, specialties.
2. Find up to five people there with "revenue operations" or "sales
operations" in the title. Stop at five; do not page further.
3. For the two most senior, find a work email and verify it.
4. Give me a table: name, title, email, verification status, and the
credits each call cost. Where a finder call missed, say which
providers were tried rather than leaving the row blank.
Create a key at app.richapi.ai/signup.
25 free credits, no card.
Add the MCP server to your client config: the block above, or the per-client instructions at /integrations/claude. The host is mcp.richapi.ai and auth is an x-api-key header.
Restart the client and check the tool list.
The tool names map one-to-one onto the REST endpoints, so anything in the API is available in the chat.
Give the assistant a budget in the prompt.
'Stop at five people' and 'do not page further' are the difference between a 12-credit answer and a 200-credit one.
Ask for the cost column.
Every waterfall call returns its own billing line; making the assistant surface it turns an opaque session into a receipt you can read.
Account research is a sequence of lookups that every rep does slightly differently and nobody writes down. Find the company. Work out who owns the problem. Get their email. Check it isn't dead. It takes an hour per account with a browser, or twenty lines of script you then have to maintain. Through MCP it's a paragraph. The assistant picks the endpoints, fills the arguments from your prose, runs them against your key, and shows you what each call returned and what it cost.
Four steps, in this order, because each one produces the input for the next: 1. **`enrich_company`** — 1 credit per call. Headcount, industry, specialties. Takes a **LinkedIn company page URL, not a domain**. If you hand the assistant a bare domain it will need `find_website_by_company_name` or a search step first, and that costs a call. Give it the LinkedIn URL when you have it. 2. **`linkedin_company_employees_search`** or **`people_search`** — per-result, 0.1 credits per result. Title-filtered. This is where an unbounded prompt gets expensive: 200 rows returned is 200 rows billed. 3. **`enrich_profile`** — 1 credit per call, also a LinkedIn URL, for the two or three people you actually care about. 4. **`email_finder`** at 5 credits per call, then **`email_verifier`** at 2. Waterfall. A finder call that comes back with nothing returns `success: false`, `billed: false`, and costs zero. Steps 1 through 3 bill on any 2xx, including a thin one. Step 4 doesn't bill on a miss. That asymmetry is worth telling the assistant about, because it changes where caution is expensive: exploring with search calls costs money, retrying a finder does not.
The reason to do research in a chat window is speed. The reason not to is that you cannot see what happened. An assistant that reports "I couldn't find an email for Dana" is indistinguishable from an assistant that never made the call. Every waterfall call returns an `execution_log`, an array of provider attempts with per-attempt status, plus a `billed` field. Ask for it in the prompt and the failure becomes legible: four providers tried, three returned no data, one timed out, nothing charged. Now you know whether to retry with the LinkedIn URL instead of name-plus-domain, or to accept the person isn't findable. We don't publish the provider roster, because it changes as we add and drop providers. The per-call log is the honest version of that answer.
The thing that goes wrong is not a wrong answer. It's a loop. You ask for "everyone in revenue at these twelve accounts", the assistant calls a per-result search endpoint with a generous limit, gets 300 rows per account, and enriches them because you said "everyone". Nothing errored. You just paid for 3,600 rows you will never read. Three guards, all of them prompt-level: - **Cap the result count explicitly.** "Stop at five." "Do not page past the first page." Per-result endpoints bill per row returned, so the limit *is* the budget. - **Name the endpoint when you care.** "Use the company employee search, not a general people search" stops the assistant picking the broader tool. - **Ask for the cost column.** An assistant that has to report credits per call behaves noticeably better than one that doesn't. Start on the 25 free credits. If a prompt blows through those, it would have blown through a funded balance too, and you found out for nothing.
Every tool in the catalog is a read-only lookup. Nothing sends an email, posts anything, or writes to your CRM. The worst outcome of a badly phrased prompt is spent credits, not a message going out to a customer with an unfilled merge field in it. There is also no CRM-native app. The assistant hands you a table; getting it into Salesforce is your integration.
**Does this work in Cursor and other MCP clients, not just Claude?** Yes. It's a standard remote MCP server. Client config formats differ; [Claude](/integrations/claude) carries the one we test. **Can the assistant spend my whole balance?** It can spend credits, which is why every result carries a cost line and why the free tier exists. Cap result counts in the prompt. **Why does `enrich_company` reject my domain?** Because it takes a LinkedIn company page URL. This trips up nearly everyone once. See [company enrichment](/api/company-enrichment). **Is the MCP data different from the REST data?** No. Same endpoints, same key, same credit pool, same responses. Prove a workflow in chat, then automate the version that worked against [people search](/api/people-search). **Do I need a credit card?** No. 25 free credits on signup, enough to research one account properly.
The [use cases](/use-cases) hub has the rest of the plays. [Claude](/integrations/claude) for setup detail, [list build and verify](/use-cases/list-build-and-verify) when the same chain has to run over 500 rows instead of 12, and [waterfall email then verify](/use-cases/waterfall-email-then-verify) for the billing model on the last two legs. Tiers on [pricing](/pricing). **25 free credits, no card.** Connect the server and research one real account before your next call.