シームレスな Apollo.io API 統合を実現する強力な Model Context Protocol (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 機能を簡単に追加できます
# 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キーの生成
トークンは次の 2 つの方法で提供できます。
環境変数として:
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認証用の実際の API キーにapikey置き換えます。
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"
}人探し
人を検索するには、人検索エンドポイントを使用します。
パラメータ:
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
