The Crunchbase MCP Server provides access to Crunchbase data for AI assistants through a Model Context Protocol (MCP), enabling various company and people-related searches:
Search for companies based on criteria like name, location, category, founding date, and status
Retrieve detailed information about specific companies using their name or UUID
Get funding rounds for a specific company, with optional limits on results
Access acquisition data for a company, including both acquisitions made by and of the company
Search for people by name, job title, or company affiliation
Access trending companies data via resource URIs
Provides access to Crunchbase data including company search, detailed company information, funding rounds, acquisitions, and people data, enabling AI assistants to retrieve and analyze business information from the Crunchbase database.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Crunchbase MCP Server search for AI startups in San Francisco founded after 2020"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to Crunchbase data for AI assistants. This server allows AI assistants to search for companies, get company details, funding information, acquisitions, and people data from Crunchbase.
Search for companies based on various criteria
Get detailed information about specific companies
Retrieve funding rounds for companies
Get acquisition data
Search for people associated with companies
Related MCP server: Coin MCP Server
Node.js (v16 or higher)
A Crunchbase API key
Clone the repository:
git clone https://github.com/Cyreslab-AI/crunchbase-mcp-server.git
cd crunchbase-mcp-serverInstall dependencies:
npm installBuild the project:
npm run buildThe server requires a Crunchbase API key to function. You can obtain an API key by signing up for the Crunchbase API.
Set the API key as an environment variable:
export CRUNCHBASE_API_KEY=your_api_key_hereYou can use the included setup script to automatically configure the MCP server:
# Build the project first
npm run build
# Run the setup script
npm run setupThe setup script will:
Ask for your Crunchbase API key
Find your MCP settings file (or create a new one)
Add the Crunchbase MCP server to your settings
Alternatively, you can manually add it to your MCP configuration file:
{
"mcpServers": {
"crunchbase": {
"command": "node",
"args": ["/path/to/crunchbase-mcp-server/build/index.js"],
"env": {
"CRUNCHBASE_API_KEY": "your_api_key_here"
},
"disabled": false,
"autoApprove": []
}
}
}Start the server:
npm startFor development with automatic reloading:
npm run devThe server exposes the following tools:
search_companies - Search for companies based on various criteria
Parameters:
query (optional): Search query (e.g., company name, description)
location (optional): Filter by location (e.g., "San Francisco", "New York")
category (optional): Filter by category (e.g., "Artificial Intelligence", "Fintech")
founded_after (optional): Filter by founding date (YYYY-MM-DD)
founded_before (optional): Filter by founding date (YYYY-MM-DD)
status (optional): Filter by company status (e.g., "active", "closed")
limit (optional): Maximum number of results to return (default: 10)
get_company_details - Get detailed information about a specific company
Parameters:
name_or_id (required): Company name or UUID
get_funding_rounds - Get funding rounds for a specific company
Parameters:
company_name_or_id (required): Company name or UUID
limit (optional): Maximum number of results to return (default: 10)
get_acquisitions - Get acquisitions made by or of a specific company
Parameters:
company_name_or_id (optional): Company name or UUID
limit (optional): Maximum number of results to return (default: 10)
search_people - Search for people based on various criteria
Parameters:
query (optional): Search query (e.g., person name)
company (optional): Filter by company name
title (optional): Filter by job title
limit (optional): Maximum number of results to return (default: 10)
The server also exposes the following resources:
Trending Companies - List of trending companies on Crunchbase
URI: crunchbase://trending/companies
Company Details - Detailed information about a specific company
URI Template: crunchbase://companies/{name}
Company Funding Rounds - Funding rounds for a specific company
URI Template: crunchbase://companies/{name}/funding
Company Acquisitions - Acquisitions made by or of a specific company
URI Template: crunchbase://companies/{name}/acquisitions
Here are some examples of how an AI assistant might use this MCP server:
Search for AI companies in San Francisco:
{
"query": "AI",
"location": "San Francisco",
"limit": 5
}Get details for a specific company:
{
"name_or_id": "OpenAI"
}Get funding rounds for a company:
{
"company_name_or_id": "Anthropic"
}Search for CEOs at tech companies:
{
"title": "CEO",
"limit": 10
}MIT
For questions or support, please contact: contact@cyreslab.ai
Get acquisitions made by or of a specific company
| Name | Required | Description | Default |
|---|---|---|---|
| company_name_or_id | No | Company name or UUID | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description lacks details on permissions, rate limits, pagination, error handling, or what the return format looks like. It doesn't disclose whether this is a safe operation or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with two parameters. It lacks information on behavioral traits, return values, error conditions, and usage context, which are critical for an AI agent to invoke this tool correctly without structured guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('company_name_or_id' and 'limit') adequately. The description adds no additional parameter semantics beyond what's in the schema, such as format examples, constraints, or usage tips, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('acquisitions'), specifying the scope as 'made by or of a specific company'. It distinguishes from sibling tools like 'get_company_details' or 'get_funding_rounds' by focusing on acquisitions, but doesn't explicitly differentiate in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_companies' or 'search_people', nor does it specify prerequisites, exclusions, or contextual triggers for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific company
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_id | Yes | Company name or UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't mention authentication needs, rate limits, error handling, or what format the 'detailed information' returns. This leaves significant gaps for a tool that presumably queries external data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without fluff. It's appropriately sized for a simple lookup tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that fetches 'detailed information'. It doesn't explain what details are returned, potential limitations, or how it differs from sibling tools. For a data retrieval tool with external dependencies, this leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the single parameter 'name_or_id' as 'Company name or UUID'. The description adds no additional meaning about the parameter (e.g., examples, formatting, or how it's used), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific company'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_companies' or specify what constitutes 'detailed information' versus what other tools might provide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_companies' or 'get_acquisitions'. The description implies it's for retrieving details about a known company, but it doesn't specify prerequisites (e.g., needing the company name/UUID) or exclusions (e.g., not for searching).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get funding rounds for a specific company
| Name | Required | Description | Default |
|---|---|---|---|
| company_name_or_id | Yes | Company name or UUID | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral traits like whether this is a read-only operation, what happens with invalid inputs, rate limits, authentication requirements, or what the return format looks like. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for this simple tool and gets straight to the point with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 2 parameters, the description is insufficiently complete. It doesn't explain what format the funding rounds data will be returned in, what fields to expect, whether there's pagination, or any error conditions. The agent would need to guess about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'funding rounds for a specific company', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_company_details' which might also provide funding information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_companies' or 'get_company_details'. It doesn't mention prerequisites, exclusions, or comparative advantages, leaving the agent to guess about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for companies based on various criteria
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (e.g., "Artificial Intelligence", "Fintech") | |
| founded_after | No | Filter by founding date (YYYY-MM-DD) | |
| founded_before | No | Filter by founding date (YYYY-MM-DD) | |
| limit | No | Maximum number of results to return (default: 10) | |
| location | No | Filter by location (e.g., "San Francisco", "New York") | |
| query | No | Search query (e.g., company name, description) | |
| status | No | Filter by company status (e.g., "active", "closed") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It states the tool searches but doesn't describe return format (e.g., list of companies with what fields), pagination behavior (implied by 'limit' parameter), error conditions, or performance characteristics. For a search tool with 7 parameters, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource. However, it could be more structured by explicitly listing key criteria or mentioning output expectations to improve usability without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the search returns (e.g., company names, IDs, summaries), how results are ordered, or handle cases like no matches. For a search tool with multiple filters, more context is needed to guide effective use, especially without annotations or output schema to fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'various criteria,' which loosely maps to the 7 parameters in the schema. However, with 100% schema description coverage, the schema already fully documents each parameter's purpose and format. The description adds no specific meaning beyond what's in the schema, such as explaining how parameters interact or providing examples beyond the schema's hints. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for companies based on various criteria' clearly states the action (search) and resource (companies), making the purpose understandable. However, it's vague about what 'various criteria' entails and doesn't differentiate from sibling tools like 'search_people' beyond the resource type. It's adequate but lacks specificity about scope or how it differs from other company-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention relationships with sibling tools like 'get_company_details' (for specific company info) or 'search_people' (for searching individuals), nor does it specify prerequisites or contexts for use. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for people based on various criteria
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Filter by company name | |
| limit | No | Maximum number of results to return (default: 10) | |
| query | No | Search query (e.g., person name) | |
| title | No | Filter by job title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Search') without detailing traits like whether it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it lacks front-loading of critical details like scope or differentiation from siblings, which could improve structure. It earns a 4 for brevity but not optimal information hierarchy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral constraints, leaving gaps for an AI agent. With 100% schema coverage for inputs, it partially compensates but fails to address output or usage context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage with clear descriptions for all 4 parameters (company, limit, query, title). It implies filtering by 'various criteria' but doesn't elaborate on syntax, combinations, or default behaviors. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Search for people based on various criteria', which is clear but vague. It specifies the verb ('Search') and resource ('people'), but lacks specificity about what 'people' means (e.g., employees, contacts, users) and how it differs from sibling tools like search_companies. It avoids tautology but doesn't provide enough detail to distinguish it from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'various criteria' but doesn't specify contexts, exclusions, or prerequisites. With sibling tools like search_companies available, there's no indication of when to choose search_people over them, leaving usage decisions ambiguous for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get_acquisitions, get_company_details, and get_funding_rounds target specific data types for a company, while search_companies and search_people handle broader searches. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun pattern with snake_case, using 'get_' for retrieval operations and 'search_' for broader queries. This uniformity enhances readability and predictability across the tool set.
With 5 tools, the server is well-scoped for a Crunchbase domain, covering key data retrieval and search functions. It is slightly lean but reasonable, as it includes core operations without unnecessary bloat, though additional tools like updates or deletions might be expected in a broader context.
The tools provide solid coverage for querying company and people data, including details, acquisitions, funding rounds, and searches. Minor gaps exist, such as lack of update/delete operations or tools for related entities like investors, but the core retrieval and search needs are well-met for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cyreslab-AI/crunchbase-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
