MCP server

Sprouts MCP

The whole Sprouts business-data corpus as tools in any MCP client — nine tools, six prompts, eight resources, and inline cards, over one hosted URL per environment.

Use the whole Sprouts platform from Claude, Cursor, VS Code, Codex or any other MCP client, without writing a line of integration code. Paste one URL, and searching companies, finding look-alikes, enriching records, walking the affiliation graph and running deep research become tools your assistant calls for you.

The Sprouts MCP server puts the corpus behind the Model Context Protocol. Your API key does the metering exactly as it does for the raw HTTP API. It is a hosted server: there is nothing to install and nothing to run. Every client connects over Streamable HTTP to one URL.

Endpoint#

https://dashboard.sproutsdata.ai/mcp

That is the endpoint for this deployment. Every config snippet in this section is built from it, so anything you copy from these pages already points at the right place.

Sprouts runs more than one deployment, each with its own dashboard, its own data and its own billing:

  • An API key belongs to exactly one deployment. The endpoint above pairs with keys from this dashboard and no other.
  • A key from elsewhere fails as 401 auth.invalid_key: the same error as a revoked key, and nothing in it names the environment. When a config that worked stops working, check first that the endpoint and the key agree.
  • Integrating a different deployment? Read its own copy of these docs. The URL on this page is not the one you want.

What you get#

Use cases#

Prospecting from a conversation

You describe a target market in plain language. The assistant calls sprouts_search and sprouts_similar with the right parameters. Outcome: ranked companies and people in the conversation itself, with no request bodies written and no docs consulted, and every call metered on your key like any API call.

Enrichment inside an agent workflow

An agent you built processes accounts and needs firmographics mid-run. Add the server URL to its MCP configuration. Outcome: the agent looks up records with sprouts_entity_lookup as a step of its own plan, instead of you writing and maintaining an HTTP integration for it.

A warm path into an account

You want to know who you already know at a target company. The assistant calls sprouts_relationships with both sides named. Outcome: ranked people with the shared employer, school or overlapping tenure that connects them, and an honest match_confidence, so a name match never reads as an established relationship.

Deep research on demand

A question needs multi-step investigation, not one search. Ask for it, and the assistant starts a run with sprouts_research_run. Outcome: an asynchronous run that resumes by run_id, returns rows with named enrichment columns plus cited insights, and states its price before spending it. A run that fails or is cancelled costs nothing.

Running out mid-conversation

A call fails because the balance is empty, or you ask to buy more credits. The assistant calls sprouts_top_up. Outcome: a link to a Sprouts page where you sign in, choose an amount and pay in your browser. The tool charges nothing and takes no amount, so nothing the model says can decide what you are billed.

Versioning#

Several things version independently here, and only one of them is ours to break.

  • The data contract is v1. The tools adapt the same /v1 routes the HTTP API exposes, and changes within v1 are additive (see Versioning). A new field can appear in a tool result; an existing one does not change meaning.
  • Tool names are frozen. sprouts_search, sprouts_similar, sprouts_entity_lookup, sprouts_relationships, sprouts_research_run, sprouts_coverage, sprouts_usage, sprouts_feedback, sprouts_top_up. They live in saved client configs and cached registry manifests, machinery we cannot reach to update, so tools get added, never renamed.
  • The protocol revision is negotiated per session. The server accepts every revision the MCP SDK does and adapts to whichever one your client agrees on, so there is nothing to pin. The one visible difference is resource_link, a content type introduced in 2025-06-18: a client that negotiated an older revision is sent the record itself rather than a link it would silently drop. See oversized records.
  • Both ways of authenticating stay supported. A client that can set a header sends an sk_dsp_ key; a client that can only take a URL signs in over OAuth 2.1. Neither is a migration path away from the other, and adding OAuth changed nothing about the key path. See Connect a client.