How do I use @louis030195/apollo-io-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@louis030195/apollo-io-mcp Find me CTOs at fintech startups in New York" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@louis030195/apollo-io-mcp

by louis030195

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@louis030195/apollo-io-mcp

MCP (Model Context Protocol) server for Apollo.io B2B sales intelligence API. Search for prospects, enrich contacts, and discover companies directly from Claude, ChatGPT, or any LLM that supports MCP.

💖 Support This Project

If you find this MCP server useful, please consider supporting its development!

👉 Click here to support this project

Your support helps maintain and improve this tool for everyone. Thank you! 🙏

Features

🔍 People Search - Find prospects by job title, location, company
👤 People Enrichment - Enrich contact data with emails, phone numbers, LinkedIn profiles
🏢 Organization Enrichment - Get detailed company information
🌍 Organization Search - Discover companies by industry, size, location
📊 B2B Intelligence - Access Apollo's database of 275M+ contacts

Related MCP server: apollo-io-mcp-server

Installation

Claude Desktop

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on Mac or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "apollo-io": {
      "command": "npx",
      "args": ["-y", "@louis030195/apollo-io-mcp"],
      "env": {
        "APOLLO_API_KEY": "your-apollo-api-key"
      }
    }
  }
}

Claude Code

# Install globally in user scope with API key
claude mcp add -s user apollo-io npx -e APOLLO_API_KEY=your-apollo-api-key -- -y @louis030195/apollo-io-mcp

Get Your Apollo.io API Key

Go to Apollo.io
Sign up or log in
Navigate to Settings → Integrations → API
Copy your API key

Usage

Once configured, you can use natural language to interact with Apollo.io:

People Search

"Find CTOs in San Francisco working at Series A startups"
"Search for product managers in New York"
"Who are the engineers at Anthropic?"

People Enrichment

"Enrich this email: john@example.com"
"Find contact info for John Smith at Apollo.io"
"Get details about jane.doe@company.com"

Organization Search

"Find SaaS companies in San Francisco with 50-200 employees"
"Search for AI companies in the Bay Area"
"List fintech startups in London"

Organization Enrichment

"Tell me about apollo.io"
"Get company info for anthropic.com"
"What technologies does stripe.com use?"

Tools

`apollo_search_people`

Search for people/prospects in Apollo's B2B database.

Parameters:

keywords (string, optional): Keywords to search for (job title, company, etc)
titles (array, optional): Job titles to filter by
locations (array, optional): Locations to filter by
organization_ids (array, optional): Organization IDs to filter by
page (number, optional): Page number for pagination (default: 1)
per_page (number, optional): Results per page, max 100 (default: 10)

Returns: List of people with contact info, job titles, companies, etc.

`apollo_enrich_person`

Enrich a person's data with Apollo's B2B intelligence.

Parameters:

first_name (string, optional): Person's first name
last_name (string, optional): Person's last name
email (string, optional): Person's email address
domain (string, optional): Company domain
organization_name (string, optional): Company name

Returns: Detailed person data including email, phone, LinkedIn, job info, etc.

`apollo_enrich_organization`

Enrich a company's data with Apollo's B2B intelligence.

Parameters:

domain (string, required): Company domain (e.g., apollo.io)

Returns: Detailed company data including size, industry, technologies, funding, etc.

`apollo_search_organizations`

Search for companies/organizations in Apollo's B2B database.

Parameters:

keywords (string, optional): Keywords to search for
locations (array, optional): Locations to filter by
employee_ranges (array, optional): Employee count ranges (e.g., ['1-10', '11-50'])
page (number, optional): Page number for pagination (default: 1)
per_page (number, optional): Results per page, max 100 (default: 10)

Returns: List of organizations with company info, size, location, etc.

Development

# Clone the repo
git clone https://github.com/louis030195/apollo-io-mcp.git
cd apollo-io-mcp

# Install dependencies
npm install

# Build
npm run build

# Run tests
npm test

# Run locally
APOLLO_API_KEY=your-api-key npm start

API Documentation

See Apollo.io API Docs for full API details.

License

MIT

Author

Louis Beaumont

Available Tools

7 tools

apollo_enrich_organizationA

Enrich a company's data with Apollo's B2B intelligence using their domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Company domain (e.g., apollo.io)

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose whether 'enrich' is read-only or destructive, nor any side effects, rate limits, or authentication needs. For a mutation-like tool, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no unnecessary words, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Low complexity (1 param, no output schema). Description lacks mention of return values or what enrichment entails, leaving the agent uninformed about output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with description. The tool description adds no extra meaning beyond the schema example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'enrich', resource 'company's data', and method 'using their domain'. Distinguishes from sibling 'apollo_enrich_person' by focusing on company.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when you have a company domain to enrich data. No explicit when-not or alternatives, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_enrich_personC

Enrich a person's data with Apollo's B2B intelligence. Provide email, name, or company info.

ParametersJSON Schema

Name	Required	Description
`first_name`	No	Person's first name
`last_name`	No	Person's last name
`email`	No	Person's email address
`domain`	No	Company domain (e.g., apollo.io)
`organization_name`	No	Company name

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fails to disclose behavioral traits such as what data is returned, whether enrichment requires authentication, or how errors are handled. The term 'enrich' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded. However, it sacrifices informative content for brevity, making it less useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 5 optional parameters and no output schema, the description lacks completeness. It does not explain what enrichment provides, how to validate success, or any constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for each parameter. The description adds 'Provide email, name, or company info', which is redundant and does not enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool enriches a person's data with B2B intelligence, specifying input types. However, it does not explicitly differentiate from the sibling tool 'apollo_enrich_organization', leaving potential confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'apollo_search_people' or 'apollo_enrich_organization'. There are no use cases, prerequisites, or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_get_email_accountsA

Get list of email accounts connected to your Apollo account. Requires master API key.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the authentication requirement (master API key) but does not mention whether the operation is read-only, how results are paginated, or what happens if no accounts exist. Basic transparency but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, very concise. However, it could be structured with additional context (e.g., output format) without becoming verbose. It earns its place but leaves room for improvement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and low complexity, the description adequately states purpose and a key requirement. However, it does not mention what the returned data looks like or any edge cases, so it is minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter details, and its lack of param info is appropriate. Baseline 4 for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'list of email accounts connected to your Apollo account'. This distinguishes it from siblings like apollo_search_people or apollo_enrich_organization, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a prerequisite ('Requires master API key') but provides no guidance on when to use this tool versus alternatives, nor when not to use it. For a simple list tool, this is minimal but not absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_get_email_message_activitiesA

Get activities (opens, clicks, replies) for a specific email message sent via sequence. Requires master API key.

ParametersJSON Schema

Name	Required	Description	Default
`message_id`	Yes	The emailer message ID to get activities for

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the required auth level (master API key) and lists activity types, but does not disclose potential rate limits, response format, or guarantee of read-only behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the purpose, the second adds a critical requirement. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with low complexity (one required parameter, no output schema), the description adequately covers what it does and the auth requirement. It could mention the return type but is sufficient for agent selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage with a description of message_id. The tool description adds value by linking the message to a sequence ('sent via sequence'), which is not in the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'activities for a specific email message sent via sequence', specifying the types of activities (opens, clicks, replies). This distinguishes it from sibling tools which perform enrichment or search operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a key requirement ('Requires master API key') but does not explicitly state when to use this tool versus alternatives. However, the sibling tools are functionally distinct, so usage context is implicitly clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_search_organizationsA

Search for companies/organizations in Apollo's B2B database. Filter by location, size, keywords, etc.

ParametersJSON Schema

Name	Required	Description
`keywords`	No	Keywords to search for
`locations`	No	Array of locations to filter by
`employee_ranges`	No	Employee count ranges (e.g., ['1-10', '11-50'])
`page`	No	Page number for pagination
`per_page`	No	Results per page (max 100)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states the tool searches and filters, but does not mention whether it is read-only, authentication needs, rate limits, pagination behavior, or output format. This leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise and front-loaded. However, it ends with 'etc.' which is slightly vague and reduces specificity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and the complexity of the tool (5 parameters, pagination), the description is incomplete. It does not explain what the search returns, how results are ordered, or how they can be used with sibling tools like apollo_enrich_organization.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. The description adds only a vague summary ('Filter by location, size, keywords, etc.'), which does not provide meaningful additional semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for companies/organizations and mentions specific filters (location, size, keywords). It distinguishes itself from sibling tools like apollo_enrich_organization (which enriches a specific organization) and apollo_search_people.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (searching for organizations) but does not explicitly state when not to use it or provide alternatives. However, the sibling context makes the usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_search_peopleA

Search for people/prospects in Apollo's B2B database. Filter by job titles, locations, companies, etc.

ParametersJSON Schema

Name	Required	Description
`keywords`	No	Keywords to search for (job title, company, etc)
`titles`	No	Array of job titles to filter by
`locations`	No	Array of locations to filter by
`organization_ids`	No	Array of organization IDs to filter by
`page`	No	Page number for pagination
`per_page`	No	Results per page (max 100)

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the ability to filter but does not disclose behaviors such as pagination (though parameters include page and per_page), rate limits, authentication requirements, or edge cases like empty results. It covers basic functionality but lacks deeper behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded with the core purpose. However, it could be more efficient by removing 'for people/prospects' (redundant with title) and focusing on the unique value. It earns its place but is somewhat generic.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not describe return values, pagination behavior, or how results are structured. For a search tool with many filters, more context is needed to aid correct invocation, such as typical use cases or result schema hints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds 'etc.' hinting at additional filters but does not provide significant new meaning beyond what the schema already describes (keywords, titles, locations, organization_ids, pagination). It fails to elaborate on parameter syntax or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for people/prospects in Apollo's B2B database.' It uses a specific verb ('Search') and resource ('people/prospects'), and the mention of filtering distinguishes it from sibling tools like apollo_enrich_person (which enriches existing data) and apollo_search_organizations (which searches for companies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates usage context ('Filter by job titles, locations, companies, etc.') but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. The implied usage is when needing to find prospects, but lacks exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apollo_search_sequencesA

Search for email sequences in your Apollo account. Returns sequence stats including sent, bounced, replied counts. Requires master API key.

ParametersJSON Schema

Name	Required	Description
`name`	No	Sequence name to filter by
`page`	No	Page number for pagination
`per_page`	No	Results per page

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses return values (sent, bounced, replied counts) and authentication requirement. With no annotations, the description adequately conveys read-only nature and basic behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences covering purpose, return stats, and auth. No redundant or extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully describes the tool's function, key return fields, and auth requirement. Adequate for a parameterized search tool without output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions (100% coverage). Description does not add new parameter details beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Search' and resource 'email sequences' with specific return values (stats). Distinct from sibling tools which target organizations, people, or email accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions required master API key, which is a key prerequisite. Does not explicitly contrast with alternatives, but sibling names imply different entities, so usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.2.0Jun 24, 2026
- First observedapollo_enrich_organization
- First observedapollo_enrich_person
- First observedapollo_get_email_accounts
- First observedapollo_get_email_message_activities
- First observedapollo_search_organizations
- First observedapollo_search_people
- First observedapollo_search_sequences

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-06-24 07:31 across 7 tools

Disambiguation5/5

Each tool targets a distinct resource or action (organization, person, email accounts, email activities, sequences), with no overlap in purpose.

Naming Consistency5/5

All tools follow the consistent pattern apollo_verb_noun (e.g., apollo_enrich_organization, apollo_search_people), with uniform verb and noun usage.

Tool Count5/5

7 tools is ideal for an Apollo.io integration, covering core functionalities without being excessive or insufficient.

Completeness4/5

Covers enrichment and search for people and organizations, plus email activities and sequences. Minor gaps, like missing a direct tool to fetch a specific person by ID, but enrich by email can substitute.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AIsa Apollo AOAuth
one.aisa
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.
CRM Search
591
GTM API: LinkedIn MCP ServerOAuth
com.gtm-api
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Social Media Communication
190
ZoomInfoOAuth
io.github.Zoominfo
Official ZoomInfo MCP server. Search and enrich companies, contacts, and buyer intent signals.
Customer Data Platforms CRM Research & Data
13
Tomba MCP Server BOAuth
io.github.tomba-io
MCP server for Tomba email finder, verification, and contact enrichment API
Email CRM Customer Data Platforms
3818

Related MCP Servers

apollo-io-mcp
CRM Search
thevgergroup
A
license
A
quality
A
maintenance
MCP server for Apollo.io B2B database enabling people and company search, enrichment, and insights through conversational interfaces.
Updated 6 days ago (2026-09-14 09:08 UTC)
9
451 npm
19
MIT
apollo-io-mcp-server
edwardchoh
F
license
B
quality
D
maintenance
Exposes Apollo.io API functionalities as MCP tools for people and organization enrichment, search, and job postings. Enables natural language interaction with Apollo.io data.
Updated a year ago (2025-04-11 23:20 UTC)
5
16
-
Apollo.io MCP Server
CRM Marketing
Inferensys
F
license
B
quality
C
maintenance
A Model Context Protocol (MCP) server for the Apollo.io API, giving AI coding assistants direct access to Apollo.io's sales intelligence platform for prospecting, enrichment, CRM operations, and outreach.
Updated 4 months ago (2026-05-16 21:23 UTC)
50
5
-
Apollo MCP
CRM Marketing
ym-labs
A
license
Not graded
quality
C
maintenance
MCP server for the Apollo.io API that lets LLMs search and enrich people and company data.
Updated 6 months ago (2026-03-20 16:28 UTC)
45 npm
MIT