Apollo 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 distinct purposes, but there is some overlap between 'contacts_search' and 'people_search' (both search contacts, though one targets the user's database and the other Apollo's global database), and between 'sequence_activate' and 'workflow_activate' (both activate/deactivate automation). Descriptions help clarify, but agents might occasionally confuse these pairs.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'analytics_email_accounts', 'contacts_search', 'deal_create'). The naming is predictable across all 34 tools, making it easy for agents to understand and navigate the set.
Tool Count3/5
With 34 tools, the count is borderline high for a CRM/outreach server, as it may feel heavy and complex for agents to manage. While it covers many aspects (analytics, contacts, deals, emails, sequences, tasks, workflows), some consolidation or scoping might improve usability without sacrificing functionality.
Completeness5/5
The tool set provides comprehensive coverage for Apollo's domain, including CRUD operations for contacts, deals, lists, sequences, tasks, and workflows, plus enrichment, search, analytics, and email capabilities. There are no obvious gaps; agents can perform end-to-end workflows from prospecting to automation.
Average 3.4/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves analytics (implying a read-only operation) but doesn't cover permissions, rate limits, data freshness, or response format. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose statement followed by Args and Returns sections. It avoids redundancy, though the Args section could be more informative. The front-loaded purpose is clear, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (analytics retrieval), no annotations, and an output schema (which covers return values), the description is minimally adequate. It states the purpose and parameters but lacks behavioral details and usage context, leaving room for improvement in 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?
The description adds minimal semantics beyond the input schema: it notes 'sequence_ids' is optional and for filtering, but the schema already shows it's optional with a default of null. With 0% schema description coverage, the description doesn't compensate by explaining format, constraints, or examples. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get analytics for email sequences.' It specifies the verb ('Get') and resource ('analytics for email sequences'), which is straightforward. However, it doesn't differentiate from sibling tools like 'analytics_email_accounts' or 'sequence_get', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analytics_email_accounts' for account-level analytics or 'sequence_get' for non-analytics sequence details, nor does it specify prerequisites or exclusions. Usage context 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?
No annotations are provided, so the description carries the full burden. It mentions pagination and filtering by stage_id, which are useful, but lacks details on permissions required, rate limits, error handling, or what the 'List of deals' output entails (e.g., format, fields). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by Args and Returns sections. It's front-loaded and uses minimal sentences, though the formatting with quotes and indentation could be slightly cleaner for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, and an output schema exists (which should cover return values), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context like auth needs or error cases, making it adequate but with clear gaps for a listing 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 description coverage is 0%, so the description must compensate. It lists the three parameters (page, per_page, stage_id) with brief explanations, adding meaning beyond the schema's titles. However, it doesn't provide details like valid ranges for page/per_page or what stage_id values are acceptable, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'deals/opportunities in your Apollo pipeline', which is specific and unambiguous. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'deal_create' or other list tools, though the context suggests it's the primary deals listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'deal_create' for creating deals or other filtering options beyond stage_id, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'Add contacts' which implies a mutation operation, but doesn't disclose important behavioral traits like whether this requires specific permissions, if it's idempotent, what happens with invalid contact IDs, rate limits, or error handling. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by structured parameter documentation. The three-line format (purpose, args, returns) is efficient and front-loaded. However, the 'Returns: Confirmation' line is redundant since there's an output schema, making it slightly wasteful.
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 mutation tool with 2 parameters, 0% schema description coverage, and no annotations, the description is minimally adequate but incomplete. It covers the basic purpose and parameters but lacks behavioral context, usage guidelines, and error handling information. The existence of an output schema reduces the need to describe return values, but other gaps remain significant.
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 description explicitly documents both parameters (list_id, contact_ids) with brief explanations, which adds value since schema description coverage is 0%. However, the explanations are minimal ('List ID', 'Contact IDs to add') and don't provide format details, constraints, or examples that would help the agent use them correctly.
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 ('Add contacts to a list') with specific verb+resource, making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'sequence_add_contacts' or explain how it differs from other list-related operations like 'list_create' or 'lists_get'.
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. There's no mention of prerequisites (e.g., needing an existing list), exclusions (e.g., cannot add duplicate contacts), or comparison to similar tools like 'sequence_add_contacts' or 'contacts_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination parameters but doesn't disclose important behavioral traits like whether this is a read-only operation, what authentication is required, rate limits, or what happens when no lists exist. The description is minimal on behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses minimal sentences. Each section earns its place, though the 'Returns' section could be slightly more informative given the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage but an output schema exists, the description compensates somewhat by documenting parameters. However, for a tool with no annotations, it lacks behavioral context like safety, permissions, or error handling, making it minimally adequate but with clear 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 description coverage is 0%, but the description explicitly documents both parameters (page and per_page) with brief explanations. This adds meaningful context beyond the schema's titles, though it doesn't provide format details or constraints. With 2 parameters fully mentioned, this meets the baseline for adequate 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 'Get all saved lists in Apollo' which specifies the verb (get) and resource (saved lists) with scope (all). It doesn't explicitly differentiate from sibling tools like 'list_create' or 'list_add_contacts', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the description implies it retrieves all saved lists, there's no mention of when to use this versus other list-related tools like 'list_create' or 'list_add_contacts' in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination parameters and status filtering, but doesn't cover critical aspects like whether this is a read-only operation, authentication requirements, rate limits, error handling, or what 'List of tasks' entails structurally. For a list tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly, though the formatting with quotes and indentation could be cleaner. 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 that there's an output schema (which should cover return values), no annotations, and moderate complexity with 3 parameters, the description is minimally adequate. It explains the purpose and parameters but lacks behavioral context and usage guidelines, making it incomplete for optimal agent operation.
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 description adds parameter semantics by explaining 'page' as 'Page number', 'per_page' as 'Results per page', and 'status' with allowed values 'pending, completed'. Since schema description coverage is 0%, this compensates somewhat, but it doesn't fully detail parameter constraints or interactions beyond basic definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'tasks in your Apollo account', making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'deals_list' or 'workflows_list' beyond specifying it's for tasks, so it lacks explicit sibling differentiation.
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. There are no mentions of prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'task_create' or other list tools, leaving the agent to infer 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention permissions required, whether it's idempotent, rate limits, or what happens if the template ID is invalid. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter and return value sections. Every sentence serves a purpose, though the parameter explanations could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations, 2 parameters (one required), and an output schema exists, the description is minimally adequate. It covers the basic operation and parameters but lacks important context about permissions, error conditions, and differentiation from sibling tools.
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 description explicitly lists both parameters with brief explanations, adding meaningful context beyond the schema (which has 0% description coverage). However, it doesn't explain where to find template IDs, what format they use, or constraints on the optional name parameter, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new workflow from a template'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'workflow_create' (which presumably creates workflows without templates), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'workflow_create' or 'workflow_templates_list'. It mentions the need for a template ID but doesn't explain how to obtain one or when this method is preferred over creating workflows from scratch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it deletes a workflow. It lacks critical behavioral details: whether deletion is permanent/reversible, permission requirements, side effects (e.g., related data removal), or error conditions (e.g., invalid ID handling).
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 front-loaded with the core action ('Delete a workflow') and uses a structured Args/Returns format efficiently. However, the Returns statement is vague ('Confirmation of deletion') and could be more precise without adding bulk.
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 destructive tool with 1 parameter, no annotations, and an output schema (which should cover return values), the description is minimally adequate. It states the action and parameter but misses behavioral context (e.g., irreversibility) and usage guidance, leaving gaps for safe agent operation.
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 0%, but the description adds minimal semantics by naming 'workflow_id' and stating it's 'The workflow ID to delete'. This clarifies the parameter's role beyond the schema's title 'Workflow Id', though it doesn't specify format or sourcing (e.g., from workflows_list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'workflow', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'workflow_update' or 'workflow_get' beyond the obvious action difference, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing workflow_id from workflows_list), exclusions (e.g., cannot delete active workflows), or comparisons with siblings like workflow_update for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return content but doesn't cover critical aspects like whether this is a read-only operation, authentication needs, rate limits, or error handling, which are essential for safe and effective use.
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 brief and front-loaded, with the main purpose stated clearly in the first sentence. The second sentence about returns is slightly redundant given the output schema, but overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema provided), the description is adequate but incomplete. It lacks behavioral context like safety or performance traits, which is a gap since no annotations are present to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids redundant parameter details, earning a high baseline score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('email account health and deliverability stats'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'analytics_sequences' or 'email_preview', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other analytics or email-related tools in the sibling list. It lacks context about prerequisites, timing, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation but doesn't disclose any behavioral traits: no information about permissions needed, whether this is a mutating/destructive operation, rate limits, error conditions, or what happens on success/failure. The description only covers basic functional intent without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The Args/Returns sections are structured clearly. However, the 'Returns' section could be more specific than 'Created deal details', and there's some redundancy between the description and parameter documentation.
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 this is a creation tool with 5 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is moderately complete. It explains parameter semantics well and mentions returns, but lacks behavioral context and usage guidelines. The output schema existence means the description doesn't need to detail return values, but other gaps remain.
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 0%, so the description must compensate. It provides clear semantic meaning for all 5 parameters beyond their schema titles, explaining what each represents (e.g., 'Deal name', 'Account/company ID', 'Deal value'). This adds significant value over the bare schema. However, it doesn't explain format constraints or provide examples.
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 deal/opportunity' which is a specific verb+resource combination. It distinguishes this tool from sibling tools like 'deals_list' (which lists deals) and 'task_create' (which creates tasks). However, it doesn't explicitly differentiate from other creation tools like 'list_create' or 'workflow_create' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing account_id), when not to use it, or what other tools might be appropriate for related operations. The agent must infer usage from the tool name and description alone.
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 only states what the tool returns ('List of contact stages') but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose in the first sentence, followed by a clear returns statement. It avoids unnecessary fluff, though the formatting with extra whitespace could be slightly improved for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values) and no parameters, the description is minimally adequate. However, it lacks context on how contact stages fit into pipeline management or relate to other tools, leaving gaps in understanding the tool's role in the broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids redundancy, earning a high baseline score for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get available contact stages for pipeline management,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_account_stages' or 'get_available_fields,' which might have overlapping or related functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for pipeline management, or how it relates to sibling tools such as 'contacts_search' or 'deal_create,' leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create a new list' implies a write/mutation operation, it doesn't address important behavioral aspects like required permissions, whether creation is idempotent, rate limits, or what happens on duplicate names. The return statement is minimal and doesn't describe the structure or content of 'Created list details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations and return information. Every sentence serves a distinct purpose with zero wasted words, and the information is appropriately front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a creation/mutation tool with no annotations but with an output schema (which handles return value documentation), the description provides adequate basic information but lacks important contextual details. It covers the what and basic parameters but misses behavioral context like permissions, idempotency, and error conditions that would be important for a write operation.
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?
With 0% schema description coverage, the description adds meaningful semantic context for both parameters: it explains that 'name' is the list name and 'modality' defines the list type with specific allowed values ('contacts', 'people', or 'static') and a default. This compensates somewhat for the schema's lack of descriptions, though it doesn't fully explain the implications of each modality choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('a new list'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling list-related tools like 'lists_get' or 'list_add_contacts', which would require more specific scope definition.
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. With sibling tools like 'lists_get' (likely for reading lists) and 'list_add_contacts' (likely for modifying existing lists), there's no indication of when creation is appropriate versus retrieval or modification, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't specify permissions, rate limits, or what 'current' means (e.g., time frame, active vs. archived). For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The 'Useful for' sentence adds value, and the Args/Returns sections are clear, though slightly redundant with the output schema. No wasted sentences, but minor structural improvements could integrate information more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral aspects like data freshness or error handling, which would be helpful despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by specifying it's an 'Apollo organization ID', which clarifies the expected format beyond the schema's generic 'string' type. With 0% schema description coverage and only one parameter, this adequately compensates, though it could detail ID sourcing or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current job postings for an organization'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'organization_search' or 'organization_enrich', which could also relate to organization data but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. While it mentions usefulness for 'identifying growth signals and finding the right contacts', this is too vague and doesn't help an agent choose between this and other organization-related tools like 'organization_search' or 'people_search' for similar goals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool adds contacts to an email sequence, implying a write operation, but doesn't disclose critical behaviors: whether this triggers immediate emails, requires specific permissions, has rate limits, handles duplicates, or what happens if the sequence is inactive. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a clear purpose statement followed by Args and Returns sections. Every sentence earns its place—the purpose is front-loaded, and the parameter/return explanations are concise without redundancy. There's no wasted text, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values) but no annotations and 0% schema description coverage, the description is moderately complete. It explains the basic operation and parameters, but as a mutation tool, it lacks details on behavioral traits (e.g., side effects, error conditions) and usage context. The output schema handles return values, but the description doesn't address other complexities like authentication needs or idempotency.
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 0%, so the description must compensate. It lists all three parameters (sequence_id, contact_ids, email_account_id) and provides basic semantics: sequence_id identifies the target sequence, contact_ids are the contacts to add, and email_account_id is optional for sending. However, it doesn't explain parameter formats (e.g., UUIDs), constraints (e.g., maximum contact_ids), or the implications of omitting email_account_id. The description adds value but doesn't fully compensate for the lack of schema descriptions.
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 ('Add contacts') and resource ('to an email sequence'), making the purpose immediately understandable. It distinguishes itself from siblings like 'list_add_contacts' (which adds to lists) and 'contacts_search' (which searches contacts) by specifying the email sequence context. However, it doesn't explicitly differentiate from 'sequence_activate' or 'sequence_create', which also involve sequences but perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the sequence must be active), exclusions (e.g., cannot add contacts already in the sequence), or when to choose other tools like 'sequence_create' (for creating sequences) or 'list_add_contacts' (for adding to lists instead of sequences). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe what happens during the update (e.g., whether it's atomic, reversible, or requires specific permissions). It mentions returning 'Updated workflow details' but gives no insight into format, error conditions, or side effects. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, then provides organized parameter documentation in a bulleted format, and ends with return information. Every sentence serves a purpose with minimal waste. The only minor improvement would be integrating usage guidance more seamlessly.
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 this is a mutation tool with no annotations, 6 parameters, and an output schema exists, the description does an adequate job. The parameter semantics are well-covered, and the output schema will handle return value documentation. However, the description lacks important context about behavioral aspects (permissions, side effects, error handling) and usage guidelines, which are particularly important for an update operation in a system with multiple workflow-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a clear, bulleted list of all 6 parameters with brief explanations of what each represents (e.g., 'New workflow name', 'Updated trigger events'). This adds substantial semantic meaning beyond the input schema, which has 0% description coverage and only provides titles like 'Name' and 'Trigger Events'. The parameter explanations help the agent understand what data to provide for each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing workflow'), making the purpose immediately understandable. It distinguishes this from sibling tools like workflow_create, workflow_delete, and workflow_get by specifying it's for updating existing workflows rather than creating, deleting, or retrieving them. However, it doesn't explicitly differentiate from workflow_activate, which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing workflow ID), when to choose update over create/delete/activate, or any constraints like permission requirements. The agent must infer usage from the tool name and parameter list alone.
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 only states that it returns a list of account stages, without mentioning if this is a read-only operation, if it requires authentication, or any rate limits. This leaves significant gaps in understanding the tool's behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently adds return information in the second. Both sentences earn their place by clarifying the action and output without any wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is adequate but minimal. It states what the tool does and the return type, but for a tool with no annotations, it could benefit from more behavioral context like safety or usage notes to be 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?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately focuses on the output. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to explain non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Get' and resource 'available account/company stages', making it understandable. However, it doesn't differentiate from sibling tools like 'get_contact_stages' or 'get_available_fields', which have similar naming patterns but target different resources, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain if this is for retrieving metadata vs. actual data, or how it relates to siblings like 'get_contact_stages' or 'deals_list'. The description lacks any context on 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a list of variables, but doesn't cover aspects like authentication needs, rate limits, error handling, or whether it's a read-only operation (implied by 'Get' but not explicit). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence and adds a brief clarification about returns in the second. Every sentence adds value without waste, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is minimally complete. However, it lacks context on when to use it or behavioral details, which are needed for full agent understanding, keeping it at an adequate but basic level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline for no parameters. It efficiently avoids unnecessary details, earning a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all available fields/variables for email personalization', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'email_preview' or 'email_send', which might also involve email-related operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for email personalization, or how it relates to sibling tools such as 'email_send' or 'contacts_search', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool returns but doesn't cover critical aspects like whether it's a read-only operation, authentication needs, rate limits, or error handling. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, with two brief sentences that front-load the core purpose and return value. Every sentence earns its place without any wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. It states the purpose and return value, but with no annotations and sibling tools present, it lacks context on usage scenarios or behavioral traits. The output schema reduces the need to explain returns, but overall completeness is just acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it appropriately avoids redundancy. A baseline of 4 is applied as it handles the no-parameter case efficiently without unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('available email sending schedules'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'email_send' or 'sequences_list', which might also involve scheduling aspects, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'email_send' and 'sequences_list' potentially related to email operations, there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the action (activate/deactivate), it doesn't describe what activation/deactivation entails, whether it requires specific permissions, if it's reversible, or any side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: a clear purpose statement followed by well-organized parameter and return value sections. Every sentence earns its place, with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations but has an output schema (which handles return values), the description is minimally adequate. It covers the basic action and parameters but lacks important context about behavioral implications and usage guidelines, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'sequence_id' identifies the sequence and 'active' controls activation (True) or deactivation (False), providing clear semantic meaning that the schema lacks. The baseline would be 3 with high schema coverage, but here the description compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'activate or deactivate' and the resource 'a sequence', making it immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'workflow_activate' or 'sequence_get', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when activation/deactivation is appropriate, or how this differs from related tools like 'workflow_activate' or 'sequence_get' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't confirm if it's safe, requires authentication, has rate limits, or what happens with invalid IDs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose clearly. The Args and Returns sections are structured efficiently with no wasted words. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic purpose and parameter, though it lacks behavioral context due to no annotations. For a simple read operation, this is mostly 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?
The description adds minimal parameter semantics: it names 'sequence_id' and states it's 'The sequence ID', but the input schema already documents this parameter with a title and type. Schema description coverage is 0%, so the description doesn't compensate with format details (e.g., expected ID format, where to find it). Baseline is 3 due to adequate but uninformative coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific sequence'). It distinguishes from siblings like 'sequences_list' (which lists multiple sequences) and 'sequence_create' (which creates sequences). However, it doesn't explicitly mention what distinguishes it from 'workflow_get' or other similar get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing sequence ID), when not to use it, or how it differs from similar tools like 'workflow_get' or 'lists_get' in the sibling list. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination and sorting parameters, which hints at list behavior, but doesn't disclose critical traits like whether this is a read-only operation, rate limits, authentication needs, error conditions, or what 'List of sequences with stats' entails. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter and return sections. Every sentence adds value: the first states what the tool does, and the subsequent lines clarify inputs and outputs without redundancy. It's appropriately sized for a list tool with parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining parameters and mentioning returns. However, with an output schema present (implied by 'Has output schema: true'), the description doesn't need to detail return values, but it still lacks behavioral context for a list operation, making it minimally adequate but with clear 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 description coverage is 0%, so the description must compensate. It explicitly lists and describes all three parameters (page, per_page, sort_by) with brief explanations, adding meaningful context beyond the bare schema. However, it doesn't specify allowed values for sort_by or constraints on page/per_page, leaving some semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all email sequences in your Apollo account'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'analytics_sequences' or 'workflows_list' which might also list sequences or related items, so it doesn't achieve full sibling differentiation.
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. With sibling tools like 'analytics_sequences' and 'workflows_list' that might overlap in functionality, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a list operation but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not explained), rate limits, authentication requirements, or what happens with invalid parameters. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: a clear purpose statement, brief context about templates, and organized parameter/return documentation. Every sentence adds value, with no redundant or verbose content. It's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation with 2 simple parameters), an output schema exists (so return values are covered), and no annotations, the description is minimally adequate. It covers purpose and parameters but lacks behavioral context and usage guidance. For a simple tool, this is borderline complete but has clear gaps in transparency and guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents both parameters ('page' and 'per_page') in an Args section, adding meaning beyond the input schema which has 0% description coverage. This compensates well for the schema gap, though it doesn't explain default values or constraints (e.g., range limits). With 2 parameters and full coverage in the description, this exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available workflow templates'), making the purpose immediately understandable. It distinguishes from siblings like 'workflow_create_from_template' (which uses templates) and 'workflows_list' (which lists active workflows). However, it doesn't explicitly differentiate from 'workflow_create_from_template' in terms of template selection vs. listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it over 'workflow_create_from_template' (for selecting a template to create a workflow) or 'workflows_list' (for listing active workflows). The second sentence explains what templates are but doesn't help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create a new task' implies a write/mutation operation, the description doesn't disclose important behavioral traits: what permissions are required, whether creation is idempotent, what happens on validation errors, rate limits, or what 'Created task details' actually contains. It mentions the return but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and appropriately sized. Every sentence earns its place by providing essential parameter documentation. It could be slightly more front-loaded by moving the purpose statement to the very beginning, but overall it's efficient with minimal waste.
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 this is a mutation tool with no annotations but with an output schema, the description is moderately complete. It documents all parameters well and mentions the return, but lacks behavioral context about permissions, error handling, or side effects. The output schema existence means the description doesn't need to detail return values, but for a creation tool with no safety annotations, more behavioral disclosure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. The schema has 0% description coverage (only titles), but the description adds: 'Contact ID to associate task with', 'Type of task (action_item, call, email, linkedin)', 'Task notes/description', 'Due date (ISO format)', and 'Priority level (low, medium, high)'. This fully compensates for the schema's lack of descriptions and adds crucial context like format requirements and allowed values.
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 task' which is a specific verb+resource combination. It distinguishes this from sibling tools like 'tasks_list' (listing vs creating) and 'deal_create' (different resource type). However, it doesn't explicitly differentiate from other creation tools like 'sequence_create' or 'workflow_create' beyond the resource name.
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. There's no mention of prerequisites (e.g., contact must exist), when not to use it, or comparison to similar tools like 'sequence_create' or 'workflow_create' that might also involve task-like operations. The agent must infer usage context from the tool name alone.
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 carries full burden. It mentions pagination behavior through the 'page' and 'per_page' parameters and filtering via 'active_only', which adds useful context. However, it doesn't disclose rate limits, authentication needs, or whether this is a read-only operation (though implied by 'List'), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, explanatory context about workflows, and separate parameter/return sections. It's appropriately sized, though the workflow explanation could be slightly trimmed if space is tight.
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 3 parameters with 0% schema coverage and an output schema present, the description does a good job: it explains the purpose, documents parameters, and notes the return value. The output schema means return details aren't needed in the description, making this reasonably complete for a 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?
The schema description coverage is 0%, so the description must compensate. It explicitly documents all three parameters ('page', 'per_page', 'active_only') with brief explanations, adding meaningful semantics beyond the bare schema. This is effective but not exhaustive (e.g., no default values or ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all workflows in your Apollo account', providing a specific purpose. However, it doesn't explicitly differentiate from sibling workflow tools like 'workflow_templates_list' or 'workflow_get', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'workflow_get' (for a single workflow) or 'workflow_templates_list' (for templates). It only states what the tool does without context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'send a one-off email' implying a write operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, if emails are queued or sent immediately, error handling, or if it logs to analytics. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured Args/Returns section. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 4 params), no annotations, and an output schema exists (implied by 'Returns: Confirmation of email sent'), the description is partially complete. It covers parameters well but lacks behavioral context (e.g., auth, side effects) and doesn't fully compensate for missing annotations, though the output schema reduces need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose: 'to_email' as recipient address, 'subject' as email subject, 'body_html' as email body HTML, and 'contact_id' as optional link to contact. This clarifies semantics beyond the schema's basic titles, though it doesn't detail formats (e.g., HTML requirements) or 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?
The description clearly states the verb 'send' and resource 'one-off email to a contact', specifying it's not part of a sequence or batch. It distinguishes from siblings like email_preview (preview), analytics_sequences (sequence analytics), and sequence_activate (activate sequences), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose email_send over sequence_activate for automated emails, or when to use email_preview for testing. There's no context on prerequisites, such as needing a verified sender or contact existence, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what data is returned, it doesn't describe important behavioral aspects like rate limits, authentication requirements, error conditions, data freshness, or whether this is a read-only operation. The description is functional but lacks operational transparency needed for an agent to use it effectively.
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 well-structured and efficiently organized: purpose statement, data scope, parameter documentation, return value, and example. Every sentence serves a clear purpose with zero redundancy. The information is front-loaded with the core functionality stated first, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return value documentation) and only one parameter, the description provides adequate context for basic usage. It covers purpose, parameter meaning, and data scope. However, for a data enrichment tool with no annotations, it should ideally mention more about behavioral aspects like rate limits, data sources, or accuracy considerations to be 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?
With 0% schema description coverage and only one parameter, the description provides essential semantic context that the schema lacks. It explains that the 'domain' parameter should be a company domain like 'stripe.com' and provides a concrete example. This adds meaningful value beyond the bare schema, though it could elaborate on format requirements or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Enrich an organization's profile by domain' with specific details about what data is retrieved (firmographics, technographics, funding info). It distinguishes from sibling tools like 'organization_search' by focusing on enrichment rather than searching. However, it doesn't explicitly contrast with 'people_enrich' which serves a similar enrichment function for individuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the example and parameter description, suggesting it should be used when you have a company domain and need comprehensive organizational data. However, it doesn't explicitly state when to use this versus alternatives like 'organization_search' or 'people_enrich', nor does it mention any prerequisites or exclusions for use.
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 carries full burden. It indicates this is a read operation ('Get') and specifies what information is returned (triggers, actions, enrollment criteria). However, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, or whether this operation has side effects. The description doesn't contradict annotations since none exist.
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 perfectly structured and concise: purpose statement first, then Args section with parameter explanation, then Returns section. Every sentence earns its place, with no redundant information. The formatting with clear sections makes it easy to parse.
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 has an output schema (so return values don't need explanation in description), 1 parameter with 0% schema coverage, and no annotations, the description does well by explaining the parameter and return content. However, for a read operation with no annotation safety profile, it could benefit from explicitly stating this is a safe, non-destructive 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?
With 0% schema description coverage (schema only has title 'Workflow Id'), the description adds significant value by explaining the single parameter's purpose ('The workflow ID'). However, it doesn't provide format details, validation rules, or examples. For a single parameter tool with no schema documentation, this is good but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific workflow', making the purpose unambiguous. It distinguishes from siblings like workflows_list (which lists multiple workflows) and workflow_create/update/delete (which modify workflows). However, it doesn't explicitly contrast with workflow_get's closest sibling workflow_activate, which might share similar parameter 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 usage when detailed information about a specific workflow is needed, but doesn't explicitly state when to use this versus alternatives like workflows_list (for listing) or workflow_activate (for activation). No explicit when-not-to-use guidance or prerequisite information is provided, though the required workflow_id parameter suggests you need to know the specific workflow identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a search operation. It doesn't disclose behavioral traits like whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, pagination behavior beyond parameters, or what happens with empty results. The example helps but doesn't cover behavioral aspects.
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?
Well-structured with clear sections: purpose statement, parameter explanations with examples, return value description, and a practical example. Every sentence adds value - no redundant information. The example is appropriately placed at the end.
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 8 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and providing an example. However, for a search tool with many siblings, it could better differentiate when to use this vs alternatives. The existence of an output schema means return values don't need explanation, which is handled appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all 8 parameters, including examples for complex ones (revenue_range, organization_num_employees_ranges). Each parameter's purpose is explained beyond just the parameter name.
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 organizations/companies in Apollo's database, using specific verb ('search') and resource ('organizations/companies'). It distinguishes from siblings like organization_enrich (which likely enriches existing records) and people_search (which searches individuals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the example (finding SaaS companies with specific criteria), but doesn't explicitly state when to use this vs alternatives like organization_enrich or people_search. No guidance on prerequisites, rate limits, or access requirements is provided.
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 carries the full burden. It discloses the tool's behavior as a preview/testing operation with variable substitution, which is helpful. However, it doesn't mention important behavioral aspects like whether this requires authentication, has rate limits, affects system state, or what happens when contact_id is omitted. The description adds value but leaves 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 perfectly structured and front-loaded: first sentence states core purpose, second explains usage context, then parameter documentation, and finally return value. Every sentence earns its place with zero waste. The formatting with clear sections enhances readability.
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 3 parameters with 0% schema coverage and an output schema exists, the description does well by explaining parameter semantics and the tool's purpose. However, as a testing/preview tool with no annotations, it should ideally mention more about the preview output format, error conditions, or authentication requirements to be 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?
The schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for all 3 parameters: explains that subject and body_html can include {{variables}}, and that contact_id is optional for previewing with real data. This adds crucial context beyond the bare schema, though it doesn't specify variable syntax details or contact_id 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's purpose with specific verbs ('preview', 'test') and resources ('email', 'contact data'), and distinguishes it from siblings like email_send by focusing on preview/testing rather than actual sending. The mention of variable substitution adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('test how your email will look with real contact data'), but doesn't explicitly state when NOT to use it or name specific alternatives. It implies usage for testing before sending, but lacks explicit exclusions or named sibling comparisons.
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 carries the full burden. It discloses that this creates a new workflow (a write operation) and mentions activation behavior via the 'active' parameter. However, it lacks details on permissions needed, error conditions, rate limits, or whether creation is idempotent, which are important for a creation 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?
The description is well-structured with clear sections (Args, Returns, Example) and uses bullet points for readability. However, it's somewhat lengthy due to the comprehensive parameter explanations, which are necessary given the 0% schema coverage. Every sentence earns its place by providing essential information.
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 (8 parameters, creation operation) and 0% schema coverage, the description does an excellent job explaining parameters and includes an example. With an output schema present, it doesn't need to detail return values. The main gap is lack of behavioral context like permissions or error handling, which lowers the score slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for all 8 parameters: explains each parameter's purpose, lists allowed values for trigger_type and model_type, enumerates trigger_events with descriptions, describes actions structure, and clarifies requirements like first_run_on for schedule-based workflows. This adds significant value beyond the bare 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 ('Create') and resource ('new workflow automation'), with additional context about workflows triggering actions based on events or schedules. It distinguishes from siblings like workflow_create_from_template (template-based creation) and workflow_update (modification).
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 through its parameter explanations (e.g., trigger_type choices, first_run_on for schedule-based workflows). However, it doesn't explicitly state when to choose this over alternatives like workflow_create_from_template or workflow_update, nor does it mention 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?
With no annotations provided, the description carries full burden. It discloses that this is a 'powerful tool for creating automated outreach campaigns' (implying mutation), describes the return value ('Created sequence details'), and provides a comprehensive example. However, it doesn't mention permissions, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The example and variable list are valuable but make it slightly longer. Every section (purpose, args, returns, example, variables) earns its place by adding necessary information.
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 complexity (4 parameters with nested structures, 0% schema coverage, no annotations) and the presence of an output schema, the description is complete. It covers purpose, detailed parameter semantics, return values, an illustrative example, and available variables—providing everything needed for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing all 4 parameters. It explains 'name' and 'steps' thoroughly (including nested configurations for step types, wait times, and emailer_touches), clarifies optionality of 'schedule_id', and specifies default behavior for 'active'. The example and variable list add further clarity.
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 resource ('new email sequence with steps'), distinguishing it from siblings like sequence_get, sequences_list, or sequence_activate. It specifies this is for 'automated outreach campaigns,' which helps differentiate from other creation tools like deal_create or workflow_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 'automated outreach campaigns' but doesn't explicitly state when to use this tool versus alternatives like workflow_create or email_send. No guidance on prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings is provided.
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 of behavioral disclosure. The description indicates this is a search/read operation (implied by 'Search contacts') and mentions pagination parameters (page, per_page), which suggests paginated results. However, it doesn't disclose important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a read-only operation versus a mutation.
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 well-structured and appropriately sized. It begins with the core purpose, provides important sibling differentiation, then lists parameters with brief explanations, and concludes with return information. Every sentence earns its place, with no wasted words or redundant information.
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 moderate complexity (6 parameters, search functionality) and the presence of an output schema (which handles return value documentation), the description provides good contextual coverage. It explains the tool's purpose, distinguishes it from alternatives, documents all parameters, and mentions the return type. The main gap is lack of behavioral transparency details that would be important for a search 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?
With 0% schema description coverage, the description provides meaningful parameter information beyond what the schema offers. It documents all 6 parameters with brief explanations of their purpose (e.g., 'Filter by contact stage IDs', 'Filter by owner user ID', 'Filter by sequence IDs'). While it doesn't provide detailed format requirements or constraints, it adds substantial value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Search') and resource ('contacts in your Apollo CRM/database'). It explicitly distinguishes this tool from its sibling 'people_search' by explaining that this searches contacts already added to the user's Apollo account, while people_search searches Apollo's 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?
The description provides explicit guidance on when to use this tool versus alternatives by stating 'Unlike people_search which searches Apollo's global database, this searches contacts you've already added to your Apollo account.' This clearly differentiates the tool from its most relevant sibling and provides context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does (enriches profiles with comprehensive data) and mentions the data source (Apollo), but doesn't disclose important behavioral traits like rate limits, authentication requirements, data freshness, or error conditions. It adequately describes the core functionality but lacks operational details.
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 well-structured and appropriately sized. It begins with the core purpose, then provides usage requirements, parameter explanations, return value description, and concrete examples. Every sentence serves a clear purpose with zero waste, making it easy for an AI agent to parse and understand.
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 moderate complexity (6 parameters, no annotations, but has output schema), the description is mostly complete. It explains the purpose, usage patterns, parameters, and return values. The output schema existence means the description doesn't need to detail return structure. However, it could better address behavioral aspects like error handling or data limitations given the lack of annotations.
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 0% schema description coverage (schema only provides titles like 'Email', 'First Name'), the description adds significant value by explaining parameter semantics. It clarifies that email is the 'best identifier', provides context for domain ('e.g., "google.com"'), and explains how parameters work together ('Provide at least one identifier...'). However, it doesn't fully explain all 6 parameters' relationships or constraints beyond the basic groupings.
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 person's profile with additional data from Apollo.' It specifies the verb ('enrich'), resource ('person's profile'), and data source ('Apollo'), distinguishing it from sibling tools like people_search (which searches rather than enriches) and organization_enrich (which targets organizations instead of people).
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 provides explicit usage guidelines: 'Provide at least one identifier (email, LinkedIn URL, or name + company).' It also offers specific examples of when to use different parameter combinations (enrich by email vs. enrich by name + company), giving clear guidance on how to invoke the tool effectively.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function as a search/prospecting operation, includes pagination behavior (page/per_page parameters with defaults), and provides a concrete example of usage. However, it doesn't mention rate limits, authentication requirements, or potential data freshness considerations.
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 well-structured with clear sections: purpose statement, usage context, parameter documentation, return value, and example. While comprehensive, it's appropriately sized for a 10-parameter tool. The front-loaded purpose statement is clear, though the parameter section is necessarily lengthy.
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 (10 parameters, no annotations, but has output schema), the description is quite complete. It covers purpose, usage context, detailed parameter semantics, return value format, and includes a helpful example. The main gap is the lack of behavioral constraints like rate limits or authentication requirements, which would be valuable for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 10 parameters, the description compensates excellently by providing detailed parameter documentation in the Args section. Each parameter includes clear explanations with examples (e.g., 'person_titles: Job titles to filter by (e.g., ["CEO", "CTO", "VP Sales"])'), which adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for people/contacts in Apollo's database' with the specific verb 'search' and resource 'people/contacts'. It further distinguishes this as 'Apollo's core prospecting tool' which differentiates it from sibling tools like contacts_search, people_enrich, or organization_search by emphasizing its lead-finding function.
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 context about when to use this tool: 'use it to find leads matching specific criteria' and positions it as 'Apollo's core prospecting tool'. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools (e.g., when to use contacts_search vs. people_search).
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 provided, the description carries full burden and does well by disclosing key behavioral traits: it's a state mutation tool (activate/deactivate), has prerequisites (actions must be configured), provides failure guidance (configure via Apollo UI), and mentions the return value. It doesn't cover rate limits, authentication needs, or side effects on related resources.
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?
Perfectly structured with purpose statement, important note, and clearly labeled Args/Returns sections. Every sentence earns its place: the first states the core function, the note provides critical usage context, and the parameter/return documentation is essential given 0% schema coverage.
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 2 parameters with 0% schema coverage and no annotations, the description provides complete parameter semantics, behavioral context (prerequisites, failure handling), and acknowledges returns. With an output schema present, it doesn't need to detail return values. This is comprehensive for a state mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It explicitly documents both parameters with clear semantics: workflow_id identifies the target, and active controls the state (True=activate, False=deactivate). This adds complete meaning beyond the bare 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 specific action ('Activate or deactivate') on a specific resource ('a workflow'), distinguishing it from siblings like workflow_create, workflow_update, and workflow_delete. It uses precise verbs that indicate state change operations rather than creation, retrieval, or modification.
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 context about when to use it (to change workflow activation state) and includes prerequisites (workflow must have actions configured). However, it doesn't explicitly differentiate when to use this vs. alternatives like sequence_activate or specify when-not scenarios beyond the prerequisite note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/BlockchainRev/apollo-mcp-server'

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