Apollo.io MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, with only minor overlaps like search_contacts (saved contacts) vs. search_people (prospecting database) and list_custom_fields_deprecated vs. list_fields. Descriptions effectively resolve ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in lowercase with underscores (e.g., create_contact, search_people). No mixed conventions or confusing name styles.
Tool Count2/5
With 50 tools, the server is significantly oversized compared to typical MCP servers (3-15). While each tool serves a specific function, the sheer number makes it heavy for an agent to navigate, and many tools (e.g., search_phone_calls, search_activities) add complexity.
Completeness4/5
The tool surface covers most CRM and enrichment operations comprehensively (CRUD for contacts, opportunities, tasks, notes, labels; enrichment; search; sequences). Minor gaps exist: missing delete_account and delete_opportunity, and no get_sequence by ID, but these are not critical.
Average 3.4/5 across 50 of 50 tools scored. Lowest: 2.4/5.
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
- Last stable release on February 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Undocumented endpoint' and provides no behavioral traits such as whether it is read-only, destructive, or rate-limited. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unnecessary text: 'FREE' and 'Undocumented endpoint' add no value. The first sentence is clear, but the fluff reduces conciseness.
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?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, pagination behavior, or how filtering across attached entities works.
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 50% (q_keywords and contact_id have descriptions). The description does not add meaning beyond the schema; it repeats 'Search notes' without clarifying parameter usage, defaults, or pagination for page/per_page.
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?
Description clearly states 'Search notes in your Apollo workspace', identifying the verb and resource. It also mentions notes can be attached to contacts, accounts, or opportunities. However, it does not differentiate from sibling search tools like search_contacts 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 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. The description lacks prerequisites, context, or exclusions. The only hint is that notes are attached to other entities, but no explicit usage scenario.
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 present, so the description must carry the full burden of behavioral disclosure. It only states 'update,' implying mutation, but fails to specify whether fields are overwritten or merged, required permissions, rate limits, or side effects. This is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence plus 'FREE'), but this conciseness comes at the cost of completeness. For a tool with six parameters, the description should include more context to be useful. It is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, six parameters, and no annotations, the description is far from complete. It does not explain return values, error conditions, what fields can be updated, or how the update behaves with partial inputs. The agent cannot reliably use this tool based solely on the description.
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?
With schema description coverage at only 17% (only account_id has a description), the description adds no additional meaning for the five other parameters (name, domain, phone_number, raw_address, owner_id). The text does not explain their formats, constraints, or relationships. This leaves the agent with inadequate information.
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 'Update' and the resource 'existing account in your Apollo CRM,' which distinguishes it from sibling tools like create_account (create) and search_accounts (search). The mention of 'FREE' is extraneous but does not detract from clarity.
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 create_account or update_contact. No prerequisites, conditions, or exclusions are provided, leaving the agent uncertain about the appropriate context for invocation.
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 provided; the description only notes 'FREE' and 'Undocumented endpoint', which alerts to instability but lacks details on side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and no wasted words, but lacks structure and substance. It is concise but insufficiently informative.
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?
With 6 parameters, no output schema, and no annotations, the description is far from complete. It does not explain update behavior, constraints, or return values.
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 17% (only opportunity_id described). The description adds no parameter meaning; thus fails to compensate for 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 'Update an existing deal/opportunity', identifying the action and resource. However, it lacks differentiation from siblings like 'create_opportunity' or 'get_opportunity'.
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 vs alternatives, prerequisites, or context. The description gives no usage information beyond the basic action.
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 must disclose behavioral traits. It indicates 'Undocumented endpoint' warns about reliability, but does not describe side effects, permissions, or required auth. The 'Can mark as completed' 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not well-structured as sentence fragments. It front-loads the main action but misses opportunity for clarity.
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?
With 5 parameters and no output schema, the description is incomplete. It fails to explain optional parameters, expected formats (e.g., due_at), or the response after update.
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 coverage is 60%, but the description adds minimal meaning. It mentions 'completed' which is already documented. Parameters 'priority' and 'due_at' are not explained 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 'Update an existing task' which identifies the action and resource. However, it does not differentiate from sibling tools like 'create_task' or 'get_task'.
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 mentions 'FREE' and 'Undocumented endpoint' indicating usage conditions but gives no guidance on when to use this tool versus alternatives like 'create_task' or 'update_account'.
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, the description bears full burden. It discloses return fields and that the endpoint is undocumented and free, but omits behavior like destructive actions, rate limits, pagination details, error handling, or stability implications.
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 very concise with two sentences front-loaded with purpose. However, the inclusion of 'FREE' and 'Undocumented endpoint' adds context but could be more structured (e.g., separated into usage notes).
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 7 parameters, no output schema, and no annotations, the description is incomplete. It lists some return fields but lacks pagination, sorting, filtering details, error codes, or any note about the undocumented endpoint's reliability, which is critical for an agent.
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 coverage is 57%, with four parameters described. The description adds no parameter-level detail beyond restating 'keyword search' for q_keywords, and does not explain sorting, pagination, or the toggle parameter sort_ascending. It fails to compensate for the three undocumented parameters.
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 deals/opportunities in Apollo CRM, specifying verb and resource. However, it does not explicitly differentiate this from sibling search tools like search_contacts or search_accounts, which target different entities but could be confused in purpose.
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 given on when to use this tool versus get_opportunity for individual records or other search tools. The mention of 'Undocumented endpoint' is a warning but lacks context on alternatives or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions 'FREE' (cost implication) and 'Undocumented endpoint' (negative signal), but fails to disclose whether deletion is irreversible, authorization requirements, or side effects like cascading deletes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but includes extraneous phrases 'FREE.' and 'Undocumented endpoint.' that do not aid an AI agent. It could be more focused on essential details.
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 simple deletion tool with no output schema and no annotations, the description is incomplete. It lacks information about response behavior, error handling, or constraints (e.g., cannot delete notes in 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 100% as the single parameter note_id has a clear description. The tool description adds no additional parameter information beyond what the schema already provides, so baseline score of 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 'Delete a note from Apollo,' which is a specific verb+resource. It distinguishes from sibling tools like create_note or delete_contact. However, the added 'FREE. Undocumented endpoint.' does not enhance purpose clarity.
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. The description does not specify prerequisites, such as whether the note must exist, or conditions under which deletion is allowed.
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, the description must reveal behavior. It only states it creates a field and adds data storage context, but omits side effects (e.g., duplicate handling, required permission levels, or impact on existing records).
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?
Two sentences with no redundancy. The first sentence states the action, the second provides context. Could be slightly more informative without sacrificing conciseness, but no wasted words.
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 tool with 4 parameters, 2 enums, and no output schema, the description is incomplete. It misses explaining the relationship between picklist_values and field_type, and does not cover error conditions or success responses.
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%, so the description does not need to explain parameters individually. The description adds a general use case but does not clarify the dependency between picklist_values and field_type or entity_type with 'opportunity'. Baseline score of 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?
Description explicitly states it creates custom fields for contacts or accounts, and the input schema adds 'opportunity'. The action is clear, but the omission of 'opportunity' in the description slightly reduces precision.
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 others, or any prerequisites like admin permissions. The word 'FREE' hints at cost but does not inform usage context.
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 provided, so description bears full burden. It mentions 'Undocumented endpoint' hinting at instability, but fails to disclose side effects, idempotency, or success/failure behavior.
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?
Very concise with purpose front-loaded. The fragments 'FREE' and 'Undocumented endpoint' are extra but not bloated. No unnecessary repetition.
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?
Lacks description of return value or outcome upon success. No output schema and no mention of error conditions. For a creation tool, it is incomplete.
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 both parameters at 100%. Description adds the fact that notes can be associated with a contact, slightly clarifying contact_id, but no further detail on content formatting or constraints.
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 the action (create) and resource (note in Apollo). The mention of association with contact gives context, and distinguishes from note-related siblings like delete_note and search_notes.
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 like create_task or create_contact. No mention of prerequisites or exclusions.
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 present, so the description carries full responsibility. It indicates a read operation ('Get') but does not disclose any side effects, required permissions, rate limits, or behavior beyond the basic action. The 'FREE' note is ambiguous and not standard.
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 very short, consisting of two brief sentences. While concise, the second sentence 'FREE.' adds little value and could be considered unnecessary. Nonetheless, it is not verbose.
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 mentions the types of activities retrieved but does not describe the return format or structure. Given the simplicity of the tool (one parameter, no output schema), it is somewhat complete but lacks details about what the response contains.
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 a minimal parameter description ('Emailer message ID'). The tool description does not add any further meaning or context about the parameter, so it meets the baseline but does not exceed.
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 that the tool retrieves activities (opens, clicks, replies) for a specific outreach email, using the verb 'Get' and specifying the resource. It distinguishes from sibling tools like search_activities which are broader in scope, though the addition of 'FREE' is somewhat extraneous.
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 on when to use this tool versus alternatives such as search_activities or other related tools. The description lacks context about appropriate scenarios 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 present, so the description must cover behavioral traits. It only mentions 'FREE' and that records are 'already saved', but omits authentication needs, rate limits, pagination behavior, or what happens with no results. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus 'FREE.'), which is efficient, but it lacks structure and important details. It front-loads the purpose but fails to elaborate beyond that.
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 search tool with 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain pagination, sorting, filtering, or response format, leaving the agent without sufficient context to use the tool correctly.
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 only 40% (q_keywords and sort_by_field have descriptions). The description adds no additional meaning beyond the schema; for the other three parameters (sort_ascending, page, per_page), no guidance is provided. Given low coverage, the description should compensate but does not.
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 'accounts' in Apollo CRM, specifying it's for saved company records. It distinguishes from sibling tools like search_contacts or search_organizations by focusing on a specific resource type. The mention of 'FREE' adds a notable trait.
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 search_organizations or search_contacts. With many sibling tools, the lack of usage context hinders 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?
With no annotations, the description should disclose behavioral traits. It mentions the endpoint is undocumented and free, but lacks details on authentication, rate limits, or potential instability. The warning is insufficient for safe usage.
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?
Extremely concise with two sentences, directly stating the function and key attributes. However, the phrase 'Undocumented endpoint' is vague and could be more informative without losing brevity.
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 low schema coverage and no output schema, the description is incomplete. It omits details about pagination, sorting, and filtering capabilities that are present in the input schema. The return format is not described.
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 only 43%, and the description adds no parameter-specific information. It does not explain how to use the 7 parameters effectively, leaving the agent to rely on incomplete schema documentation.
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 the resource 'tasks', and specifies the types of tasks returned (manual, call, sequence-triggered), distinguishing it from sibling tools like search_contacts or search_opportunities. The mention of 'FREE' adds clarity.
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 search_activities or search_sequences. The description does not provide context for appropriate use cases or exclusions, leaving the agent without decision-making support.
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 bears full responsibility for behavioral disclosure. It only mentions 'FREE' and 'Undocumented endpoint,' which hints at possible instability but does not disclose rate limits, authentication needs, pagination behavior, or potential side effects. This is insufficient for a tool without annotations.
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 at 4 sentences and includes essential information upfront. It is well-structured but lacks bullet points or clear separation of details; however, it remains efficient and easy to read.
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 tool has 3 parameters, no output schema, and no annotations, the description should provide more context. It explains the output (user IDs, names, emails) and the need for user IDs, but omits pagination behavior, the meaning of 'Undocumented endpoint,' and potential issues. This leaves gaps for an agent using the tool.
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 coverage is 33% with only q_keywords described in the schema. The description adds context about searching users and return fields but does not explain page or per_page parameters. It partially compensates for low schema coverage but not enough to provide complete parameter understanding.
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 it searches for team members/users in the Apollo workspace, returns user IDs, names, and emails, and explains the importance of user IDs for assigning tasks, deals, and contacts. This distinguishes it from sibling tools like search_people and search_contacts.
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 does not provide when or when not to use this tool versus alternatives. It mentions 'FREE' and 'Undocumented endpoint' but offers no guidance on context or exclusions. With many sibling search tools, explicit differentiation is missing.
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 provided. The description only mentions 'FREE' but does not disclose behavioral traits like whether updates are immediate, whether omitting a field clears it, or if the operation is idempotent.
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?
Two sentences, succinct and directly states the purpose. 'FREE' is extraneous but not detrimental.
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?
Missing information on return format, error handling, and which fields are updatable. With no output schema and many sibling tools, the description should provide more context but does not.
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?
Only one parameter (contact_id) has a description in the schema; the description does not compensate by explaining other fields or constraints. With 7% schema coverage and 15 parameters, the description adds minimal semantic value.
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 ('existing contact in Apollo CRM'), distinguishing it from create/delete tools. However, it could explicitly differentiate from bulk_update_contacts.
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?
Implies usage when you have an existing contact ID and want to modify specific fields, but lacks explicit guidance on when to use versus alternatives (e.g., search then update).
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 provided. Description only says 'FREE' and 'Undocumented endpoint' but does not disclose behavioral traits like side effects, required permissions, or safety. As a creation tool, mutation is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but disjointed with abrupt period between 'FREE' and 'At minimum'. Includes unnecessary 'Undocumented endpoint' phrase. Could be more polished.
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?
Lacks output information, error handling, prerequisites, and detailed behavior. Leaves gaps for a tool with 7 parameters and no annotations.
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%, so baseline is 3. Description adds minimal extra meaning by summarizing optional fields, but mostly restates schema info.
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?
Clearly states 'Create a new deal/opportunity' with specific verb and resource. Siblings are other create tools for different entities, so no 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?
No explicit when-to-use or alternatives. Only gives minimal parameter input guidance ('At minimum, provide a name'). Does not distinguish from other create tools.
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, the description only adds 'FREE' and 'Undocumented endpoint', which hint at cost and stability but omit critical details like authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but the extreme brevity sacrifices necessary operational detail, making it less effective than a slightly longer but more complete description.
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 output schema, the description fails to explain what is returned (e.g., the opportunity object) or any error behaviors, leaving the agent underinformed about the tool's full behavior.
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% for the single parameter 'opportunity_id', so the description doesn't need to add detail. The description adds no extra parameter meaning 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 'Get' and the resource 'single deal/opportunity by ID', distinguishing it from sibling tools that create or search opportunities.
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 search_opportunities or create_opportunity, nor does it mention prerequisites or limitations.
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 provided; description mentions 'FREE' but doesn't explain behavior like rate limits, auth, or default entity handling. Minimal beyond schema.
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?
Two sentences, front-loaded, no wasted words. Could be slightly more precise about entity types.
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?
Adequate for a simple list tool with one optional param, but doesn't describe output format or pagination; completeness is acceptable given sibling tool context.
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 coverage is 100% with enum and description, so baseline 3; but description misstates allowed values (omits 'opportunity'), actually adding less value than 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?
Clear verb 'List' and resource 'all available fields' for contacts and accounts, but the schema includes 'opportunity' which is omitted in the description, causing slight inconsistency.
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?
Indicates usefulness for understanding search/filter data, implying when to use, but lacks explicit when-not-to-use or alternatives among siblings like search tools.
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, the description must disclose behavior. It states 'Undocumented endpoint,' hinting at instability, but does not mention side effects, idempotency, duplicate handling, auth requirements, or what the tool returns. Minimal behavioral insight.
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?
Extremely concise: three sentences cover purpose, cost, utility, and a warning. No redundant information, and the main action is front-loaded.
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?
For a simple create tool with two parameters and no output schema, the description is mostly sufficient. However, it lacks details on duplicate name behavior, the structure of the response, and prerequisites, leaving some 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?
Schema coverage is 100% with clear parameter descriptions for name and modality. The description adds context that labels organize contacts and accounts, but this does not significantly enhance parameter meaning 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 'Create a new label' in Apollo, identifying the verb and resource. It distinguishes labels as organizing contacts and accounts, but does not explicitly differentiate from sibling tools like delete_label or update_label.
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 like delete_label or update_label. The description mentions it's FREE, but provides no context on prerequisites or appropriate scenarios.
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 provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or side effects. It only states the operation is a simple get, but without annotations, more transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. However, it could be structured with more context (e.g., read-only hint). Still, it lacks waste.
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?
No output schema and the description does not hint at return values or structure. For a simple get tool, some indication of what fields are returned would be helpful. Missing 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 has 100% coverage on the single parameter contact_id with description 'Apollo contact ID'. The tool description adds no extra meaning beyond the schema, so baseline of 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 'Get', resource 'single contact', and scope 'by ID from your Apollo CRM'. It distinguishes from sibling tools like search_contacts and create_contact.
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 vs alternatives, no prerequisites, and no context on when not to use it. Only mentions 'FREE' which is not usage advice.
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 provided, so description carries full burden. Mentions contacts will start receiving emails, but does not disclose side effects (e.g., what happens if contacts already in sequence? No mention of idempotency or failure modes). The 'FREE' tag is useful but not sufficient.
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?
Three sentences, efficient. 'FREE' is slightly out of place but not detrimental. No excess verbosity.
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?
Covers main operation and key required parameters, but lacks details on success/error behavior, rate limits, or handling of optional parameters. Output schema absent increases need for more context.
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 descriptions. Description reinforces requirement for email_account_id but adds little new meaning beyond 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?
Clear verb-resource combination ('Add contacts to an email sequence'). Specifies inputs needed (sequence ID, contact IDs). Does not explicitly differentiate from sibling tools, but the action is unique.
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?
States when to use (adding contacts to a sequence) and required parameters, but no explicit 'when not to use' or alternatives. Sibling tools do not include similar functionality.
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?
With no annotations, the description carries the burden. It discloses the endpoint is undocumented, implying potential instability, and states tasks can be associated with contacts. However, it does not detail mutation behavior, error handling, or idempotency, leaving gaps.
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 with three sentences, front-loading the purpose. Every sentence is necessary and there is no redundant information.
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 and no output schema, the description should hint at return value or behavior. It lacks information on response format, pagination, or side effects, making it incomplete for a creation tool.
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%, so baseline is 3. The description adds context like 'requires user_id' and association with contacts, but does not explain enum values beyond the schema. Added value is minimal.
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 creates a new task in Apollo, specifying verb and resource. However, it does not explicitly differentiate from sibling creation tools like create_note or create_contact, relying on the name for identification.
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 mentions 'FREE' and requires user_id, but provides no guidance on when to use this tool versus alternatives like update_task or create_note. No explicit when-to-use or when-not-to-use context is given.
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 must fully disclose behavior. It mentions permanence ('permanently removes') and says 'Undocumented but functional,' but lacks details on side effects, permissions, or error handling. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, but the third sentence 'Undocumented but functional' adds little value and may confuse. It is not as concise as it could be, though the first sentence is well front-loaded.
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 delete operation with one parameter and no output schema, the description covers the purpose and permanence. It is adequate, though it could mention that the contact must exist and what happens if the ID is invalid.
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 a clear description for the single parameter. The description does not add additional meaning beyond what the schema already provides, so baseline score 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 'Delete a contact from your Apollo CRM' with a specific verb and resource. It distinguishes from siblings like 'create_contact' and 'update_contact' by implying the destructive action.
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. For example, it does not mention scenarios where deleting is preferred over updating or archiving. No prerequisites or exclusions are provided.
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 must carry the full burden. It only states 'Undocumented endpoint,' hinting at instability, but does not disclose whether the deletion is irreversible or if there are any side effects.
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 extremely brief with one sentence, which is efficient, but it lacks detail that could be included without verbosity.
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?
For a simple delete operation with one parameter and no output schema, the description provides minimal context. The 'Undocumented endpoint' warning is useful, but it does not specify success behavior or return values.
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 a single parameter 'label_id' already described as 'Label ID to delete.' The description adds no additional meaning beyond what the schema provides.
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 'Delete a label from Apollo' clearly states the verb (delete) and resource (label), distinguishing it from sibling tools like create_label and update_label.
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 mentions 'FREE' and 'Undocumented endpoint' but does not provide explicit guidance on when to use this tool versus alternatives like delete_contact or delete_note.
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 must disclose safety and behavior. It mentions the tool is 'FREE' and 'Undocumented endpoint', giving some insight, but lacks details on rate limits, side effects, or expected response structure. The list of returned activity types is useful.
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 with three sentences, no redundant information, and gets to the point quickly. The 'UNDOCUMENTED ENDPOINT' note is a quick warning but could be integrated more smoothly.
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 7 parameters without an output schema, the description is insufficient. It omits details about sorting, pagination, response limits, and the structure of returned data, leaving the agent unprepared for invocation.
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 only 43%; the description adds no additional parameter meaning beyond what the schema provides. Parameters like sort_by_field and pagination are left unexplained, and the description does not clarify their usage or format.
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 activity logs in Apollo workspace and lists specific types of activities returned (email sends, opens, clicks, etc.). This distinguishes it from sibling tools that search contacts, accounts, or sequences.
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 only vaguely says 'useful for monitoring outreach performance' without providing explicit guidance on when to use this tool versus alternatives like get_email_activities or search_outreach_emails. No exclusions or prerequisites are mentioned.
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 burden. It mentions 'COSTS CREDITS,' which is a behavioral trait. However, it does not disclose other aspects like authorization needs, rate limits, or what happens upon execution (e.g., data returned). The cost note is helpful but incomplete.
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 concise with two sentences: one for purpose and one for usage and cost. Every sentence adds value, and the important note about credits is 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 the lack of output schema and annotations, the description is too brief. It does not explain return format, pagination behavior, or how to effectively combine the parameters. The use case is provided but not enough context for an agent to fully understand the tool's behavior.
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 50% (page and per_page lack descriptions). The tool description does not compensate by explaining these parameters or how they work together. The description adds no meaning beyond the schema for the covered parameters, leaving a gap for users.
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 news articles about companies in Apollo's database. It distinguishes from sibling tools like search_contacts or search_activities, which search different entities. However, it could be more specific about the scope (e.g., 'recent news' is vague).
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 gives a use case ('finding recent news about target companies for personalized outreach') but does not explicitly state when to use it vs. alternatives, nor any conditions where it should not be used. The guidance is implied but not explicit.
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, the description must disclose behavior. It states returns fields but fails to mention read-only nature, pagination details, or any side effects. Incomplete for safe agent usage.
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 very concise—one sentence with key info. However, it could be restructured to separate behavioral notes from return fields for better clarity.
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 5 optional parameters and no output schema, the description is minimal. It fails to explain pagination behavior, default sort, or response structure beyond listing a few fields.
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 low (40%), and the description does not explain parameter semantics beyond the schema. It adds no examples or clarification for sort_by_field or pagination params.
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 identifies the verb 'Search' and the resource 'email sequences (campaigns)' in Apollo. It distinguishes from sibling tools like update_sequence_status by focusing on search and return fields.
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 mentions 'FREE' but provides no explicit guidance on when to use this tool over other search tools (e.g., search_people). Usage context is implied but no exclusions or alternatives are given.
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 burden. It discloses the batch limit and that it updates contacts, but does not explain if the operation is idempotent, what happens on errors, or the return format (e.g., success response). This is adequate but minimal.
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 very concise with three short sentences. The first sentence clearly states the purpose. The inclusion of 'FREE' is extraneous but not harmful, keeping the overall structure clean.
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 output schema or annotations, the description is incomplete for a mutation tool. It lacks information about return values, error handling (e.g., partial failures), and any side effects. The 100-item limit is helpful but behavioral details are missing.
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% (the array parameter has a description), so baseline is 3. The tool description adds 'Provide contact IDs and fields to update' which largely restates the schema, adding little new meaning.
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 'Update multiple contacts at once' which distinguishes it from single-contact update tools like 'update_contact'. It also specifies the key inputs (contact IDs and fields), making the purpose clear.
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 mentions 'Max 100 per request' which gives a constraint, but does not provide guidance on when to use this tool versus alternatives like 'update_contact' for single updates. No when-not or explicit comparison is given.
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?
The description labels the tool as 'FREE' and 'Undocumented endpoint', hinting at cost and reliability characteristics. However, it lacks details on read-only behavior, error responses, or required permissions, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It directly states the purpose and adds two metadata tags ('FREE', 'Undocumented endpoint') without sacrificing clarity.
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?
For a simple get-by-ID tool, the description is minimally adequate but lacks details on return value, error handling, and prerequisites. The 'undocumented endpoint' note introduces uncertainty about stability.
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% for the single parameter ('Apollo task ID'). The description adds no further meaning beyond the schema, so baseline score applies.
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 ('Get a single task by ID') and identifies the resource (task). It specifies the identifier method, but does not differentiate from sibling tools like 'search_tasks' or 'update_task'.
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. For example, it does not mention that this tool retrieves a single task by ID while 'search_tasks' may be used for filtering or listing tasks.
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 only states that the tool is read-only ('List') and notes 'Undocumented endpoint', which hints at potential instability but offers no detail on behavior, permissions, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes filler ('FREE', 'Undocumented endpoint') that does not add value. It could be more concise by focusing on the core action and label purpose. Front-loading is present with the action verb.
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 simple nature (no parameters, no output schema), the description adequately states the functionality and label purpose. However, it omits any mention of output format, limitations, or whether labels are hierarchical. 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?
The input schema has zero parameters with 100% coverage, so the description needs no parameter details. It adds context about labels' purpose, which is helpful but not required for parameter semantics. Baseline for 0 parameters is 4.
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 explicitly states 'List all labels' with synonyms 'tags/lists' and specifies the workspace context. It clearly distinguishes this list operation from sibling tools like create_label and delete_label.
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 (e.g., list_account_stages, list_contact_stages). The description does not provide usage context or exclusions, leaving the agent without decision support.
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 provided, so description carries full burden. Mentions it's free and undocumented, hinting at potential instability. However, fails to disclose read/write nature, rate limits, authentication needs, or pagination behavior. Significant gaps for a search tool.
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?
Three sentences, front-loaded purpose. No wasted words. The warning about undocumented endpoint is relevant but could be integrated. Overall efficient for a simple search 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?
Covers purpose, return types, and a caution. Lacks detail on pagination, result structure, error handling, and how it fits among siblings. With no output schema, more context would be beneficial. Adequate but incomplete.
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 coverage is 50% (user_id and contact_id described in schema; page and per_page only have constraints). Description adds no additional meaning for parameters, doesn't explain page/per_page functionality or expected values. Does not compensate for schema gaps.
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?
Description clearly states 'Search phone call logs' with specific verb and resource. It distinguishes from siblings like search_contacts and search_activities by focusing on phone calls. Mentions return types (records, durations, outcomes) adding 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?
Indicates it's free and an undocumented endpoint, but lacks explicit when-to-use vs alternatives or prerequisites. Does not guide on when to use this over other search tools, though the name implies phone call-specific scope.
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 provided, so the description must disclose behavioral traits. It states cost and max batch size, but omits safety profile, error behavior, authentication needs, or whether the operation is idempotent. This is insufficient for a billing-related 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?
Two sentences with no fluff, front-loaded with purpose and key constraints. Every word earns its place.
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?
No output schema exists, so the description should cover return values, but does not. Given the complexity (nested parameter, billing implications), more context on errors, partial successes, and field requirements is needed for 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 coverage is low (33%), but the description adds context for the 'details' parameter by specifying it should contain identifying info (name, domain, email, linkedin_url). The boolean parameters are not explained, so the description provides partial added value.
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 explicitly states the tool enriches multiple people in a single request. It distinguishes from singletons like 'enrich_person' and other sibling tools by highlighting the batch capability and cost structure.
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 when to use (for batch enrichment) but does not provide explicit when-not scenarios or alternatives. It mentions max 10 people and cost per person, but lacks guidance on when to prefer this over single enrichment or search tools.
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 must disclose behavioral traits. It mentions the two modes (remove vs stop) but does not explain side effects, reversibility, or required permissions, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no extraneous words. Every sentence adds value.
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?
No output schema, and the description does not mention return values, error handling, or batch behavior. For a tool with 3 required params, it lacks sufficient context beyond the basic action.
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%, so baseline is 3. The description does not add meaning beyond the schema; the parameters are already well-documented in the input 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 action ('Remove or stop contacts in a sequence') and the specific resource (contacts in a sequence). It distinguishes from sibling tools like add_contacts_to_sequence by its opposite purpose.
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 says 'Use this to pause or remove contacts from an active sequence,' which provides clear context but lacks explicit when-not-to-use guidance or alternatives.
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?
Mentions 'FREE' and 'undocumented endpoint', providing some transparency about cost and stability, but lacks details on side effects or required permissions.
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?
Extremely concise with no wasted words; front-loads the essential 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?
For a simple two-parameter update tool with no output schema, the description is minimally adequate but omits return value or success criteria.
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%, so parameters are already described. The description adds no additional meaning beyond the schema (e.g., type or format constraints).
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?
Clearly states verb ('update'), resource ('label'), and specific attribute ('name'), distinguishing it from create_label and delete_label among siblings.
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 like create_label or delete_label. No context about prerequisites or appropriate scenarios.
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?
Without annotations, the description carries full burden. It states the tool returns email messages with status, open/click tracking, and content, which implies a read-only operation, but does not explicitly confirm safety or disclose rate limits, destructive potential, or other side effects. The word 'FREE' is ambiguous but suggests no cost.
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: two sentences with no filler. It front-loads the purpose and immediately adds key return details. Every word adds value.
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 absence of an output schema, the description adequately covers what the tool returns (email messages with status, open/click tracking, content). It does not explain pagination or result limits, but the parameters (page/per_page) cover that. Sibling tools are many, but the description's focus on outreach emails and sequence context provides sufficient differentiation.
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 all 5 parameters with clear filter purposes (e.g., 'Filter by sequence/campaign ID'). The description does not add further meaning beyond the schema, and with 60% schema description coverage, it moderately compensates by stating the tool returns email messages with tracking data, but not specific parameter combinations or usage tips.
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 outreach emails sent through Apollo sequences, with specific verb 'Search' and resource 'outreach emails'. It distinguishes from sibling search tools like search_activities or search_contacts by referencing Apollo sequences and mentioning return of tracking data.
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, such as search_activities or search_phone_calls. It does not mention prerequisites, limitations, or typical use cases, leaving the agent to infer context.
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?
The description notes the credit cost (a behavioral trait) but lacks details on error handling, pagination, or rate limits. With no annotations, more transparency is needed.
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 and front-loaded with purpose. The all-caps 'COSTS 1 CREDIT' is slightly jarring but overall efficient.
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 provides necessary context: purpose, cost, and a use case. Minor gap in return format.
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 a clear description for the only parameter. The tool description adds minimal extra meaning beyond what the schema provides.
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 'current job postings for an organization', distinguishing it from sibling tools which focus on contacts, accounts, etc.
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 mentions the credit cost and suggests use for understanding hiring priorities, but does not explicitly state when to use or avoid using this tool, nor compare with alternatives.
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 indicates a read-only list operation but does not mention authentication needs, rate limits, or whether the endpoint is stable. The phrase 'Undocumented endpoint' hints at potential instability but lacks explicit safety or side-effect info.
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: one core sentence plus two brief notes ('FREE.' and 'Undocumented endpoint.'). It is front-loaded with the main action and purpose, 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?
For a simple tool with no parameters and no output schema, the description adequately states the purpose and the nature of the output (stage IDs). However, it does not describe the response format or provide any details about the staging system, leaving some ambiguity about what exactly is 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?
The tool has no parameters, so schema coverage is 100% by default. The description adds value by explaining what the output (stage IDs) is used for, which helps the agent understand the purpose beyond the empty 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 'List' and the resource 'all account stages', and explains the purpose of using the stage IDs for creating or filtering accounts. It distinguishes from sibling tools like 'list_contact_stages' by specifying 'account stages'.
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 mentions that the stage IDs are used when creating or filtering accounts, implying a use case, but it does not explicitly state when to use this tool versus alternatives like list_contact_stages or list_opportunity_stages. No guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It mentions deduplication and a size limit but omits important details like error handling, atomicity, or response format. For a bulk creation 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?
Three concise sentences with no redundancy. Critical details are front-loaded: purpose, cost, dedup, limit.
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 description lacks information about return values, success/failure indications, and partial success behavior. Given no output schema and no annotations, the description should provide a more complete picture for a bulk operation.
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%, so the description adds value by noting 'FREE,' 'Deduplication is enforced,' and 'Max 100,' which are not in the schema. This helps the agent understand constraints beyond the property definitions.
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 explicitly states 'Create multiple contacts at once,' clearly identifying the action (create) and resource (contacts). The bulk aspect distinguishes it from sibling tools like 'create_contact' (singular).
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 this tool (bulk creation) but does not explicitly mention alternatives or when to avoid it. However, the presence of 'Max 100 contacts per request' sets a clear constraint.
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?
Without annotations, the description must convey behavioral traits. It mentions 'FREE' and that the domain 'will be auto-cleaned', but does not disclose permissions, idempotency, or side effects of creating the record.
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, front-loaded sentences with no wasted words. Every sentence adds value: action, resource, cost, minimal requirements.
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 sufficiently explains the tool's purpose and basic requirements. It could mention what the created account looks like or error cases, but overall adequate.
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%, so parameters are well-documented. The description adds marginal value: only 'will be auto-cleaned' for domain and a redundant example. Baseline 3 applies.
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 'Create' and the resource 'account (company record) in your Apollo CRM', distinguishing it from update and other account-related tools. The mention of 'FREE' adds a unique selling point.
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?
It advises to 'provide at least the name and domain', but the schema only requires 'name'; 'domain' is optional. No explicit guidance on when to use this vs alternatives like 'update_account' or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'FREE' but does not disclose behavioral traits such as read-only nature, rate limits, pagination behavior, or data freshness. For a search tool without annotations, more disclosure is needed.
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?
Three sentences, front-loaded with key verb and resource, no filler. Every sentence adds value.
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?
Covers usage guidance well and distinguishes from sibling. However, without output schema, description could mention return format (e.g., list of contacts with pagination). Slightly incomplete.
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 (100% of 6 parameters have descriptions in the schema). The description adds no extra meaning beyond what the schema provides, so baseline of 3 applies.
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?
Clearly states verb (Search) and resource (contacts in your Apollo CRM). Explicitly distinguishes from sibling search_people by specifying scope: already saved contacts vs global database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (for saved contacts) and when not (for prospecting, use search_people). Provides direct alternative tool name.
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 states 'Max 10 results per page,' but the input schema allows per_page up to 100, contradicting this claim. This undermines transparency. It does disclose free status and return fields, but the contradiction is significant.
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 relatively concise, covering purpose, cost, return fields, alternatives, and filter support in a few sentences. It is front-loaded with the key point. However, the inaccurate 'Max 10 results per page' detracts from overall quality, preventing a 5.
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 18 parameters and no output schema, the description provides a good high-level overview but fails to accurately describe pagination limits (misleading 'max 10') and omits details about additional return fields beyond the stated four. This is adequate but not fully comprehensive.
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%, so each parameter is described in the schema. The description adds value by summarizing supported filters ('title, company, location, seniority, and more') and noting free usage, which helps the agent prioritize. This exceeds the baseline of 3 for high schema coverage.
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 people in Apollo's database, specifies it is free, and distinguishes it from enrich_person by noting what it returns (name, title, company, LinkedIn URL) and what it does not (email/phone). The phrase 'primary discovery tool' reinforces its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it (primary discovery, free) and when not to (for email/phone, use enrich_person instead, which costs credits). It also mentions alternatives like enrich_person, providing clear guidance.
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?
With no annotations provided, the description must disclose behavioral traits. It mentions deduplication is enforced, which is a key behavior. But it does not address authentication requirements, rate limits, whether it is a destructive operation, or what happens on duplicate (error vs. update). The description is adequate but not comprehensive.
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 two clear sentences. It front-loads the core purpose and then adds key details (FREE, deduplication, minimum requirements). Every sentence adds value without 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 14 parameters and no output schema, the description covers the most important aspects (purpose, deduplication, required fields). However, it lacks information about response format, error handling for duplicates, and the effect of optional parameters like account_id or phone_numbers on the creation process. It is reasonably complete but has gaps.
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 71%, and the description adds critical context beyond the schema: it clarifies that deduplication is enforced (run_dedupe=true) and that either email or organization_name is required in addition to first_name and last_name. This provides guidance on parameter combinations not evident from the schema alone.
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 creates a new contact in Apollo CRM, and the context of sibling tools like 'bulk_create_contacts' and 'update_contact' helps distinguish it. The verb-create and resource-contact are explicit.
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 specifies required minimum fields (first_name, last_name, and email or organization_name), indicates deduplication is enforced, and mentions it is FREE. However, it does not explicitly state when to use this vs. alternatives like bulk_create_contacts or search_contacts for finding existing contacts.
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 adds that the endpoint is 'FREE' and 'Undocumented', hinting at stability issues, but lacks details on authentication, rate limits, or any side effects.
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?
Three sentences, each serving a purpose: listing function, providing examples, explaining ID usage, and warning about documentation. No superfluous text.
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 tool is simple (no params, no output schema), the description could be more complete by specifying the output format (e.g., includes both ID and name) or indicating required authentication. It is adequate but not thorough.
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?
With zero parameters, the baseline is 4. The description adds no extra parameter info, but the schema covers all (none).
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 lists all opportunity stages in the Apollo pipeline, with examples. It implicitly distinguishes from sibling tools like list_account_stages by specifying 'opportunity stages'.
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?
It explains to use the returned stage IDs when creating or filtering opportunities, providing clear context. However, it doesn't explicitly mention when not to use this tool or compare it to alternatives.
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 credit cost per match and hints at matching behavior, but does not explain failure scenarios (e.g., if no match found, does it still cost?), or whether the tool is read-only or modifies data. It lacks details on rate limits or authentication requirements.
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 concise with two lines. The first line states the core purpose ('Enrich a single person...'), and the second covers critical usage details (cost, required fields). No unnecessary words, and information is front-loaded.
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 9 parameters fully described in schema, no output schema, and no nested objects, the description adequately covers the tool's function and input requirements. It lacks explicit output structure details but the intended output (email, phone, profile) is clear from the purpose. Minor gap in explaining what 'detailed profile' includes.
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 description coverage is 100%, so baseline is 3. The description adds value by highlighting important combinations (name+domain, LinkedIn URL, email) and mentioning credit cost, which goes beyond the schema's parameter descriptions. It gives actionable advice for effective use.
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: 'Enrich a single person to get their email, phone, and detailed profile.' It uses specific verbs ('Enrich', 'get') and identifies the resource ('single person'). It distinguishes from siblings like 'bulk_enrich_people' by specifying 'single person'.
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 provides clear guidance: costs 1 credit, requires name+domain, LinkedIn URL, or email, and suggests providing as many fields as possible. However, it does not explicitly state when not to use this tool or mention alternatives like 'bulk_enrich_people' for multiple enrichments.
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 provided, so description bears the burden. Mentions 'FREE' and 'Undocumented endpoint', providing some behavioral context (cost and stability). However, does not explicitly state it's read-only or safe, though the action implies it.
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, front-loaded with action and examples. Every word is informative with no redundancy.
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?
Covers purpose and usage well. Provides examples and hints at output contents. Could mention output format (e.g., list of objects), but acceptable for a simple tool with no 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?
No parameters in the schema, so baseline is 4. The description does not need to add further parameter information.
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?
Clearly states the action (list), resource (contact stages), and context (Apollo pipeline). Includes examples (Cold, Approaching, Replied) for clarity. Implicitly distinguishes from sibling tools like list_account_stages by specifying 'contact stages'.
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?
Explicitly directs to use stage IDs when creating or filtering contacts. Does not mention alternatives or when not to use, but the purpose is clear enough for the agent to infer.
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 provided, so description carries full burden. Mentions deprecation and free status, but does not explicitly state that it is a read-only operation or any side effects.
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 with no wasted words. Front-loaded with purpose and immediate distinction from sibling.
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 parameterless tool with no output schema, the description covers purpose, deprecation, and preference. Return format is implicit for a list operation.
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, and schema coverage is 100%. Baseline score of 4 is appropriate as description adds no parameter info, which is not needed.
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?
Clearly states it lists custom fields using a legacy endpoint, and distinguishes from sibling 'list_fields' by noting a preference for the newer tool.
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?
Explicitly advises to prefer list_fields, giving clear usage guidance. Does not provide when-not-to-use scenarios, but the preference implies it.
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 provided, so description carries full burden. Discloses that it lists all accounts, is free, and requires a master API key. Does not mention potential side effects, rate limits, or what happens when no accounts exist. Adequate for a simple read tool but could be more comprehensive.
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?
Three concise sentences, front-loaded with purpose, and every sentence provides essential information (what, why, prerequisite). No redundancy or filler.
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 and zero parameters, the description covers the core functionality, use case, and requirements. It implies the return of email_account_id, but could explicitly state that the response includes IDs. Still sufficiently complete for a simple list tool.
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?
Tool has zero parameters, so schema coverage is 100%. According to guidelines, baseline is 4. Description does not need to add param details, and it mentions the key output (email_account_id) indirectly.
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?
Clearly states the tool lists email accounts, specifies the context (Apollo workspace), and explicitly connects it to finding email_account_id for add_contacts_to_sequence. This directly informs the agent of the tool's role and output.
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?
Indicates when to use (to get email_account_id for add_contacts_to_sequence) and mentions a prerequisite (requires a master API key). Does not provide explicit alternatives or when-not-to-use, but the sibling set is large and the purpose is distinct enough.
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 provided, so the description carries the burden. It discloses that the endpoint is undocumented and returns basic account info, but does not explicitly state it is read-only or mention any side effects. For a health check, the assumed safe behavior is implied but not confirmed.
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 with two short sentences. It front-loads the core purpose ('Check Apollo API health and verify your API key is working.') and adds essential context (FREE, input/output, undocumented). No wasted words.
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?
For a zero-parameter health check tool with no output schema, the description fully covers what the tool does, its output, and an important caveat (undocumented endpoint). It is complete given the tool's simplicity.
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 no parameters, so schema coverage is effectively 100%. The description does not need to add param info. Baseline for 0 params is 4, and no additional clarification is required.
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: checking Apollo API health and verifying API key. It uses a specific verb ('Check') and resource ('Apollo API health'), and distinguishes from sibling tools which focus on specific CRUD 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 indicates when to use this tool (to check health and verify key) and notes it is free and returns account info, but does not explicitly state when not to use or provide alternatives. However, for a simple health check, this is adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses cost (1 credit) and output details (company size, industry, etc.), and notes domain auto-cleaning. It lacks disclosure on rate limits or side effects, but for a read-like enrichment tool, this is satisfactory.
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 sentences, zero waste. The first sentence states purpose and cost, the second lists output. Essential information is front-loaded.
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 adequately lists key returned fields. It could mention error cases or partial enrichment, but is complete for a simple enrichment tool.
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 already describes domain with 100% coverage. The description adds value by implying the tool works on a single organization and listing returned fields, though parameter specifics are already clear.
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 uses specific verb 'enrich' and resource 'organization by domain', clearly stating the action. It distinguishes from siblings like 'enrich_person' and 'bulk_enrich_people' by specifying 'single organization'.
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 mentions credit cost, which is key usage context. However, it does not explicitly state when to use this tool versus batch alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses cost (1 credit per page) and highlights the free alternative. It does not detail other behavioral aspects like pagination or response format, but the cost disclosure is important and well-communicated.
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?
Three sentences: purpose, cost, usage guidance. Front-loaded, no wasted words, and well-organized. Every sentence adds value.
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 complexity (9 parameters, no output schema), the description covers the primary purpose and cost effectively. However, it lacks description of the response structure or what data is returned, which is a minor gap for a search tool.
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%, so all parameters are documented. The description adds no additional parameter-level meaning beyond the schema; it only adds the cost context. 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?
Description clearly states it searches for organizations/companies and distinguishes from sibling 'search_people' by noting cost and specific use case (company-level data like revenue, tech stack, funding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer 'search_people' (free) when possible and specifies when to use this tool: for company-level data. This provides clear guidance on when to use versus alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that the tool is read-only (gets stats) and mentions it is FREE. It does not explicitly state it is non-destructive, but the context implies a safe read operation. For a zero-parameter tool, this is sufficiently transparent.
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 two sentences with no wasted words. It includes the purpose, the data shown, and a usage tip. Every sentence provides value.
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?
Given no output schema, the description explains what is returned (credit usage, remaining credits, rate limit info). It also adds context for when to use (verify API key). With zero parameters and simple semantics, the description is fully 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 no parameters in the input schema, so the baseline score of 4 applies. The description does not need to add parameter details, and it does not mislead.
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 purpose: 'Get API usage statistics for your Apollo account'. It specifies what is shown (credit usage, remaining credits, rate limit info) and suggests a use case. This distinguishes it from all sibling tools, which are about contacts, sequences, etc.
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 provides explicit guidance: 'Call this first to verify your API key works.' This tells the agent when to use it. There are no alternative tools for this purpose, so exclusion is naturally handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds value by stating 'FREE -- no credit cost.' It doesn't disclose read-only nature or rate limits, but for a simple get tool, it's adequate.
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 informative sentences with no wasted words. The purpose and usage guidelines are front-loaded.
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?
Given the tool's simplicity (one parameter, no output schema), the description fully covers what the agent needs to know to use it correctly.
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% and the description does not add extra semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details for an organization using an Apollo ID. It distinguishes from sibling tools like search_organizations by implying the ID is already known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you already have the organization ID from a previous search,' guiding the agent on when to invoke this tool vs. searching.
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-io-mcp MCP server](https://glama.ai/mcp/servers/Inferensys/apollo-io-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Inferensys/apollo-io-mcp)

Score Badge

Copy to your README.md:

[![apollo-io-mcp MCP server](https://glama.ai/mcp/servers/Inferensys/apollo-io-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Inferensys/apollo-io-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/Inferensys/apollo-io-mcp'

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