Company Data API for AI Agents: Using MCP Tools Safely

To give an AI agent company data, either call a REST endpoint from the agent’s code or expose the same lookup as an MCP tool the model can call when a company question arises. Whichever you choose, add a spend cap, a cache and not-found memory so the agent cannot loop on paid calls.

Two ways to connect

REST from your code. Your orchestration decides when to enrich: after a signup, before drafting an email. The model sees only the result. This is the more predictable pattern and the easier one to cost.

MCP tool. The model decides. You register the tool, and when a user asks “what does acme.com do and how big are they?”, the assistant calls it. This is flexible and fits chat-based research, at the price of less control over call counts.

The BusinessMCP Company Data API page states that each endpoint exists as both a REST route and an MCP tool with the same name, inputs and price, and that the same key works from any MCP client such as Claude or Cursor. Its integration guide describes adding the endpoint via mcp-remote for Claude Desktop or Cursor, or claude mcp add for Claude Code.

Tools that map to agent tasks

Agent task	Tool	Stated price (BusinessMCP)
“Who is this company?”	company_lookup	$0.02 when found
“Enrich this list”	company_bulk_lookup	$0.02 per item found
“Find logistics firms in Ohio”	company_search	$0.01 per item
“Is their site still up?”	company_website_status	$0.005 per call
“What email format do they use?”	email_pattern	$0.01 per call

Key takeaway: an agent with a paid tool needs a budget the way a script needs a timeout. Decide the maximum spend per run before connecting it.

Guardrails that matter

1. Prepaid balance as a ceiling. A prepaid account caps worst-case spend; the provider’s guide describes a prepaid model with a 402 on empty balance or spend limit.
2. Per-run call cap. Count tool calls in your harness and stop at a limit.
3. Memory of misses. Tell the agent, via instructions and a cache, that not-found is final for this session. The company tools charge only when found, but loops still burn time and context.
4. Normalise inputs. Ask the model to pass bare domains; clean them in a wrapper.
5. Idempotency keys for retries on REST calls.
6. Read-only tools. Company lookup does not change anything, which lowers risk compared with write tools.

Writing the tool description well

Models choose tools by their description. Be explicit: “Looks up a company by domain, URL or work email. Returns firmographics or found=false. Does not return people or personal emails. Do not call repeatedly for the same domain.” The limits in the description steer the model away from asking for data the tool cannot give.

Handling uncertainty in answers

Agents tend to fill gaps fluently. Instruct yours to report only returned fields and to say “not available” for anything else. The provider says it carries no revenue, funding or intent data, so an agent asked about funding should say the tool does not cover it rather than inventing a figure. This is where agents most often go wrong with enrichment, and a short instruction fixes much of it.

Typical agent workflows

• Account research. Look up a domain, summarise, then draft talking points grounded in returned fields.
• List building. Use company search with a limit, then review.
• Lead triage. Enrich a work email and route.
• Hygiene. Run website status checks across stale accounts.

Privacy and data handling

Company endpoints return company-level data only, according to the provider, with no personal email addresses. Even so, your agent’s prompts may include personal data supplied by users, so apply your own policies and review the vendor’s terms. This article is not legal advice.

Cost modelling for agents

Agent usage is spiky. Estimate calls per task, tasks per day and hit rate, then multiply by the price; add a margin. A caching layer by domain reduces cost a lot when many tasks touch the same accounts. Our pricing guide has the formula, and the CRM integration article covers the non-agent path.

Example agent session, step by step

Imagine a sales assistant connected to the company tools. A user types: “Prepare me for a call with acme-logistics.com.” A well-behaved agent does the following.

1. Calls the lookup tool with the bare domain.
2. If found, reads name, industry, size band, location and website status from the result.
3. Reports those facts, labelling the size as a band and noting the status date.
4. States clearly that revenue, funding and technology data are not available from this tool.
5. Offers to run company search for similar firms, and waits for a yes before spending more.

If the lookup returns found=false, the agent says so, suggests checking the spelling of the domain and does not guess. That behaviour comes from your tool description and system prompt, not from the API.

Testing the tool before you trust it

Before giving an agent access, try the same questions yourself with the free company lookup tool so you know what a correct answer looks like. Then run the agent on ten known domains and compare. Check three things: does it pass clean domains, does it report only returned fields, and does it stop after a miss? Fix instructions until all three hold.

Rate limits and concurrency

Agents can fan out. A research task that decides to look up fifty companies in parallel may hit limits. The provider’s guide lists 600 requests per minute per key, 3,000 per workspace and 60 per minute for bulk and per-unit tools. Put a queue or semaphore in the tool wrapper so concurrency never exceeds a safe number, and have it return a clear “rate limited, retry later” message the model can relay. For list enrichment, route to bulk lookup instead of looping single calls.

Logging for accountability

Log every tool call with the input domain, a timestamp, the outcome (found, not found, error) and the cost. Review the log weekly at first. It shows which tasks drive spend, whether the model is repeating itself and whether instructions need tightening. It also gives you an audit trail if someone asks why an agent stated a fact. Pair that with the real-time data article so everyone understands that returned facts are dated snapshots, not live feeds.

When not to use an agent

If the workflow is fixed, such as enrich every new signup, plain code is cheaper and safer than a model deciding each time. Reserve agent access for open-ended research where the question is not known in advance.