The problem this solves
Cursor is where you are building the integration, and every company or person you need to check during that work sends you to a browser tab: what does <company.com> do, how big is it, who runs marketing there, is that address real. The tab has the answer and the editor has the code, and the two never meet in the commit.
Through MCP the editor's agent can ask those questions itself and get JSON back: firmographics, technographics, funding and news for a domain; a person by name and company with a found and verified email; and a row added to list <name> so the lookup becomes part of a list your team already works. These are the same tools the Company Intelligence Agent uses in the console, called from the agent panel in Cursor.
The setup is a config block and a key. What deserves thought is the key's scope, because an agent that can add rows to a list and verify emails does useful work, while an agent that can push to your CRM from an editor session is one bad prompt from a mess. Reads, verification and list writes on this key; external writes off it.
How the mission runs
- Create a key for the Cursor session. On the API-keys page you mint a key named for Cursor with scopes covering company and people search, email verification and list writes. Signing in from Cursor at connect time works too: you approve a workspace, and the granted key lands on the same page under the client's name, revocable there in one click.
- Add the config block. The Company Intelligence Agent gives you the MCP server entry for Cursor's settings - the server URL and the Authorization header carrying the Bearer key - and the same block is what the CLI's connect command prints for Cursor. Adding the tools=all option to the URL exposes the individual data tools; leaving it off exposes mission_agent for whole objectives.
- Look up a company by domain. With the server connected, the agent resolves <company.com> into a profile: what the company does, headcount and industry from firmographics, the technologies detected on its properties, recent funding and news, and similar companies. The response is JSON, so the agent can quote a fact in a comment or write it into a fixture.
- Find a person by name and company. Given a name and a company, people search returns the person's title, seniority and department, and the email finder fills the address through the waterfall, billed only when a source answers. The phone finder works the same way when a direct number is needed.
- Verify before you trust. Every address passes email verification, returning a status - deliverable, risky, catch-all or invalid - and a confidence value. The agent can gate its own next action on the status, so a fixture, a test account or a list row never carries an address that bounces.
- Add rows to list <name>. The agent writes the company or the person to list <name> as a row that carries the evidence it just gathered. The list is persistent and shared, so a rep sees the row in the console minutes later with the verified email and the facts the editor session found, and the next scoring pass on the list gives it a fit score.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
The MCP server entry for Cursor with a Bearer key scoped to lookups, verification and list writes, plus a test prompt: look up <company.com>, find the head of marketing there, verify the email and add both to list <name>. Run it once and the whole loop works from the editor: a company profile and a person as JSON, a verification status on the address, and a new row on list <name> that the rest of the team can see and act on, every call metered and recorded under the key's name.
Make it yours
- Use the same block for VS Code, Windsurf, Codex or Gemini CLI; the CLI's connect command prints each client's variant.
- Drop list writes from the key when the session should only read, and let the lookups feed fixtures and docs without touching a list.
- Add local business data and WHOIS to the test prompt when the companies you check are small or newly registered and firmographics alone come back thin.
- Chain a similar-companies call after the domain lookup to turn one customer into twenty candidates for list <name> in the same session.
Frequently asked questions
Does adding a row to list <name> need approval?
No. A list lives inside your workspace, so a list write is recorded in the audit trail and lands immediately. Pushing that list into a CRM, a sheet or an ad audience is the approval-gated step, and it needs a scope this key does not carry.
What does a lookup cost?
Company and person lookups are light, and the waterfall for an email or a phone bills only when a source answers. Each response carries its own credits, and the usage endpoint shows the workspace's running total, so a busy Cursor session is visible before it is surprising.
Can the agent verify a whole file of emails from Cursor?
Yes, by passing the addresses in one call, though a large file is better handled by the CLI in CI, where a threshold can fail the build. The tools are the same; the CLI adds the exit codes and the file handling.
Is my key stored in the config file?
Only if you choose the header route. Signing in from Cursor at connect time keeps the secret out of the file: the client holds a granted key that appears on the API-keys page named after Cursor, and revoking it there ends the session's access instantly.