一个模型上下文协议 (MCP) 服务器，为 AI 助手提供 Crunchbase 数据的访问权限。该服务器允许 AI 助手从 Crunchbase 搜索公司，获取公司详情、融资信息、收购信息和人员数据。
根据各种标准搜索公司
获取特定公司的详细信息
检索公司融资轮次
获取采集数据
搜索与公司相关的人员
Related MCP server: Coin MCP Server
Node.js（v16 或更高版本）
Crunchbase API 密钥
克隆存储库：
git clone https://github.com/Cyreslab-AI/crunchbase-mcp-server.git
cd crunchbase-mcp-server安装依赖项：
npm install构建项目：
npm run build该服务器需要 Crunchbase API 密钥才能运行。您可以通过注册Crunchbase API来获取 API 密钥。
将 API 密钥设置为环境变量：
export CRUNCHBASE_API_KEY=your_api_key_here您可以使用附带的安装脚本自动配置 MCP 服务器：
# Build the project first
npm run build
# Run the setup script
npm run setup安装脚本将：
索取您的 Crunchbase API 密钥
找到您的 MCP 设置文件（或创建一个新的）
将 Crunchbase MCP 服务器添加到您的设置中
或者，您可以手动将其添加到您的 MCP 配置文件中：
{
"mcpServers": {
"crunchbase": {
"command": "node",
"args": ["/path/to/crunchbase-mcp-server/build/index.js"],
"env": {
"CRUNCHBASE_API_KEY": "your_api_key_here"
},
"disabled": false,
"autoApprove": []
}
}
}启动服务器：
npm start对于自动重新加载的开发：
npm run dev该服务器公开以下工具：
search_companies - 根据各种标准搜索公司
参数：
query （可选）：搜索查询（例如公司名称、描述）
location （可选）：按位置过滤（例如“旧金山”、“纽约”）
category （可选）：按类别过滤（例如“人工智能”、“金融科技”）
founded_after （可选）：按成立日期过滤（YYYY-MM-DD）
founded_before （可选）：按成立日期过滤（YYYY-MM-DD）
status （可选）：按公司状态过滤（例如“活跃”、“关闭”）
limit （可选）：返回的最大结果数（默认值：10）
get_company_details - 获取特定公司的详细信息
参数：
name_or_id （必填）：公司名称或UUID
get_funding_rounds - 获取特定公司的融资轮次
参数：
company_name_or_id （必填）：公司名称或 UUID
limit （可选）：返回的最大结果数（默认值：10）
get_acquisitions - 获取特定公司进行的收购
参数：
company_name_or_id （可选）：公司名称或 UUID
limit （可选）：返回的最大结果数（默认值：10）
search_people - 根据各种条件搜索人员
参数：
query （可选）：搜索查询（例如，人名）
company （可选）：按公司名称过滤
title （可选）：按职位过滤
limit （可选）：返回的最大结果数（默认值：10）
服务器还公开以下资源：
热门公司- Crunchbase 上的热门公司列表
URI： crunchbase://trending/companies
公司详情——有关特定公司的详细信息
URI 模板： crunchbase://companies/{name}
公司融资轮次- 特定公司的融资轮次
URI 模板： crunchbase://companies/{name}/funding
公司收购- 特定公司进行的收购
URI 模板： crunchbase://companies/{name}/acquisitions
以下是 AI 助手如何使用此 MCP 服务器的一些示例：
搜索旧金山的人工智能公司：
{
"query": "AI",
"location": "San Francisco",
"limit": 5
}获取特定公司的详细信息：
{
"name_or_id": "OpenAI"
}为公司获取融资轮次：
{
"company_name_or_id": "Anthropic"
}搜索科技公司的首席执行官：
{
"title": "CEO",
"limit": 10
}麻省理工学院
如有任何疑问或需要支持，请联系： 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_acquisitionsget_company_detailsget_funding_roundssearch_companiessearch_peopleScored across 5 tools
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.
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.
