强大的模型上下文协议 (MCP) 服务器实现，可实现无缝的 Apollo.io API 集成，使 AI 助手能够与 Apollo.io 数据进行交互。
该 MCP 服务器提供了一套与 Apollo.io API 交互的全面工具，允许 AI 助手：
丰富个人和组织的数据
搜索人员和组织
查找特定组织的招聘信息
无需离开 AI 助手界面即可执行 Apollo.io 操作
Related MCP server: apollo-io-mcp
无缝 AI 集成：将您的 AI 助手直接连接到 Apollo.io 数据
简化的 API 操作：通过自然语言命令执行常见的 Apollo.io 任务
实时数据访问：从 Apollo.io 获取最新信息
安全认证：使用 Apollo.io 的安全 API 令牌认证
可扩展设计：根据需要轻松添加更多 Apollo.io API 功能
# 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 build服务器需要 Apollo.io API 访问令牌。您可以通过以下方式获取：
前往你的Apollo.io 账户
导航至“设置”>“API”
生成 API 密钥
您可以通过两种方式提供令牌：
作为环境变量：
APOLLO_IO_API_KEY=your-api-key作为命令行参数：
npm start -- --api-key=your-api-key为了开发，请在项目根目录中创建一个.env文件来存储环境变量：
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.jsSSE 服务器使用mcp-proxy-auth软件包进行身份验证。要实现身份验证，请执行以下操作：
安装软件包：
npm install mcp-proxy-auth设置AUTH_SERVER_URL环境变量以指向您的 API 密钥验证端点：
export AUTH_SERVER_URL=https://your-auth-server.com/verify使用身份验证运行 SSE 服务器：
npx mcp-proxy-auth node dist/index.jsSSE URL 可在以下位置获取：
localhost:8080/sse?apiKey=apikey将apikey替换为您实际的用于身份验证的 API 密钥。
mcp-proxy-auth包充当代理：
拦截对 SSE 服务器的请求
根据您的身份验证服务器验证 API 密钥
仅允许经过身份验证的请求到达您的 SSE 端点
此 MCP 服务器旨在与支持模型上下文协议 (MCP) 的 AI 助手配合使用。运行后，服务器会公开一组工具，供兼容的 AI 助手使用，与 Apollo.io 数据进行交互。
该服务器公开了以下强大的 Apollo.io 集成工具：
人员充实
使用人员扩充端点来扩充 1 个人的数据
参数：
first_name （字符串，可选）：人的名字
last_name （字符串，可选）：人的姓氏
email （字符串，可选）：个人的电子邮件地址
domain （字符串，可选）：公司域
organization_name （字符串，可选）：组织名称
例子：
{
"first_name": "John",
"last_name": "Doe",
"email": "john.doe@example.com"
}组织丰富
使用组织丰富端点丰富 1 家公司的数据
参数：
domain （字符串，可选）：公司域
name （字符串，可选）：公司名称
例子：
{
"domain": "apollo.io"
}people_search
使用人员搜索端点来查找人员
参数：
q_organization_domains_list （数组，可选）：要搜索的组织域列表
person_titles （数组，可选）：要搜索的职位列表
person_seniorities （数组，可选）：要搜索的资历级别列表
例子：
{
"person_titles": ["Marketing Manager"],
"person_seniorities": ["vp"],
"q_organization_domains_list": ["apollo.io"]
}组织搜索
使用组织搜索端点查找组织
参数：
q_organization_domains_list （数组，可选）：要搜索的组织域列表
organization_locations （数组，可选）：要搜索的组织位置列表
例子：
{
"organization_locations": ["Japan", "Ireland"]
}组织职位发布
使用“组织职位发布”端点查找特定组织的职位发布
参数：
organization_id （字符串，必需）：Apollo.io 组织 ID
例子：
{
"organization_id": "5e60b6381c85b4008c83"
}该服务器设计为易于扩展。要添加新的 Apollo.io API 功能，请执行以下操作：
在src/apollo-client.ts中向ApolloClient类添加新方法
在src/index.ts中的setupToolHandlers方法中注册新工具
使用npm run build重建项目
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。
Apollo.io、模型上下文协议、MCP、AI 助手、TypeScript、API 集成、Apollo.io API、人员丰富、组织丰富、人员搜索、组织搜索、职位发布、AI 工具
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
