People Data API over MCP: Giving AI Agents Contact Lookups

A people data API over MCP exposes lookups such as people search, email finding and enrichment as named tools that an AI agent can call directly, without custom glue code. It lets an agent answer “who should I contact at this company?” in the middle of a task, within whatever budget and rules you set.

What MCP changes

Traditionally you write code that calls a REST endpoint, parses JSON and passes the result to the next step. With the Model Context Protocol, described at modelcontextprotocol.io, a service publishes tools with names, inputs and descriptions, and the agent decides when to call them. The integration effort moves from code to configuration and instructions.

That matters for contact data because sales agents have a natural need for it. An inbound-lead agent that sees an unknown email wants to know who it is. An outbound agent working a target list needs names. Giving the agent a tool is quicker than building a pipeline, but it also moves control from your code to the agent’s judgement, which is why guardrails matter.

The BusinessMCP tool set

The BusinessMCP People Data API says it is available over REST and MCP, with the same name, input and price for each endpoint.

Function	MCP tool name	REST route	Price
People search	people_search	POST /api/hub/v1/people/search	$0.08 per item
Email finder	email_finder	POST /api/hub/v1/people/email-finder	$0.04 per call
Person enrichment	person_enrich	POST /api/hub/v1/people/enrich	$0.10 per call

All three are charged only when a result is found. Authentication is a bearer token. BusinessMCP’s comparison page adds that every API in its comparison now ships an official MCP server, so, in its words, agent access no longer separates vendors. That is a vendor’s observation, but it matches the direction of the market: the question is less “does it have MCP?” and more “what are its rules and prices?”.

Key takeaway: MCP makes access easy, so the differentiators become price, coverage and rules. Evaluate those first, then wire it up.

Guardrails an agent needs

Agents loop, retry and over-explore. Give them limits.

1. Prepaid balance as a cap. BusinessMCP’s model is prepaid from $10 with no subscription, which means a balance is a natural ceiling. Fund it modestly while you test.
2. Result limits. Search is billed per item, so instruct the agent to request a small number of results.
3. A budget rule. Tell the agent how many lookups it may run per task and to stop when it reaches the cap.
4. A purpose statement. The provider requires a declared purpose and logs each people call with it. Make the agent’s use case match what you declared.
5. Fallback behaviour. If a call returns nothing, the agent should record “not found” and move on rather than retry with variations.
6. No eligibility decisions. The terms prohibit use for credit, employment, insurance or housing decisions. Say so in the instructions.

Those rules mirror the controls in our pricing article for human-run workflows.

Which lookup should the agent use?

Write a short decision rule in the prompt. For example: “If you have a company domain but no person, call people search with at most three results. If you have a name and domain, call the email finder. If you have an email, call enrichment. If you only need to know what kind of company it is, call the company lookup instead.” The company lookup lives in the sibling company data API, at $0.02 per found call, and is cheaper than a person lookup for account-level questions.

Explaining each tool in a sentence helps the agent choose well; our guides to people search, the email finder and enrichment are good source material for those descriptions.

Data handling when the agent writes to your systems

The agent’s output ends up somewhere: a CRM, a message draft, a chat. Decide what it may store.

• Store only fields you will use, with a timestamp.
• Keep the email status label with each address.
• Do not let the agent paste personal details into public channels.
• Honour opt-outs across every system the agent touches.
• Remember the coverage limits. BusinessMCP never returns people located in the EU, EEA, UK or Switzerland, or people placed in California, Texas, Vermont or Oregon, so an agent should expect empty results for those leads, not keep searching other ways.

The regional reasoning is covered in people data and GDPR.

MCP or REST?

Use MCP when the caller is an agent that decides at runtime whether it needs a lookup. Use REST when your code makes a fixed, high-volume call in a batch, because explicit code is easier to test, rate-limit and audit. Many teams use both: batch enrichment through REST overnight, and agent-driven lookups through MCP during the day. With identical names, inputs and prices across the two, switching costs are low.

Testing an agent integration

If you would rather see the plain request shapes before you hand them to an agent, the Python example shows each call.

Before going live, run the agent on 20 leads with a tiny balance, then read its logs. Did it call the right tool? Did it stop when told? Did it spend more than expected? Did it record empty results properly? Adjust the instructions and repeat. The provider checklist lists the other questions to settle before production.

Documenting the setup for the next person

Agent integrations decay quietly when the one person who built them leaves. Keep a short runbook: which MCP tools are enabled, which key and balance they use, the budget rule in the agent’s instructions, and how to rotate the key. Record the declared purpose that you gave the provider, so that agent behaviour and declaration stay aligned.

If you also expose company-level checks, BusinessMCP’s Data API overview shows the other tools that sit under the same key, and its site includes an MCP config generator in its tools section for assembling client configuration. Check its output against your client’s own documentation before use, and test with a small balance. Review agent logs weekly for the first month, then monthly: look for repeated lookups of the same person, unexpected tool choices and any attempt to use results for something outside the declared purpose.