AI 비서에게 Crunchbase 데이터 접근을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 AI 비서는 Crunchbase에서 기업 검색, 기업 세부 정보, 자금 조달 정보, 인수 및 인사 데이터를 얻을 수 있습니다.
다양한 기준에 따른 기업 검색
특정 회사에 대한 자세한 정보를 얻으세요
기업을 위한 자금 조달 라운드 검색
수집 데이터 가져오기
회사와 관련된 사람을 검색하세요
Related MCP server: Coin MCP Server
Node.js(v16 이상)
Crunchbase API 키
저장소를 복제합니다.
지엑스피1
종속성 설치:
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 서버를 사용하는 방법에 대한 몇 가지 예는 다음과 같습니다.
샌프란시스코에서 AI 회사를 검색하세요:
{
"query": "AI",
"location": "San Francisco",
"limit": 5
}특정 회사에 대한 세부 정보를 얻으세요:
{
"name_or_id": "OpenAI"
}회사에 대한 자금 조달 라운드를 받으세요:
{
"company_name_or_id": "Anthropic"
}기술 회사의 CEO를 검색하세요:
{
"title": "CEO",
"limit": 10
}MIT
질문이나 지원이 필요하시면 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.
