Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona acceso a los datos de Crunchbase para los asistentes de IA. Este servidor permite a los asistentes de IA buscar empresas, obtener detalles de las mismas, información de financiación, adquisiciones y datos de personas de Crunchbase.
Búsqueda de empresas según diversos criterios
Obtenga información detallada sobre empresas específicas
Recuperar rondas de financiación para empresas
Obtener datos de adquisición
Búsqueda de personas asociadas a empresas
Related MCP server: Coin MCP Server
Node.js (v16 o superior)
Una clave API de Crunchbase
Clonar el repositorio:
git clone https://github.com/Cyreslab-AI/crunchbase-mcp-server.git
cd crunchbase-mcp-serverInstalar dependencias:
npm installConstruir el proyecto:
npm run buildEl servidor requiere una clave API de Crunchbase para funcionar. Puedes obtenerla registrándote en la API de Crunchbase .
Establezca la clave API como una variable de entorno:
export CRUNCHBASE_API_KEY=your_api_key_herePuede utilizar el script de configuración incluido para configurar automáticamente el servidor MCP:
# Build the project first
npm run build
# Run the setup script
npm run setupEl script de configuración hará lo siguiente:
Solicita tu clave API de Crunchbase
Encuentra tu archivo de configuración de MCP (o crea uno nuevo)
Añade el servidor Crunchbase MCP a tu configuración
Alternativamente, puede agregarlo manualmente a su archivo de configuración de 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": []
}
}
}Iniciar el servidor:
npm startPara desarrollo con recarga automática:
npm run devEl servidor expone las siguientes herramientas:
search_companies - Búsqueda de empresas según diversos criterios
Parámetros:
query (opcional): consulta de búsqueda (por ejemplo, nombre de la empresa, descripción)
location (opcional): Filtrar por ubicación (por ejemplo, "San Francisco", "Nueva York")
category (opcional): Filtrar por categoría (p. ej., "Inteligencia Artificial", "Fintech")
founded_after (opcional): Filtrar por fecha de fundación (AAAA-MM-DD)
founded_before (opcional): Filtrar por fecha de fundación (AAAA-MM-DD)
status (opcional): Filtrar por estado de la empresa (por ejemplo, "activo", "cerrado")
limit (opcional): número máximo de resultados a devolver (predeterminado: 10)
get_company_details - Obtenga información detallada sobre una empresa específica
Parámetros:
name_or_id (obligatorio): nombre de la empresa o UUID
get_funding_rounds - Obtener rondas de financiación para una empresa específica
Parámetros:
company_name_or_id (obligatorio): Nombre de la empresa o UUID
limit (opcional): número máximo de resultados a devolver (predeterminado: 10)
get_acquisitions - Obtener adquisiciones realizadas por o de una empresa específica
Parámetros:
company_name_or_id (opcional): Nombre de la empresa o UUID
limit (opcional): número máximo de resultados a devolver (predeterminado: 10)
search_people - Busca personas según varios criterios
Parámetros:
query (opcional): consulta de búsqueda (por ejemplo, nombre de la persona)
company (opcional): Filtrar por nombre de empresa
title (opcional): Filtrar por puesto de trabajo
limit (opcional): número máximo de resultados a devolver (predeterminado: 10)
El servidor también expone los siguientes recursos:
Empresas en tendencia : lista de empresas en tendencia en Crunchbase
URI: crunchbase://trending/companies
Detalles de la empresa : información detallada sobre una empresa específica
Plantilla de URI: crunchbase://companies/{name}
Rondas de financiación de empresas : rondas de financiación para una empresa específica
Plantilla de URI: crunchbase://companies/{name}/funding
Adquisiciones de empresas : adquisiciones realizadas por o de una empresa específica
Plantilla de URI: crunchbase://companies/{name}/acquisitions
A continuación se muestran algunos ejemplos de cómo un asistente de IA podría utilizar este servidor MCP:
Buscar empresas de IA en San Francisco:
{
"query": "AI",
"location": "San Francisco",
"limit": 5
}Obtenga detalles de una empresa específica:
{
"name_or_id": "OpenAI"
}Conseguir rondas de financiación para una empresa:
{
"company_name_or_id": "Anthropic"
}Búsqueda de directores ejecutivos en empresas tecnológicas:
{
"title": "CEO",
"limit": 10
}Instituto Tecnológico de Massachusetts (MIT)
Para preguntas o asistencia, comuníquese con: 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.
