MCP Crunchbase: When Your Agent Needs Tools, Not Just an API

An MCP Crunchbase tool raises one question almost immediately: why not call the REST endpoint the way the rest of the pipeline already does? Usually the answer is both, for different callers. A backend job that runs the same lookup on a schedule already knows when to call. An agent that realises mid-conversation that it needs a company's funding history has to discover the capability and decide to use it. The protocol matters less than who decides when the call happens.

The short version

• —The claim: REST and MCP can wrap the same Crunchbase lookup and return the same data. What differs is the caller: a developer who chose the call in advance, or an agent that chooses it mid-task.
• —Use MCP when the need for a lookup shows up unpredictably inside an agent's reasoning. Use REST when your code already knows exactly where the lookup belongs.
• —Who it is for: teams wiring a Crunchbase company lookup into an agent, and teams deciding which of their capabilities to expose as tools.
• —Cost: 15 points per successful lookup, which is $15 per 1,000, and a company that cannot be found is not billed. The Crunchbase company source page is the reference for exact fields, request shape and prices.

Who decides when the call happens

REST is a way to call a capability you already know about, at a point in your code where you already decided the call belongs. You write the request, you know the shape of the response, and the call happens because your code says so. MCP is a different layer: a way for an application to discover which capabilities are available and invoke one without the calling code having been written for that specific capability.

That distinction is not about which is more modern or more capable. A REST endpoint and an MCP tool can wrap exactly the same logic and return exactly the same data. The only variable is who is deciding.

A fixed pipeline: call REST directly

Take a pipeline that enriches every new vendor record with funding data the moment the record is created. It knows exactly when the lookup belongs: right after creation, every time. Calling the REST endpoint from the pipeline's own code is the natural fit. The call count is predictable, the cost can be budgeted, and the failure mode is easy to reason about, because the call either succeeds or it does not at a moment you already know about.

A due-diligence agent: reach for the tool

Now take an agent working through a compound question: verify this counterparty, check its funding history, flag anything inconsistent. It does not know which lookups it will need until it is partway through reasoning. It might need the Crunchbase profile or it might not, depending on what the first steps surface. Exposing the lookup as an MCP tool lets the agent discover it and reach for it exactly when its reasoning says so, a decision no developer scripted in advance.

Both callers reach the same data in the same response shape. Only the layer that decided the call changed. Either way, the profile is read from the source at the moment of the call rather than served from a stored copy, which is the main way this differs from buying the same funding data from a stored B2B contact and company database.

A conversation: an unpredictable trigger

A third case shows where REST alone gets awkward. A sales or support agent is talking with a prospect about pricing, and the prospect mentions their company by name partway through. Nothing about that moment is schedulable, so a fixed pipeline has no natural place for a lookup.

With only REST, you either run a lookup on every conversation, wasting calls on those where no company came up, or you write separate logic that watches the transcript for company names and triggers the call, and then keep that logic in sync with the agent's own judgment. With the same capability exposed as the run_crunchbase_company tool, the agent's reasoning does the detection implicitly: when a name surfaces and funding context would help answer the question, it calls the tool in the same step that noticed the name mattered.

REST and MCP

The same lookup is reachable both ways, from the same account, with the same inputs and the same response. Over MCP the tool is named run_crunchbase_company; the REST path is run-crunchbase-company, with a hyphen where the tool name has an underscore. Once an agent's host is connected to the hosted MCP server at https://mcp.neuralverge.ai/mcp, a call looks like this:

{
  "tool": "run_crunchbase_company",
  "arguments": { "url": "https://www.crunchbase.com/organization/acme-oy" }
}

For connection steps in each client, see the MCP setup walkthrough rather than repeating it here. The tool takes one argument, url, which must be a Crunchbase company URL, not a name or domain. It answers synchronously with the same shape a direct POST to https://api.neuralverge.ai/functions/v1/run-crunchbase-company returns: a session_id, kind set to crunchbase_company, the url echoed back, a readable human Markdown summary, and a machine object holding the structured company record. The values below are placeholders to show the shape:

{
  "session_id": "…",
  "kind": "crunchbase_company",
  "url": "https://www.crunchbase.com/organization/acme-oy",
  "human": "**Acme Oy** — Helsinki, Finland. Founded …",
  "machine": {
    "total_items": 1,
    "company": {
      "name": "Acme Oy",
      "legal_name": "Acme Oy",
      "permalink": "acme-oy",
      "website": "https://acme.example",
      "locations": [
        { "name": "Helsinki", "type": "city" },
        { "name": "Finland", "type": "country" }
      ],
      "founded": "…",
      "operating_status": "…",
      "employee_range": "…",
      "founders": [{ "name": "…", "permalink": "…" }],
      "funding_rounds": [{ "name": "…", "announced_on": "…", "investment_type": "…" }],
      "total_funding_usd": "…",
      "ipo_status": "…"
    }
  }
}

The company record covers more than funding. In groups:

• —Identity and contacts: name, legal name, description and summary, website, social links, contact email and locations.
• —Size and status: founding date, operating status, company type, employee range and rank.
• —People: founders, key people with titles and start dates, and board members and advisors.
• —Funding: total funding in US dollars, number of rounds and investors, funding rounds with announcement date and type, investors with the round they appear on, and current valuation where listed.
• —Corporate events: acquisitions, the acquirer if there is one, sub-organizations and IPO status.
• —Dated news notes: leadership changes, layoffs, legal proceedings and product launches.

Industries and categories come back as their own lists. Nothing about the data depends on which transport carried the request. The tool definition is just a name, a description and a set of arguments that an agent can match against the question it is trying to answer, with no integration code written for this lookup in this application.

What adding MCP changes

Adding MCP to a capability that already has a REST endpoint does not mean building a second version of the logic. It means wrapping the same call with a discoverable description: a name, a summary of what it does, and the parameters it takes. Every source in the source catalog is exposed this way, as a thin wrapper of its REST endpoint, and so are Search and AI extraction. AI research is the exception: it runs over REST only.

For company and contact data, that means an agent can reach far more than funding through one connection: corporate registry records through dedicated registry tools, email and phone enrichment, and LinkedIn people and company search, each returning typed JSON and a session id you can trace later. Full connection details are at docs.neuralverge.ai.

Why the tool description matters

A REST endpoint's shape is documented once, read by a developer, and encoded into fixed calling code. An MCP tool's description is read by an agent, in the moment, to decide whether this tool is the right one for the question in front of it. A vague description risks the agent skipping a useful tool, or reaching for it on the wrong kind of question. For this lookup, the description should say what the tool needs (a Crunchbase company URL), what it returns (funding, people and firmographics for one company), and when it is not the right choice (the agent has no Crunchbase URL, or needs a list of companies rather than one profile).

Why "just use MCP everywhere" is the wrong instinct

Once MCP is available it is tempting to expose every capability through it and treat REST as the legacy option. That undersells what a fixed pipeline has going for it: predictability. A pipeline that calls a REST endpoint at a known point has a call count you can predict, a cost you can budget and a failure mode you can reason about. An agent deciding for itself whether to reach for a tool does not have that by construction. That is the trade that makes MCP valuable for genuinely dynamic decisions and unnecessary overhead for decisions that were never dynamic.

The practical rule: if a person could predict, in advance, every point in a workflow where a lookup belongs, write a REST call into the pipeline. If the workflow has to discover mid-task that it needs a specific piece of information, that is the problem MCP is built for.

Where teams end up using both

• —One product, two doors. The source catalog is reachable over REST for fixed pipeline integrations and over MCP for agent-driven use, with the same response shape either way.
• —A pipeline with an agent layered on top. Scheduled and triggered logic calls REST directly; an agent handling exceptions or open-ended requests reaches for the same capabilities over MCP.
• —Migrating toward autonomy. A team that starts with a scripted pipeline and gradually hands decisions to an agent does not rebuild the capability. It adds an MCP-accessible wrapper as the decision layer changes.
• —Deliberate calls. Because an MCP tool is only called when an agent decides it is needed, it avoids running a lookup on every record regardless of whether that record needed one. The flip side is that an agent can also call it more often than you expected, so watch the session history.

Which transport fits which situation

Cost and limits

The Crunchbase company source costs 15 points per successful lookup, which is $15 per 1,000. A company that cannot be found is not billed. The price is the same over REST and MCP, because the tool is a wrapper of the endpoint, so the transport never changes what a lookup costs.

A few limits are worth planning around:

• —The input is a URL. The tool does not take a company name or domain. An agent that only has a name needs a step that finds the Crunchbase URL first, such as a search.
• —One profile per call. It returns one company record, not a list of companies matching criteria.
• —Fields can be empty. Not every profile lists every field, such as valuation, so handle missing values rather than assuming the example shape is always full.
• —Agents can over-call. An agent that decides for itself can run the same lookup repeatedly. Check the call history after a test run and tighten the tool description if it is calling more than it needs to.

Check the docs for how other calls, such as AI research, are billed.

How to decide

Run through these questions for each capability before exposing it over MCP:

• —Does something need to decide dynamically whether to call this, or is the calling logic already fixed? A fixed pipeline does not need MCP just because the option exists.
• —Would an agent plausibly need this mid-task? Due-diligence checks, counterparty verification and conversations where a company name can appear at any point are the strongest cases.
• —Is the tool description clear enough for an agent to know when to use it? This is the MCP-specific failure mode REST does not have.
• —Does the capability return the same shape either way? If REST and MCP differ, you maintain two integrations instead of one.
• —Are you exposing it because an agent needs to discover it, or by default? A capability only ever called at one fixed point gains little from being discoverable too.
• —What happens when there is no profile? Decide whether an empty result routes to a lower-touch path, and test with a company you know is missing.

The best test is to build one real agent workflow that might need the lookup, then watch whether the agent actually reaches for it. That tells you more than reasoning about it in the abstract.

Frequently asked questions

Is MCP meant to replace REST entirely?

No. They solve different problems. REST is a way to call a capability; MCP is a way for an application to discover and connect to capabilities it does not already know about in advance. Most real systems use both for different parts of the same pipeline.

Does exposing a capability over MCP change what it does?

No. The underlying capability, and the data it returns, stays identical. What changes is who decides when to call it: a developer, in code written in advance, or an agent, deciding for itself mid-task.

If I already call a REST endpoint directly, do I need to add MCP too?

Only if something in your system needs to decide dynamically whether to reach for that capability, typically an autonomous agent. A fixed pipeline that already knows when a lookup belongs has no need for MCP just because the option exists.

Does MCP add latency compared to calling REST directly?

There is a discovery step the first time a client connects to a server, but the invocation itself is a similar request-response exchange to a REST call. The larger latency difference in practice usually comes from an agent's own reasoning about whether to call a tool, not from the protocol itself.

How do I decide which of a product's capabilities to expose over MCP?

Start with the capabilities an agent would plausibly need to reach for dynamically, mid-task, rather than exposing everything by default. A capability only ever called at one fixed point in a pipeline does not gain much from being MCP-accessible too.

Does an MCP Crunchbase tool return different data than the REST endpoint?

No. NeuralVerge's run_crunchbase_company MCP tool wraps the same underlying Crunchbase company source as the REST endpoint and returns the identical structured response. Only the transport and who decides when to call it differ.

Is NeuralVerge's MCP coverage available for every data source at once?

Yes. Search, AI Extract and every data source, Crunchbase included, are tools on NeuralVerge's hosted MCP server, each a thin wrapper of its REST endpoint with the same inputs and outputs. AI research runs over REST only.