Сервер Model Context Protocol (MCP), который предоставляет доступ к данным Crunchbase для помощников ИИ. Этот сервер позволяет помощникам ИИ искать компании, получать данные о компаниях, информацию о финансировании, приобретениях и данные о людях из Crunchbase.
Поиск компаний по различным критериям
Получите подробную информацию о конкретных компаниях
Получить раунды финансирования для компаний
Получить данные о приобретении
Поиск людей, связанных с компаниями
Related MCP server: Coin MCP Server
Node.js (v16 или выше)
API-ключ Crunchbase
Клонируйте репозиторий:
git clone https://github.com/Cyreslab-AI/crunchbase-mcp-server.git
cd crunchbase-mcp-serverУстановить зависимости:
npm installСоздайте проект:
npm run buildДля работы сервера требуется ключ API Crunchbase. Вы можете получить ключ API, зарегистрировавшись на API Crunchbase .
Установите ключ API как переменную среды:
export CRUNCHBASE_API_KEY=your_api_key_hereВы можете использовать прилагаемый скрипт настройки для автоматической настройки сервера MCP:
# Build the project first
npm run build
# Run the setup script
npm run setupСкрипт установки выполнит следующие действия:
Запросите ваш ключ API Crunchbase
Найдите файл настроек 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 (необязательно): Фильтр по дате основания (ГГГГ-ММ-ДД)
founded_before (необязательно): Фильтр по дате основания (ГГГГ-ММ-ДД)
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
Вот несколько примеров того, как помощник на основе искусственного интеллекта может использовать этот сервер 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. Dates show when Glama detected each change.
v1.0.0get_acquisitionsget_company_detailsget_funding_roundssearch_companiessearch_peopleEach 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
