How do I use Clay.com MCP Server?

1. Click on "Install 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., "@Clay.com MCP Server find CTOs at AI 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.

Clay.com MCP Server

by bpw-civic

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Clay.com MCP Server

MCP (Model Context Protocol) server for Clay.com API integration, providing people and company enrichment tools.

Features

People Search & Enrichment: Find and enrich people by title, company, industry, location
Company Search & Enrichment: Find and enrich companies by industry, technology, funding, size
Clay Tables: List, query, and explore your Clay workspace tables

Related MCP server: GTM MCP Server

Installation

npm install @civic-wisdom/clay-mcp

Or clone and build from source:

git clone https://github.com/bpw-civic/clay-mcp-server.git
cd clay-mcp-server
npm install
npm run build

Configuration

Set your Clay API key as an environment variable:

export CLAY_API_KEY=your-api-key-here

Usage

With Claude Code

Add to your .claude/settings.json or .mcp.json:

{
  "mcpServers": {
    "clay": {
      "command": "node",
      "args": ["node_modules/@civic-wisdom/clay-mcp/dist/index.js"],
      "env": {
        "CLAY_API_KEY": "${CLAY_API_KEY}"
      }
    }
  }
}

Or if installed from source:

{
  "mcpServers": {
    "clay": {
      "command": "node",
      "args": ["/path/to/clay-mcp-server/dist/index.js"],
      "env": {
        "CLAY_API_KEY": "${CLAY_API_KEY}"
      }
    }
  }
}

With Other MCP Clients

The server communicates via stdio. Start it with:

CLAY_API_KEY=your-key node dist/index.js

Available Tools

People Tools

`clay_search_people`

Search for people matching specific criteria.

Parameters:

query (string, optional): Natural language search query
filters (object, optional):
- titles: Array of job titles
- companies: Array of company names
- industries: Array of industries
- locations: Array of locations
- companySize: Company size range (e.g., "51-200")
- seniorityLevels: Array of seniority levels
limit (number, default 25): Maximum results

Example:

{
  "query": "ML engineers",
  "filters": {
    "industries": ["Technology", "AI"],
    "companySize": "51-200"
  },
  "limit": 10
}

`clay_enrich_person`

Get full enrichment data for a specific person.

Parameters (at least one required):

email: Email address
linkedinUrl: LinkedIn profile URL
fullName + company: Name and company combo

Example:

{
  "email": "jane@example.com"
}

Returns:

Full name, title, company
Work experience history
Education
Skills
Social profiles (LinkedIn, Twitter, GitHub)
Location details
Contact information

Company Tools

`clay_search_companies`

Search for companies matching specific criteria.

Parameters:

query (string, optional): Natural language search query
filters (object, optional):
- industries: Array of industries
- technologies: Array of technologies
- employeeCount: Size range (e.g., "51-200")
- fundingStage: Funding stage (e.g., "series_a")
- location: Location string
- foundedAfter: Year (number)
- foundedBefore: Year (number)
limit (number, default 25): Maximum results

Example:

{
  "filters": {
    "industries": ["AI", "Machine Learning"],
    "fundingStage": "series_a",
    "location": "San Francisco"
  }
}

`clay_enrich_company`

Get full enrichment data for a specific company.

Parameters (at least one required):

domain: Company domain
name: Company name
linkedinUrl: Company LinkedIn URL

Example:

{
  "domain": "anthropic.com"
}

Returns:

Company name, domain, description
Industry classification
Employee count and range
Founding year
Location details
Funding information (total raised, last round, investors)
Technographics (technologies used)
Social profiles
Recent news

Table Tools

`clay_list_tables`

List all Clay tables in your workspace.

Parameters: None

Returns: List of tables with ID, name, description, row count, and timestamps.

`clay_get_table_schema`

Get the schema for a specific table.

Parameters:

tableId (required): Table ID

Returns: Table metadata and column definitions (name, type, description).

`clay_query_table`

Query a Clay table with filters.

Parameters:

tableId (required): Table ID
filters (object, optional): Filter conditions
sort (object, optional): Sort configuration
- column: Column name
- order: "asc" or "desc"
limit (number, default 50): Maximum results
offset (number, default 0): Pagination offset

Example:

{
  "tableId": "tbl_abc123",
  "filters": { "status": "active" },
  "sort": { "column": "created_at", "order": "desc" },
  "limit": 25
}

Resources

The server exposes Clay tables as MCP resources:

clay://tables - List all tables
clay://tables/{id}/schema - Table schema

Development

# Install dependencies
npm install

# Watch mode (rebuild on changes)
npm run dev

# Type check
npm run typecheck

# Build for production
npm run build

# Run the server
npm start

Error Handling

The server handles:

Rate limiting (429 responses) with retry information
API errors with descriptive messages
Missing authentication with clear error message
Invalid parameters with validation feedback

Requirements

Node.js 18+
Clay.com API key (Get one here)

API Reference

This server uses the Clay.com REST API:

Base URL: https://api.clay.com/v1
Authentication: API key in X-Api-Key header

For Clay.com API documentation, visit: https://docs.clay.com/api

License

MIT License - see LICENSE file.

Available Tools

7 tools

clay_enrich_companyA

Get full enrichment data for a specific company. Provide domain, company name, or LinkedIn URL.

ParametersJSON Schema

Name	Required	Description
`domain`	No	Company domain (e.g., "acme.com")
`name`	No	Company name
`linkedinUrl`	No	Company LinkedIn URL

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It implies a non-destructive read operation ('get enrichment data') but does not disclose any behavioral traits such as rate limits, authentication needs, or what happens when multiple parameters are provided.

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?

The description is extremely concise at 14 words over two sentences, with the first sentence front-loading the purpose and the second providing parameter guidance. No filler or redundant information.

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?

While the description covers the basic purpose and input, it lacks information about the output format of the 'full enrichment data'. Given that there is no output schema, the description could be more helpful by hinting at what fields are returned.

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?

Schema coverage is 100% with descriptions, but the description adds value by clarifying that the three parameters are alternatives ('provide domain, company name, or LinkedIn URL'). This goes beyond the schema which merely defines each parameter individually.

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 'full enrichment data for a specific company', distinguishing it from sibling tools like clay_search_companies (search) and clay_enrich_person (people). The additional instruction to provide domain, name, or LinkedIn URL adds specificity.

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 what input to provide but lacks explicit guidance on when to use this tool vs alternatives like clay_search_companies. It does not mention prerequisites, use cases, or exclusions.

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

clay_enrich_personA

Get full enrichment data for a specific person. Provide email, LinkedIn URL, or full name + company.

ParametersJSON Schema

Name	Required	Description
`email`	No	Email address to enrich
`linkedinUrl`	No	LinkedIn profile URL
`fullName`	No	Full name (requires company)
`company`	No	Company name (required if using fullName)

TDQS

A3.9/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 implies a read operation but does not disclose any behavioral traits such as rate limits, data freshness, or whether previous enrichment data is cached.

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?

A single sentence of 14 words that front-loads the purpose and immediately follows with the required inputs. No redundancy or unnecessary information.

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, the description does not explain what 'enrichment data' includes. It is adequate for a simple tool but lacks details on error conditions or response structure that would help an agent use it confidently.

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?

The input schema has 100% description coverage, so the schema already explains each parameter. The description adds minimal extra meaning, merely listing the identifier types without clarifying 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 'Get full enrichment data for a specific person', which is a specific verb+resource. It distinguishes from sibling tools like clay_enrich_company by focusing on individuals.

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 lists three ways to identify the person (email, LinkedIn URL, or full name+company), giving clear usage conditions. However, it does not explicitly compare to sibling tools like clay_search_people or advise when not to use.

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

clay_get_table_schemaA

Get the schema (columns and types) for a specific Clay table.

ParametersJSON Schema

Name	Required	Description	Default
`tableId`	Yes	The ID of the table to get schema for

TDQS

A3.6/5.0

Behavior2/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 only states it retrieves schema, but does not disclose read-only nature, error behavior for invalid tableId, or authentication requirements. For a simple read operation, more transparency about safety is expected.

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?

The description is a single sentence of 12 words, front-loading the purpose with zero wasted words. It is highly concise and structured appropriately.

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 simple tool with one parameter and no output schema, the description is nearly complete. It would benefit from mentioning the return format, but given low complexity, it adequately informs the agent without significant gaps.

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?

The input schema has 100% coverage for the single parameter 'tableId' with a clear description. The tool description does not add extra meaning beyond the schema, so it meets the baseline for a well-documented parameter but does not exceed it.

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 retrieves the schema (columns and types) for a specific Clay table. The verb 'Get' and resource 'schema' are precise, and it distinguishes from sibling tools like clay_list_tables (lists tables) and clay_query_table (queries data).

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 implies usage when needing a table's schema, but provides no explicit guidance on when to use alternatives like clay_list_tables, nor does it mention prerequisites or when not to use it. It is adequate but lacks differentiation.

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

clay_list_tablesA

List all available Clay tables in your workspace. Returns table names, IDs, row counts, and column information.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 description must cover behaviors. It describes the output but does not mention pagination, rate limits, or permissions. Adequate but incomplete for a simple tool.

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 that is clear and front-loaded. Every word adds value with no waste.

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?

Given no output schema, the description provides the key return fields. For a simple list tool, this is sufficient, though details on pagination or volume limits would improve completeness.

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?

No parameters exist, so schema coverage is 100%. Baseline 4 applies; description adds no param detail as none needed.

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?

Clearly states it lists all tables and returns specific information (names, IDs, row counts, column info). However, does not explicitly differentiate from sibling tools like clay_get_table_schema.

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?

No guidance on when to use this tool versus alternatives such as clay_get_table_schema or clay_query_table. The description lacks context for appropriate usage.

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

clay_query_tableA

Query a Clay table with optional filters and sorting. Use this to retrieve specific data from your Clay tables.

ParametersJSON Schema

Name	Required	Description
`tableId`	Yes	The ID of the table to query
`filters`	No	Filter conditions as key-value pairs (e.g., {"status": "active"})
`sort`	No
`limit`	No	Maximum number of results (default 50, max 100)
`offset`	No	Number of rows to skip (for pagination)

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 cover behavioral traits. It only states the basic operation without disclosing side effects, permissions, or edge cases like non-existent tables. The description is insufficient to fully inform an agent.

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 short and front-loaded, but the second sentence is slightly redundant. It could be more compact without loss of meaning.

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?

The tool has no output schema and moderate complexity (5 params, nested objects). The description does not mention return format, pagination behavior, or error handling, leaving significant gaps for an agent.

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?

The input schema already describes most parameters (80% coverage). The description adds no extra meaning beyond mentioning optional filters and sorting, so baseline 3 is appropriate.

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 'Query' and the resource 'Clay table', distinguishing it from sibling tools like clay_get_table_schema and clay_search_* which target different 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 explicitly says to use this tool to 'retrieve specific data from your Clay tables', providing clear context. Although alternatives are not directly mentioned, sibling tool names imply when other tools would be more appropriate.

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

clay_search_companiesB

Search for companies matching specific criteria. Use this to find companies by industry, technology stack, size, funding stage, or location.

ParametersJSON Schema

Name	Required	Description
`query`	No	Natural language search query (e.g., "AI startups in San Francisco")
`filters`	No
`limit`	No	Maximum number of results (default 25, max 100)

TDQS

B3.2/5.0

Behavior2/5

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 'Search for companies', which implies a read operation, but it does not explicitly confirm non-destructive behavior, rate limits, or authentication needs. This leaves uncertainty for the agent.

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 front-loads the core purpose. It is appropriately concise with no wasted words.

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?

The description lacks information about the output format (no output schema provided). For a search tool, an agent needs to understand the return structure. Additionally, with 6 sibling tools, some context about when to use this over clay_search_people would improve completeness.

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 high (67%+) and the description merely reiterates the filter fields already documented in the schema. It does not add additional constraints or clarify usage of nested parameters beyond what the schema provides. Baseline 3 is appropriate.

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 it searches for companies by criteria, but does not distinguish itself from its sibling clay_search_people, which searches for people. This lack of sibling differentiation is a minor gap.

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 implies usage by listing searchable criteria, but provides no explicit guidance on when to use this tool vs alternatives like clay_search_people or enrichment tools. Missing when-not-to-use or exclusionary advice.

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

clay_search_peopleA

Search for people matching specific criteria. Use this to find people by job title, company, industry, location, or company size.

ParametersJSON Schema

Name	Required	Description
`query`	No	Natural language search query (e.g., "ML engineers at AI startups")
`filters`	No
`limit`	No	Maximum number of results (default 25, max 100)

TDQS

A3.6/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 fully disclose behavioral traits. It does not mention rate limits, pagination, search behavior (e.g., fuzzy matching), or whether results are public only. The nested filters are complex but no explanation of their interaction is given.

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?

The description is only two sentences, directly stating purpose and usage without unnecessary words. It is well-structured and front-loaded.

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 no annotations, no output schema, and a complex nested input schema, the description lacks completeness. It does not explain default behavior, limit implications, or how filters combine. More context is needed for effective use.

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 67% with detailed descriptions for each parameter. The description adds meaning by summarizing the criteria types (job title, company, etc.) but does not significantly enhance understanding 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 verb 'Search' and resource 'people', and specifies criteria such as job title, company, industry, location, or company size. It also distinguishes from the sibling tool 'clay_search_companies' by focusing on 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 explicitly indicates when to use the tool: 'Use this to find people by...' but does not provide when-not-to-use or alternatives. However, the context is clear and sufficient for basic usage.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool serves a distinct purpose: enrichment for companies/persons, table metadata, and search. There is no overlap or ambiguity between tool functionalities.

Naming Consistency5/5

All tools follow a consistent 'clay_{verb}_{noun}' pattern using snake_case, making the action and target clear in every name.

Tool Count5/5

With 7 tools, the set is well-scoped for the domain of enrichment, table management, and search, providing essential operations without unnecessary bloat.

Completeness3/5

The tools cover enrichment, search, and table schema/querying, but lack write operations (e.g., create/update/delete) for tables or data, which may limit full workflow coverage.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Tomba MCP Server B
io.github.tomba-io
MCP server for Tomba email finder, verification, and contact enrichment API
Email CRM Customer Data Platforms
3818
LeadFoxConnect
io.github.LeadFox-Shay
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Marketing CRM
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
GTM API: LinkedIn MCP Server
com.gtm-api
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Social Media Communication
15

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 10 days ago (2026-08-24 09:09 UTC)
9
507
19
MIT
GTM MCP Server
CRM Communication Email
dylanottinger
F
license
Not graded
quality
D
maintenance
A unified MCP server that connects HubSpot, Clay, Apollo, Slack, and email to enable AI agents to execute multi-step GTM workflows such as prospecting, enrichment, CRM updates, and notifications.
Updated 3 months ago (2026-06-08 19:25 UTC)
@louis030195/apollo-io-mcp
CRM Search
louis030195
A
license
A
quality
D
maintenance
MCP server for Apollo.io B2B sales intelligence API. Enables searching and enriching people and organizations via natural language.
Updated a year ago (2025-10-17 22:53 UTC)
7
27
4
MIT
Apollo MCP
CRM Marketing
ym-labs
A
license
Not graded
quality
D
maintenance
MCP server for the Apollo.io API that lets LLMs search and enrich people and company data.
Updated 5 months ago (2026-03-20 16:28 UTC)
66
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bpw-civic/clay-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server