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.
Keys, a config snippet per client, and how to tell it worked.
What each of the nine does, what it costs, and how to pick between them.
The inline UI, which hosts render it, and what the text fallback carries.
The workflows and reference material that ship with the server.
Spend caps, topping up, rate limits, retry behaviour, and what each error means.
The same guide the server hands the model, as one page.
Endpoint#
https://dashboard.sproutsdata.ai/mcpThat 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#
Search, Similar Companies, Record Lookup, the relationship graph, deep research, coverage, usage, feedback and credit top-up. All nine are on by default.
Pre-built workflows a client can surface as slash commands: target lists, look-alikes, enrichment, warm intros, deep research, coverage checks.
Reference the model pulls only when it needs it: the agent guide, the error catalogue, live coverage, per-category fields and sorts, filter values, feedback tags.
In hosts that render MCP Apps, results from eight of the tools come back as interactive cards. Everywhere else the same answer arrives as text.
Use cases#
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.
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.
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.
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.
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/v1routes the HTTP API exposes, and changes withinv1are 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 in2025-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.