Apollo.io MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, enrich_organization and enrich_person target different entity types, while search_accounts and search_people serve different search functions. The descriptions reinforce these distinctions, making tool selection straightforward.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., enrich_organization, search_accounts, update_account). The only minor deviation is health_check, which uses a compound noun instead of a verb_noun structure, but this doesn't significantly impact readability or predictability.
Tool Count5/5
With 11 tools, the count is well-scoped for a CRM/sales intelligence platform. Each tool serves a specific function in account management, enrichment, and search operations, with no apparent redundancy or missing core functionalities, making the set appropriately sized.
Completeness4/5
The tool set provides comprehensive coverage for account CRUD (create, get, update, search), organization and person enrichment, and opportunity search. A minor gap is the lack of update/delete operations for people or opportunities, but agents can likely work around this given the strong core functionality.
Average 3.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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. While it mentions that domain and address will be 'intelligently parsed for additional data', it doesn't disclose important behavioral traits like authentication requirements, rate limits, whether this is a write operation (implied but not stated), what happens on duplicate accounts, or what the response contains. The description adds minimal behavioral context beyond the basic operation.
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 appropriately concise with two sentences. The first sentence clearly states the core purpose, and the second adds useful information about intelligent parsing. There's no wasted verbiage, though the second sentence could be more specific about what 'additional data' means.
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 that there's an output schema (which handles return values), no annotations, and 4 parameters with 0% schema coverage, the description is incomplete. It provides basic purpose but lacks crucial context about parameter usage, behavioral constraints, and differentiation from sibling tools. For a creation tool with multiple parameters, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters (only 1 required), the description provides almost no parameter guidance. It mentions that 'domain and address will be intelligently parsed' which hints at how those parameters might be used, but doesn't explain the purpose of 'name' (the only required parameter) or 'phone_number', nor does it provide format expectations, constraints, or examples for any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new account in Apollo.io' which provides a clear verb ('Create') and resource ('account'), but it doesn't differentiate from sibling tools like 'update_account' or 'get_account_by_id'. The second sentence is somewhat tautological, restating the tool name rather than adding specificity about what makes this creation tool unique.
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 is provided about when to use this tool versus alternatives like 'update_account' or 'get_account_by_id'. The description mentions intelligent parsing of domain and address, but doesn't explain when this tool is preferred over other account-related operations or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Only specified fields will be updated' which adds some context about partial updates, but fails to address critical aspects like authentication requirements, rate limits, error handling, or what the update operation actually does to the account data.
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 appropriately brief with three sentences that get straight to the point. Each sentence adds value: establishing context, stating the action, and providing a key behavioral note about partial updates. No wasted words or redundancy.
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?
For a mutation tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema, the description is insufficient. It doesn't explain the update semantics, error conditions, or relationship to sibling tools. While the output schema may cover return values, the description lacks critical context about the operation itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters, the description provides no information about parameter meanings beyond what's in the schema titles. It doesn't explain what 'account_id' identifies, what format 'domain' should be in, or how 'phone_number' should be structured, leaving significant gaps in parameter understanding.
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 action ('update') and resource ('account in Apollo.io'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_account' beyond the basic verb distinction, lacking specificity about what makes this update operation unique.
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 'create_account' or 'get_account_by_id'. There's no mention of prerequisites, error conditions, or typical use cases, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions the tool returns detailed information (e.g., industry, employee count, contact info), which adds some context about output behavior. However, it lacks critical details such as data sources, rate limits, authentication requirements, or error handling, leaving significant gaps for a tool with no annotation coverage.
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 appropriately concise with two sentences that efficiently convey the core functionality. The first sentence states the purpose, and the second elaborates on inputs and outputs without redundancy. However, it could be slightly more front-loaded by integrating key details earlier, but overall it's well-structured.
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 the tool's moderate complexity (enriching data), no annotations, low schema coverage (0%), but with an output schema present, the description is partially complete. It covers the basic purpose and output types but lacks details on parameters, behavioral traits, and usage context. The output schema mitigates some gaps, but overall it's adequate with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('request') with 0% description coverage and no enums, making it completely undocumented. The description adds minimal semantics by implying the parameter is a domain or related data, but it doesn't specify the exact format (e.g., string vs. object), required fields, or examples. This insufficiently compensates for the low schema coverage.
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's purpose: 'enriches company data based on domain, returning detailed information about the organization.' It specifies the verb ('enriches'), resource ('company data/organization'), and key input ('domain'). However, it doesn't explicitly differentiate from sibling tools like 'bulk_enrich_organizations' or 'enrich_person,' which would be needed for 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.
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. It doesn't mention sibling tools like 'bulk_enrich_organizations' for multiple domains or 'enrich_person' for individual data, nor does it specify prerequisites or exclusions. The only implied context is enriching single organizations by domain, but this is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions that the tool 'can reveal email addresses and phone numbers', which hints at data retrieval, but it doesn't clarify if this is a read-only operation, requires authentication, has rate limits, or what happens on failure. For a tool with no annotations and potential privacy implications, this is a significant gap in transparency.
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 concise with three sentences that are front-loaded: the first sentence states the core purpose, the second elaborates slightly, and the third adds a usage tip. There's no wasted text, but the structure could be improved by more clearly separating purpose from guidelines.
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 the tool's complexity (enriching person data with contact details), no annotations, and an output schema exists (which should cover return values), the description is moderately complete. It states what the tool does but lacks details on behavioral traits and parameter usage. The presence of an output schema helps, but the description doesn't fully compensate for the missing annotations and low parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('request') with 0% description coverage, and the description doesn't explain what 'request' should contain (e.g., person's name, ID, or other identifiers). It vaguely states 'The more information provided, the higher the match likelihood', but this doesn't add meaningful semantics beyond the schema. With low schema coverage, the description fails to compensate adequately.
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's purpose: 'Enrich a person's information and reveal contact details.' It specifies the verb ('enrich'), resource ('person's information'), and outcome ('reveal contact details'). However, it doesn't explicitly differentiate from sibling tools like 'search_people' or 'get_account_by_id', which might also retrieve person information, so it doesn't reach the highest score.
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 minimal guidance: 'The more information provided, the higher the match likelihood' implies that better input leads to better results, but it doesn't specify when to use this tool versus alternatives like 'search_people' or 'get_account_by_id'. There's no explicit context, exclusions, or named alternatives, leaving the agent with little direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the tool returns contact information and employment details, which is helpful, but lacks critical behavioral traits: it doesn't specify if this is a read-only operation, what permissions are needed, whether there are rate limits, or how results are paginated/limited. For a search tool with no annotations, 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 appropriately sized with two sentences: the first states the purpose, and the second adds search criteria and return details. It's front-loaded with the core function. There's minimal waste, though it could be slightly more structured (e.g., bullet points for criteria).
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 the tool's moderate complexity (search with multiple criteria), no annotations, and an output schema that likely handles return values, the description is partially complete. It covers purpose and criteria but lacks behavioral context and detailed parameter guidance. The output schema reduces the need to explain returns, but gaps in usage and transparency remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists search criteria like job title, seniority, company domain, and location, which adds meaning beyond the generic 'request' parameter in the schema. However, it doesn't explain the parameter's structure, format, or how to combine criteria, leaving the single required parameter poorly defined.
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 searches for people/contacts in the Apollo.io database, specifying the resource (people/contacts) and verb (search). It distinguishes from siblings like search_accounts and search_opportunities by focusing on people rather than accounts or opportunities. However, it doesn't explicitly contrast with enrich_person, which might retrieve details for a specific person.
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. It doesn't mention when to choose search_people over enrich_person for individual details, or how it differs from search_accounts for company-related searches. No exclusions or prerequisites are stated, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions search capabilities by name, location, employee count, and other criteria, but doesn't describe pagination, rate limits, authentication requirements, result format, or what 'other criteria' might include. For a search tool with zero annotation coverage, this leaves significant behavioral 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 appropriately concise with two sentences. The first sentence establishes the core purpose, and the second adds context about search criteria and use cases. No wasted words, though it could be slightly more structured by explicitly listing parameters.
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 the tool's moderate complexity (search functionality), no annotations, and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. It covers what the tool does and some use cases, but lacks parameter details and behavioral context that would make it fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single 'request' parameter. It mentions search criteria like name, location, and employee count, but doesn't explain how to structure these in the request parameter. With low coverage and no parameter guidance in the description, this fails to compensate for the schema gap.
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's purpose: 'Search for accounts/companies in Apollo.io database' with specific resources (accounts/companies) and a database context. It distinguishes from siblings like 'search_people' by focusing on companies, but doesn't explicitly differentiate from 'get_account_by_id' or 'bulk_enrich_organizations' which also involve account 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 provides implied usage guidance: 'Useful for finding potential prospects and account information' suggests prospecting use cases. However, it doesn't explicitly state when to use this vs. alternatives like 'get_account_by_id' (for known IDs) or 'search_people' (for individuals), nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. While it mentions filtering and sorting capabilities, it doesn't describe important behavioral traits like whether this is a read-only operation, what permissions are required, rate limits, pagination behavior (implied by page/per_page parameters but not explained), or what the search returns. The description is too sparse for a tool with 4 parameters and no annotation coverage.
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 appropriately concise with three sentences that are front-loaded with the core purpose. Each sentence adds value: the first states what the tool does, the second elaborates on capabilities, and the third provides usage context. There's no wasted verbiage or redundancy.
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 that there's an output schema (which handles return values), no annotations, and 4 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose and some usage context but lacks parameter explanations and behavioral details needed for a search tool with filtering/sorting capabilities. The existence of an output schema prevents the lowest score, but significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'filtering and sorting options' in general terms but doesn't specify what parameters are available, what they mean, or how they work. The four parameters (page, per_page, account_stage_ids, sort_by_field) receive no explanation in the description, leaving significant gaps in understanding.
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 searches for sales opportunities in Apollo.io with filtering and sorting, specifying both the verb ('searches') and resource ('sales opportunities'). It distinguishes from obvious siblings like search_accounts and search_people by focusing on opportunities rather than accounts or people, though it doesn't explicitly contrast with all siblings.
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 provides implied usage context ('Useful for tracking deals and pipeline management'), suggesting when this tool might be appropriate. However, it doesn't explicitly state when to use this versus alternatives like search_accounts or search_people, nor does it provide exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the batch limit (10 domains) but lacks details on permissions, rate limits, what 'enrich' entails (e.g., data sources, fields added), error handling, or response format. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a clarifying detail. Both sentences are essential—no wasted words. It's appropriately sized for a simple tool.
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 1 parameter with 0% schema coverage, an output schema exists (so return values are covered), and no annotations, the description is minimally adequate. It covers the batch nature and limit but misses behavioral aspects like mutation effects or error cases. For a bulk operation tool, more context on outcomes would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'domains' are used for enrichment and specifies a limit of 10 items, adding some meaning. However, it doesn't explain domain format requirements (e.g., valid TLDs), whether duplicates are allowed, or other constraints, leaving gaps in parameter understanding.
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's purpose: 'Bulk enrich multiple organizations at once' and specifies it's based on domains. It distinguishes from the sibling 'enrich_organization' by emphasizing bulk capability. However, it doesn't explicitly contrast with other siblings like 'enrich_person' or 'search_accounts'.
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 context by stating 'Up to 10 domains can be processed in a single request,' suggesting this tool is for batch processing. It doesn't explicitly state when to use this versus 'enrich_organization' (single vs. bulk) or other alternatives, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'returns the list of configured email accounts' but doesn't cover critical aspects like authentication needs, rate limits, error handling, or whether it's a read-only operation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose, and the second clarifies the return value. There's no wasted language, and it's front-loaded with the main action, making it easy for an agent to parse quickly.
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 the tool's low complexity (0 parameters) and the presence of an output schema, the description is minimally adequate. However, with no annotations and sibling tools present, it lacks context on usage scenarios and behavioral traits, which could hinder the agent's ability to invoke it correctly in practice.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied since no parameters exist and schema coverage is complete.
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's purpose with 'Retrieve email accounts associated with your Apollo.io account' and specifies the resource (email accounts) and context (Apollo.io). However, it doesn't explicitly differentiate from sibling tools like 'get_account_by_id' or 'search_accounts' that might also retrieve account information, missing full sibling distinction.
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. It doesn't mention prerequisites, exclusions, or compare to sibling tools like 'get_account_by_id' or 'search_accounts', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions fetching 'comprehensive account data' but doesn't disclose behavioral traits such as whether this is a read-only operation, authentication requirements, rate limits, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
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 appropriately sized with two sentences: the first states the core purpose, and the second elaborates on the data included. It's front-loaded with the main action and resource, with no wasted words. Every sentence adds value by clarifying scope and content.
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 the tool's low complexity (single parameter), lack of annotations, and presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose, parameter semantics, and data scope. However, it could improve by addressing behavioral aspects like read-only nature or error cases, which are missing despite the output schema.
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 description adds meaning by specifying that the tool retrieves data 'by ID', which clarifies the purpose of the 'account_id' parameter beyond what the schema provides (schema coverage is 0%). Since there's only one parameter and the description explains its role, it compensates well for the lack of schema descriptions, though it doesn't detail format constraints like ID structure.
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 verb ('Retrieve', 'fetches') and resource ('detailed information for a specific account by ID'), making the purpose evident. It distinguishes from siblings like 'search_accounts' by specifying retrieval by ID rather than search criteria. However, it doesn't explicitly contrast with 'get_email_accounts' or 'enrich_organization', leaving some sibling differentiation incomplete.
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 you need comprehensive account data for a known account ID, but it doesn't explicitly state when to use this versus alternatives like 'search_accounts' (for unknown IDs) or 'enrich_organization' (for organization-level data). No exclusions or prerequisites are mentioned, leaving usage context partially implied rather than fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the tool's behavior as a read-only diagnostic check ('check', 'verify'), which is appropriate, but lacks details like rate limits, error responses, or specific output format. The description adds basic context without contradictions, but more behavioral traits could be included.
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 appropriately sized with two concise sentences that are front-loaded with the main purpose. Every sentence adds value by explaining what the tool does and its specific checks, with zero waste or unnecessary details.
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 the tool's low complexity (0 parameters, simple diagnostic purpose) and the presence of an output schema, the description is mostly complete. It covers the purpose and usage context adequately, but could benefit from more behavioral details like what 'health' entails or authentication specifics, though the output schema may handle return values.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description does not mention parameters, which is acceptable, earning a baseline score of 4 for not introducing confusion or redundancy.
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 with specific verbs ('check', 'verify') and resources ('health and authentication status', 'API connection', 'API key', 'service accessibility'). It distinguishes itself from sibling tools by focusing on system diagnostics rather than data operations like enrichment, search, or updates.
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 usage context for verifying API connectivity and authentication validity, which is clear guidance for when to use this tool. However, it does not explicitly state when not to use it or name specific alternatives among the siblings, such as distinguishing from data retrieval tools that might also fail due to auth issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Apollo-MCP MCP server](https://glama.ai/mcp/servers/FromSmall2Big/Apollo-MCP/badges/card.svg)](https://glama.ai/mcp/servers/FromSmall2Big/Apollo-MCP)

Score Badge

Copy to your README.md:

[![Apollo-MCP MCP server](https://glama.ai/mcp/servers/FromSmall2Big/Apollo-MCP/badges/score.svg)](https://glama.ai/mcp/servers/FromSmall2Big/Apollo-MCP)

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/FromSmall2Big/Apollo-MCP'

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