Apollo.io API와의 원활한 통합을 위한 강력한 모델 컨텍스트 프로토콜(MCP) 서버 구현으로, 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 기능을 쉽게 추가할 수 있습니다.
지엑스피1
서버에는 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-authAUTH_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 통합 도구를 제공합니다.
사람_풍요로움
People Enrichment 엔드포인트를 사용하여 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"
}사람 검색
사람 검색 엔드포인트를 사용하여 사람을 찾으세요
매개변수:
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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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
