MCP Server for Business Data: Give Agents Live Leads

If you want an AI agent to fetch live local-business leads, the cleanest way to give it that capability is a tool it can call, and increasingly that tool is described through the Model Context Protocol (MCP). An MCP server exposes a set of tools, each with a name, a description, and a JSON Schema, that an agent runtime can discover and call on its own. This guide explains what MCP is, why a business-data and lead tool is a natural fit for the agent-first world, and how biz collect's OpenAPI 3.1 spec, llms.txt, stable JSON, and synchronous wait:true mode make it trivial to wrap as an MCP-style tool an agent can call to turn a city and keywords into structured, verified business records.

What MCP Is

The Model Context Protocol is an open standard for connecting AI agents to external tools and data. Instead of every application inventing its own way to hand capabilities to a model, MCP defines a common interface: a server advertises a list of tools, and a client (the agent runtime) discovers them, sees their schemas, and calls them during a conversation or task.

The important part for tool builders is what a tool definition contains. Each tool an MCP server exposes has three things:

• A name, a stable identifier the agent uses to invoke it, such as search_local_businesses.
• A description, natural-language text that tells the model what the tool does and, critically, when to call it.
• An input_schema, a JSON Schema describing the arguments, their types, and which are required.

That is the same shape used for tool definitions across modern agent runtimes. When an agent decides a task needs external data, it reads the available tool descriptions, picks the right one, fills in arguments that satisfy the schema, and calls it. The runtime executes the call, returns the result, and the model continues. MCP standardizes how that catalog of tools is published and transported (commonly over a Streamable HTTP endpoint), so a single server can serve many different agents.

If you want the conceptual definition on its own, the glossary entry for MCP server covers it. The official protocol documentation lives at modelcontextprotocol.io.

Why a Business-Data Tool Belongs in the Agent Stack

Language models are good at planning, interpreting intent, and formatting results. They are not a live database of local businesses, and they should not be treated as one. Ask a model to "list dentists in Austin" from memory and you get plausible-looking text, not operational data, often with invented names, stale addresses, and hallucinated phone numbers.

A lead and business-data tool fixes exactly this gap. It gives the agent a source of truth for two things models cannot reliably produce on their own:

• Discovery. Which businesses actually exist in a place, right now, matching a category.
• Enrichment. The verifiable contact data for each one: website, phone, address, and emails extracted from the business's own site.

This is the textbook case for tool use. The model handles the conversation, decides what to search for, validates and scores the results, and routes them somewhere useful. The tool handles deterministic execution and returns stable records. Separating those responsibilities is what makes an agent testable, cheaper to run, and safe to trust, because the data does not depend on the model's imagination. The companion post on building an AI lead generation agent walks through that planner-tool-validation-writer architecture in depth. If you are choosing where that live data should come from, see how the Google Places API, a scraper, and a business data API compare.

The reason this matters more every month is that "agent-first" is becoming a real distribution channel. People increasingly ask an assistant to do the work rather than opening a dashboard. A business-data product that is easy for an agent to call is a product that shows up inside those workflows. The goal, in our words, is that users like the app and AI is in love with it.

What Makes an API Trivially Agent-Callable

Not every API is pleasant to wrap as an agent tool. The ones that are share a few properties, and biz collect was built around them deliberately.

1. A precise OpenAPI 3.1 specification

biz collect publishes an OpenAPI 3.1 spec describing every endpoint, parameter, and response field. This is the single most important enabler for agent tooling, because many runtimes and MCP server frameworks can ingest an OpenAPI document and generate tool definitions from it automatically. The spec is the contract: parameter types, required fields, and response shapes are all machine-readable, so a generated tool's input_schema matches the real API without anyone hand-writing it. Start at the API docs for the spec and endpoint reference.

2. An llms.txt that points agents at the truth

biz collect serves an llms.txt file, a simple, agent-readable index that tells a model where the important documentation lives. When an agent or an agent-building developer lands on the domain, llms.txt is a fast, low-token way to discover the API surface, the docs, and how the search-and-poll lifecycle works, without crawling marketing pages. It is a small file with an outsized effect on how easily an agent can orient itself.

3. A stable, predictable JSON shape

An agent tool is only as reliable as the data it returns. biz collect returns the same field names and structure on every call: each business carries name, address, phone, website, and a deduped emails array. Stable fields mean the model (and your validation code) can depend on them without defensive parsing, and the same tool definition keeps working as the product grows. Deduplication happens before the response leaves the API, so the agent never has to clean up the same address three times.

4. A synchronous wait:true mode

This is the detail that makes a single clean tool possible. By default biz collect is asynchronous: you POST a search, get a job_id, and poll /api/v1/jobs/:id until the job completes, which is the right model for large jobs and for no-code tools that loop. But asking a model to manage a poll loop adds turns, tokens, and failure modes.

With wait:true, the search request blocks until the job finishes and returns the results in the same response. For an agent, that collapses the entire create-poll-read lifecycle into one tool call. The model calls one tool, gets enriched leads back, and moves on, no job IDs, no polling state, no loop to reason about. For larger searches you can still use the async path, but for the typical agent request the synchronous mode is what keeps the tool definition simple.

Together these four properties mean wrapping biz collect as an MCP tool is mostly a matter of pointing a generator at the OpenAPI spec, or writing one small handler around the wait:true endpoint. The how biz collect works page shows the request lifecycle, and the integrations page lists the surfaces it plugs into.

An Example Tool Definition

Here is what a single search tool looks like, expressed as a JSON Schema tool definition, the same shape an MCP server would advertise and an agent runtime would consume. Note how the description states when to call the tool, which measurably improves how reliably an agent reaches for it:

{
  "name": "search_local_businesses",
  "description": "Search for local businesses in a city or area and return structured records with website, phone, address, and deduped contact emails. Call this whenever the user asks to find, list, or collect businesses in a place by category (for example 'dentists in Austin' or 'roofing contractors near Denver'). Returns verified data, not estimates, so prefer it over answering from memory.",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City, region, postal code, or address to search around."
      },
      "keywords": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Business categories or search phrases, such as 'dentist' or 'roofing contractor'."
      },
      "radius_km": {
        "type": "number",
        "description": "Search radius in kilometers."
      },
      "scrape_emails": {
        "type": "boolean",
        "description": "Whether to extract deduped contact emails from each business website."
      },
      "wait": {
        "type": "boolean",
        "description": "If true, block until results are ready and return them in one response instead of an async job_id."
      }
    },
    "required": ["location", "keywords"]
  }
}

The handler behind this tool is small. It POSTs the arguments to /api/v1/search with wait:true, and returns the structured businesses array. No polling, no state machine. The agent receives records like this:

{
  "businesses": [
    {
      "name": "Example Dental Studio",
      "address": "123 Main St, Austin, TX 78701",
      "phone": "+1 512-555-0101",
      "website": "https://exampledentalstudio.com",
      "emails": ["hello@exampledentalstudio.com", "office@exampledentalstudio.com"]
    }
  ]
}

For a comprehensive description of the parameters and response fields, the OpenAPI reference in the docs is the source of truth, and a generated MCP tool will match it field for field.

The Agent Loop With a Live Data Tool

With the tool defined, the agent loop is straightforward. A typical request and the agent's internal trajectory look like this:

1. User: "Find independent law firms within 15 km of Zurich and collect their emails."
2. Agent plans: location = "Zurich, Switzerland", keywords = ["law firm"],
   radius_km = 15, scrape_emails = true, wait = true.
3. Agent calls search_local_businesses with those arguments.
4. The tool handler POSTs to /api/v1/search?wait=true and returns the businesses array.
5. Agent validates: required fields present, results match the requested category.
6. Agent filters: keep records with an email when email outreach is the goal,
   keep phone-bearing records otherwise.
7. Agent writes approved records to the CRM, a sheet, or a webhook, or summarizes them.

A few practices keep this loop robust:

• Let the runtime call the tool; do not ask the model to "remember" results. The tool result enters the context as data the model reasons over, not as something it has to reconstruct.
• Keep the tool surface narrow and explicit. One well-described search tool beats five overlapping ones. If you need a job-status tool for the async path, add it separately and keep its schema tight.
• Validate before acting. Even with stable fields, confirm the records suit the next action and dedupe against your own systems using normalized domains, phones, and addresses. The glossary entry on data enrichment covers what enrichment does and does not guarantee.
• Gate side effects. Collecting data and sending outreach are different systems. Require approval before first contact, respect suppression lists, and log what the agent did. This is not legal advice; compliance with the GDPR, the Swiss FADP, and applicable U.S. privacy laws is your responsibility.

For agents that run inside no-code tools rather than a code runtime, the same create-and-read shape applies as visual steps. The n8n lead generation workflow shows the async version of this loop as nodes, which is the right pattern when you want a long-running job rather than a single synchronous call.

Async vs Synchronous: Picking the Right Mode

The choice between the async job model and wait:true is the one design decision worth getting right for an agent.

• Use wait:true for interactive agent requests. When a user is waiting on an answer and the search is a normal size, one synchronous call is the cleanest experience: one tool, one result, no polling logic in the prompt. This is the default recommendation for an MCP-style search tool.
• Use the async job model for large or background work. When the search is broad, when you are running many searches in a batch, or when the work happens on a schedule without a human waiting, the job_id plus poll pattern is more robust and lets the agent (or your orchestration) do other things while the job runs. Pair it with a second tool that checks job status, or with a webhook so the agent is notified on completion instead of polling.

Both modes hit the same search engine and return the same stable record shape, so you can expose both as tools and let the agent (or your design) choose based on the request. The honest tradeoff is latency versus simplicity: wait:true holds the connection open until results are ready, while the async path returns immediately and shifts the waiting into polling. For most agent conversations, the synchronous path wins on developer and model simplicity.

Being Honest About What the Tool Returns

An agent tool is only trustworthy if it is honest about coverage, so the same caveats that apply to website email extraction apply here.

• Email coverage is partial. Some businesses publish only a contact form, and some render their address as an image. Those records come back with a website and phone but no email, which is accurate, not a bug. Build the agent's filtering around "records with an email when email is required" rather than assuming every business has one.
• The data reflects what is public. biz collect returns verified contact data extracted from live sources and the businesses' own websites. It does not invent fields to fill gaps, which is exactly the property that makes it safe to hand to a model.
• Other capabilities are described fairly. Plenty of tools can be wrapped for agents; what makes a business-data tool easy is the combination of a precise OpenAPI spec, a stable JSON shape, a synchronous mode, and llms.txt. Any API with those properties is pleasant to wrap; biz collect simply ships all four.

That honesty is what lets an agent act on the results without a human re-checking every record, which is the entire point of giving an agent a real data tool.

Start Building

Giving an AI agent live business data does not require a bespoke integration. It requires a tool with a clear name, a description that says when to call it, and a schema that matches a real API, plus a backend that returns stable, verified records. biz collect provides the backend: an OpenAPI 3.1 spec you can generate tools from, an llms.txt that orients agents fast, a stable JSON response, and a wait:true mode that turns the whole search-and-enrich lifecycle into one synchronous tool call.

Define one search_local_businesses tool, point it at the wait:true endpoint, and your agent can turn a city and a category into enriched, deduped local-business leads in a single round trip. It is free to start with 200 signup credits and no credit card, which is enough to build the tool, wire it into your runtime, and watch an agent call it end to end.

Open the API docs for the OpenAPI spec, review the integrations, check the pricing, and give your agent a live business-data tool today.