Una potente implementación de servidor de Protocolo de contexto de modelo (MCP) para una integración perfecta de la API de Apollo.io, que permite que los asistentes de IA interactúen con los datos de Apollo.io.
Este servidor MCP proporciona un conjunto completo de herramientas para interactuar con la API Apollo.io, lo que permite a los asistentes de IA:
Enriquecer datos para personas y organizaciones
Búsqueda de personas y organizaciones
Encuentre ofertas de trabajo para organizaciones específicas
Realice operaciones de Apollo.io sin salir de la interfaz de su asistente de IA
Related MCP server: apollo-io-mcp
Integración perfecta con IA : conecta tus asistentes de IA directamente a los datos de Apollo.io
Operaciones de API simplificadas : realice tareas comunes de Apollo.io mediante comandos de lenguaje natural
Acceso a datos en tiempo real : obtenga información actualizada de Apollo.io
Autenticación segura : utiliza la autenticación de token de API segura de Apollo.io
Diseño extensible : agregue fácilmente más capacidades de API de Apollo.io según sea necesario
# Clone the repository
git clone https://github.com/lkm1developer/apollo-io-mcp-server.git
cd apollo-io-mcp-server
# Install dependencies
npm install
# Build the project
npm run buildEl servidor requiere un token de acceso a la API de Apollo.io. Puedes obtenerlo de la siguiente manera:
Accediendo a su cuenta de Apollo.io
Navegando a Configuración > API
Generar una clave API
Puedes proporcionar el token de dos maneras:
Como variable de entorno:
APOLLO_IO_API_KEY=your-api-keyComo argumento de línea de comandos:
npm start -- --api-key=your-api-keyPara el desarrollo, cree un archivo .env en la raíz del proyecto para almacenar sus variables de entorno:
APOLLO_IO_API_KEY=your-api-key# Start the server
npm start
# Or with a specific API key
npm start -- --api-key=your-api-key
# Run the SSE server with authentication
npx mcp-proxy-auth node dist/index.jsEl servidor SSE utiliza el paquete mcp-proxy-auth para la autenticación. Para implementar la autenticación:
Instalar el paquete:
npm install mcp-proxy-authEstablezca la variable de entorno AUTH_SERVER_URL para que apunte al punto final de verificación de su clave API:
export AUTH_SERVER_URL=https://your-auth-server.com/verifyEjecute el servidor SSE con autenticación:
npx mcp-proxy-auth node dist/index.jsLa URL de SSE estará disponible en:
localhost:8080/sse?apiKey=apikeyReemplace apikey con su clave API real para la autenticación.
El paquete mcp-proxy-auth actúa como un proxy que:
Intercepta solicitudes a su servidor SSE
Verifica las claves API con su servidor de autenticación
Solo permite que las solicitudes autenticadas lleguen a su punto final SSE
Este servidor MCP está diseñado para funcionar con asistentes de IA compatibles con el Protocolo de Contexto de Modelo. Una vez en funcionamiento, el servidor expone un conjunto de herramientas que los asistentes de IA compatibles pueden usar para interactuar con los datos de Apollo.io.
El servidor expone las siguientes potentes herramientas de integración de Apollo.io:
enriquecimiento de personas
Utilice el punto final de enriquecimiento de personas para enriquecer los datos de una persona
Parámetros:
first_name (cadena, opcional): nombre de la persona
last_name (cadena, opcional): apellido de la persona
email (cadena, opcional): dirección de correo electrónico de la persona
domain (cadena, opcional): dominio de la empresa
organization_name (cadena, opcional): nombre de la organización
Ejemplo:
{
"first_name": "John",
"last_name": "Doe",
"email": "john.doe@example.com"
}enriquecimiento de la organización
Utilice el punto final de enriquecimiento de la organización para enriquecer los datos de una empresa
Parámetros:
domain (cadena, opcional): dominio de la empresa
name (cadena, opcional): nombre de la empresa
Ejemplo:
{
"domain": "apollo.io"
}búsqueda de personas
Utilice el punto final de búsqueda de personas para encontrar personas
Parámetros:
q_organization_domains_list (matriz, opcional): Lista de dominios de la organización en los que buscar
person_titles (matriz, opcional): lista de títulos de trabajo para buscar
person_seniorities (matriz, opcional): Lista de niveles de antigüedad para buscar
Ejemplo:
{
"person_titles": ["Marketing Manager"],
"person_seniorities": ["vp"],
"q_organization_domains_list": ["apollo.io"]
}búsqueda de organización
Utilice el punto final de búsqueda de organizaciones para encontrar organizaciones
Parámetros:
q_organization_domains_list (matriz, opcional): Lista de dominios de organización para buscar
organization_locations (matriz, opcional): lista de ubicaciones de organizaciones para buscar
Ejemplo:
{
"organization_locations": ["Japan", "Ireland"]
}ofertas de trabajo de la organización
Utilice el punto final Publicaciones de empleo de la organización para encontrar publicaciones de empleo para una organización específica
Parámetros:
organization_id (cadena, obligatoria): ID de la organización de Apollo.io
Ejemplo:
{
"organization_id": "5e60b6381c85b4008c83"
}El servidor está diseñado para ser fácilmente extensible. Para añadir nuevas funciones de la API de Apollo.io:
Agregue nuevos métodos a la clase ApolloClient en src/apollo-client.ts
Registra nuevas herramientas en el método setupToolHandlers en src/index.ts
Reconstruir el proyecto con npm run build
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Apollo.io, Protocolo de Contexto de Modelo, MCP, Asistente de IA, TypeScript, Integración de API, API de Apollo.io, Enriquecimiento de Personas, Enriquecimiento de Organizaciones, Búsqueda de Personas, Búsqueda de Organizaciones, Ofertas de Empleo, Herramientas de IA
Find employees of a company using company name or website/LinkedIn URL
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name | |
| website_url | No | Company website URL | |
| linkedin_url | No | Company LinkedIn URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Find employees') but lacks behavioral details such as what data is returned (e.g., employee names, roles, contact info), whether it's a read-only operation, potential rate limits, authentication needs, or error handling. This leaves significant gaps for an agent to understand the tool's behavior.
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 front-loads the core purpose ('Find employees of a company') and specifies input methods. There is no wasted text, making it highly concise and well-structured for quick understanding.
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 of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of employees, details), behavioral traits, or usage context relative to siblings. This leaves the agent under-informed for effective tool selection and invocation.
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 all parameters (company, website_url, linkedin_url) with descriptions. The description adds minimal value by mentioning input options but doesn't provide additional semantics like format examples, constraints, or how parameters interact (e.g., if multiple are provided). Baseline 3 is appropriate as 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 tool's purpose: 'Find employees of a company' with specific input options (company name or website/LinkedIn URL). It uses a clear verb ('Find') and resource ('employees of a company'), but doesn't explicitly differentiate from sibling tools like 'people_search' or 'organization_search', which might have overlapping functionality.
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 'people_search' or 'organization_search'. It mentions input options but doesn't specify scenarios, prerequisites, or exclusions for usage, leaving the agent to guess about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get email address for a person using their Apollo ID
| Name | Required | Description | Default |
|---|---|---|---|
| apollo_id | Yes | Apollo.io person ID |
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 states the tool 'Get email address', which implies a read-only operation, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error handling, or what happens if no email is found. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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: 'Get email address for a person using their Apollo ID'. It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
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 (a simple lookup with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., email string, error messages), behavioral aspects like permissions or limitations, or how it differs from sibling tools. For a tool with no structured data beyond the input schema, more context is needed to be fully helpful.
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. It mentions 'using their Apollo ID', which aligns with the 'apollo_id' parameter in the schema. Since schema description coverage is 100% (the parameter is fully described as 'Apollo.io person ID'), the baseline is 3. The description doesn't provide additional syntax, format details, or constraints, so it meets but doesn't exceed the baseline.
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: 'Get email address for a person using their Apollo ID'. It specifies the verb ('Get'), resource ('email address'), and key identifier ('Apollo ID'), making the action unambiguous. However, it does not explicitly differentiate this tool from sibling tools like 'people_enrichment' or 'people_search', which might also retrieve person-related data, so it doesn't fully distinguish from 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 doesn't mention sibling tools like 'people_enrichment' or 'people_search', nor does it specify prerequisites, such as needing an Apollo ID. The context is implied (use when you have an Apollo ID and want an email), but there's no explicit when/when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the Organization Enrichment endpoint to enrich data for 1 company
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Company domain | |
| name | No | Company name |
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 the tool enriches data but doesn't explain what 'enrich' entails (e.g., adding details like industry, size, location), whether it's a read-only or mutative operation, or any constraints like rate limits or authentication needs. This lack of detail makes it inadequate for a tool with potential complexity.
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 any fluff. It's front-loaded with the core action ('enrich data') and resource ('1 company'), making it easy to parse. Every word earns its place, achieving optimal 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 the lack of annotations and output schema, the description is incomplete for a data enrichment tool. It doesn't explain what enriched data is returned (e.g., company details, metrics), how results are structured, or any behavioral traits like error handling. For a tool that likely provides rich output, this leaves significant gaps in understanding its full context.
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 clear documentation for 'domain' and 'name'. The description adds no additional parameter semantics beyond implying it processes '1 company', which aligns with the schema but doesn't provide extra context like how parameters interact or which is prioritized. 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 clearly states the tool's purpose: 'enrich data for 1 company' using the Organization Enrichment endpoint. It specifies the verb ('enrich') and resource ('data for 1 company'), making the intent unambiguous. However, it doesn't differentiate from sibling tools like 'organization_search' or 'people_enrichment', which prevents 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. It doesn't mention when to prefer this over 'organization_search' for enrichment versus search, or over 'people_enrichment' for company versus individual data. There's no context about prerequisites, exclusions, or typical use cases, leaving the agent without operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the Organization Job Postings endpoint to find job postings for a specific organization
| Name | Required | Description | Default |
|---|---|---|---|
| organization_id | Yes | Apollo.io organization ID |
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 the tool 'finds' job postings, implying a read operation, but doesn't mention permissions, rate limits, pagination, or what the response includes. This leaves significant gaps for a tool with no output schema.
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 zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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. It doesn't explain what the tool returns (e.g., list of postings, metadata), error conditions, or behavioral traits. For a tool with 1 parameter and 100% schema coverage, it minimally covers purpose but lacks critical context for effective use.
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 the 'organization_id' parameter. The description adds no additional meaning about the parameter beyond implying it's for a 'specific organization', which is redundant with the schema. Baseline 3 is appropriate when 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 tool's purpose: 'find job postings for a specific organization' with a specific verb ('find') and resource ('job postings'). It distinguishes from siblings like 'organization_search' or 'employees_of_company' by focusing on job postings, but doesn't explicitly contrast them.
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 'organization_search' or 'people_search'. It mentions 'specific organization' but doesn't clarify prerequisites, exclusions, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the Organization Search endpoint to find organizations
| Name | Required | Description | Default |
|---|---|---|---|
| q_organization_domains_list | No | List of organization domains to search for | |
| organization_locations | No | List of organization locations to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it 'find organizations' without disclosing behavioral traits like whether this is a read-only operation, what permissions might be needed, rate limits, pagination behavior, or what the response format looks like. For a search tool with zero annotation coverage, this is insufficient.
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 sentence with no wasted words, making it appropriately concise. However, it's front-loaded with minimal information, which could be improved with more context, but it's not verbose or poorly structured.
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 search tool. It doesn't explain what 'find' entails, the return values, or how results are structured. With 2 parameters and no behavioral context, it should provide more guidance to be fully helpful.
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 with clear descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema. Baseline 3 is appropriate when 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 states the tool 'find organizations' which gives a basic purpose, but it's vague about what 'find' means (search by what criteria?) and doesn't distinguish it from sibling tools like 'organization_enrichment' or 'people_search'. It uses the generic verb 'find' rather than specifying the search mechanism.
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 about when to use this tool versus alternatives like 'organization_enrichment' or 'people_search'. The description doesn't mention any prerequisites, context, or exclusions for usage. It's a generic statement with no operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the People Enrichment endpoint to enrich data for 1 person
| Name | Required | Description | Default |
|---|---|---|---|
| first_name | No | Person's first name | |
| last_name | No | Person's last name | |
| No | Person's email address | ||
| domain | No | Company domain | |
| organization_name | No | Organization name | |
| linkedin_url | No | Person's LinkedIn profile URL |
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 the tool enriches data for one person but doesn't describe what 'enrich' entails (e.g., adding contact info, job history, social profiles), whether it requires authentication, rate limits, or what the output looks like. This is a significant gap for a tool with no annotations or output schema.
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 core function. It's appropriately sized for a tool with a clear purpose and well-documented schema, with zero wasted words or unnecessary elaboration.
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 (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'enrichment' means, what data is returned, or how parameters are used. For a data enrichment tool with multiple input options and no structured output documentation, this leaves significant gaps for the agent.
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 all 6 parameters with clear descriptions. The description adds no additional parameter semantics beyond implying these fields are used for enrichment. This meets the baseline of 3 when schema does the heavy lifting, but doesn't compensate with extra context like which parameters are most important or how they interact.
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: 'enrich data for 1 person' with the specific verb 'enrich' and resource 'person'. It distinguishes from siblings like 'employees_of_company' (multiple people) and 'get_person_email' (specific data point). However, it doesn't specify what 'enrich' means in terms of data types or sources, keeping it at 4 rather than 5.
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 when to choose this over 'people_search' (which might find multiple people) or 'organization_enrichment' (which enriches company data). There's no context about prerequisites or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the People Search endpoint to find people
| Name | Required | Description | Default |
|---|---|---|---|
| q_organization_domains_list | No | List of organization domains to search within | |
| person_titles | No | List of job titles to search for | |
| person_seniorities | No | List of seniority levels to search for |
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 none. It doesn't indicate whether this is a read-only operation, what authentication might be required, whether there are rate limits, what the typical response format looks like, or any other behavioral characteristics. The description is completely silent on these critical operational aspects.
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 extremely concise (just 7 words) but this brevity comes at the cost of being under-specified rather than efficiently informative. While it's front-loaded with the core function, it lacks the necessary detail to be genuinely helpful to an AI agent trying to understand when and how to use this tool effectively.
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 search tool with 3 parameters and no output schema, the description is inadequate. While the schema covers the parameters well, the description fails to explain what kind of results to expect, how results are structured, or any limitations of the search. With no annotations and no output schema, the description should provide more operational context about what this tool actually returns.
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?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in 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 'Use the People Search endpoint to find people' is tautological - it essentially restates the tool name 'people_search' with minimal additional information. While it indicates a search function, it lacks specificity about what kind of people search (e.g., professional contacts, employees, etc.) and doesn't distinguish it from sibling tools like 'employees_of_company' or 'people_enrichment'.
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. With sibling tools like 'employees_of_company', 'people_enrichment', and 'organization_search' available, there's no indication of what makes this tool distinct or when it should be preferred over those other options for finding people information.
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.0employees_of_companyget_person_emailorganization_enrichmentorganization_job_postingsorganization_searchpeople_enrichmentpeople_searchScored across 7 tools
Most tools have distinct purposes, but there is some potential overlap between organization_search and organization_enrichment, as both involve company data retrieval. However, their descriptions clarify that search is for finding organizations while enrichment is for augmenting data on a known company, which helps mitigate confusion. The other tools target clearly different resources like employees, emails, job postings, and people.
The naming follows a consistent snake_case pattern throughout, which is good. However, there is a minor inconsistency: most tools use a verb_noun format (e.g., organization_search, people_enrichment), but employees_of_company uses a noun_of_noun structure, deviating slightly from the pattern. This does not severely impact readability but is a noticeable deviation.
With 7 tools, the count is well-scoped for a sales intelligence or recruitment domain, covering key operations like searching and enriching data for both organizations and people. Each tool appears to earn its place without feeling excessive or sparse, aligning well with the server's apparent purpose of data enrichment and lookup.
The tool set provides solid coverage for core workflows in the domain, including search and enrichment for both organizations and people, plus specific functions like finding employees and emails. A minor gap is the lack of update or delete operations, but this is reasonable for a read-heavy enrichment server. The surface supports common agent tasks without obvious dead ends.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Your agent needs B2B contacts and the pipeline objects around them — find the company, find the person, get the email, then write it back where your team works. **What you can ask for** • "Find heads of engineering at Series-B SaaS companies in the Nordics, with emails." • "Enrich these companies with headcount, industry and funding." • "What roles is this company hiring for right now?" • "Create an account and a contact, then log this opportunity." • "Search our sequences for messages sent to this domain." **How to use it** Point any MCP client at https://mcp.aisa.one/apollo/mcp and sign in with OAuth — there is no key to create or paste. 54 tools: people and organisation search and enrichment, job postings, accounts, contacts, opportunities and their stages, custom fields, labels, notes, users, email accounts, sequence messages and phone-call search — reads and writes. **Why this rather than the source** The full object model, not just a search endpoint, so an agent can finish the job rather than hand you a CSV. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the person here, then ask the same agent what their company's traffic looks like or what they rank for — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/sales/mcp adds Similarweb and creator discovery around it.
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
