Instantly 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 targeting specific resources like campaigns, leads, accounts, or emails, with clear boundaries. However, some potential confusion exists between get_campaign_analytics and get_campaign_analytics_overview, as both relate to campaign analytics but differ in scope, which could lead to misselection without careful reading of descriptions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_campaign, list_accounts, update_lead, and get_campaign_analytics. This predictability makes it easy for agents to understand and navigate the toolset without ambiguity in naming conventions.
Tool Count3/5
With 22 tools, the count is borderline high for an email marketing server, potentially feeling heavy and overwhelming. While it covers a broad domain, some tools might be redundant or overly specialized, making the set less streamlined than ideal for typical agent workflows.
Completeness5/5
The toolset provides comprehensive CRUD and lifecycle coverage for campaigns, leads, accounts, and emails, including creation, listing, updating, and analytics. It also includes specialized tools like validate_campaign_accounts and reply_to_email, ensuring no obvious gaps for the email marketing domain and supporting robust agent operations.
Average 3.3/5 across 22 of 22 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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. 'Create a new lead' implies a write operation, but it doesn't disclose behavioral traits like required permissions, whether the operation is idempotent, rate limits, or what happens on success/failure. This leaves significant gaps for an agent to understand how 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 a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'lead' is, what happens after creation, or any error conditions, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters like 'email' (required) and others are documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationships between fields or usage examples, which aligns with the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new lead' clearly states the verb ('Create') and resource ('lead'), which is better than a tautology. However, it doesn't distinguish this tool from its sibling 'update_lead' or specify what constitutes a 'lead' in this context, making it somewhat vague.
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 'update_lead' or 'create_lead_list'. It doesn't mention prerequisites, such as needing an email address, or contextual factors like when leads should be created versus updated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. It lacks context on what 'details' includes or how it behaves, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loaded with the core action. It's appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'details' are returned, error cases, or how it fits with sibling tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'campaign_id' parameter. The description adds no meaning beyond this, such as format examples or constraints, but meets the baseline since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific campaign' clearly states the verb ('Get') and resource ('campaign'), but it's vague about what 'details' entails and doesn't differentiate from siblings like 'get_campaign_analytics' or 'list_campaigns'. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_campaigns' for multiple campaigns or 'get_campaign_analytics' for performance data. The description implies usage for a single campaign but doesn't specify 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 but only states the action without details on permissions, rate limits, output format, or side effects. It lacks critical context for a read operation with optional parameters, making it inadequate for informed use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for the tool's complexity, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with optional parameters, the description is incomplete. It fails to explain what analytics are returned, how optional parameters affect results, or behavioral traits, leaving significant gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no additional meaning beyond implying analytics retrieval, which is already covered by the tool name and purpose. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get analytics for campaigns' states a basic purpose (verb+resource) but is vague about what analytics are retrieved or how it differs from sibling tools like 'get_campaign_analytics_overview'. It doesn't specify scope (e.g., metrics, timeframes) or distinguish itself clearly from alternatives.
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 like 'get_campaign_analytics_overview' or 'get_campaign'. There's no mention of prerequisites, context, or exclusions, leaving the agent with no usage direction beyond the basic purpose.
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. 'Update an existing campaign' implies a mutation operation but doesn't specify required permissions, whether changes are reversible, rate limits, or what happens if only some fields are provided. It lacks critical behavioral context for a write operation 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple update operation and front-loads the core action. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the update does beyond the basic action, what values 'status' can take, whether all fields are optional besides campaign_id, or what the tool returns. For a 3-parameter write operation with zero structured context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (campaign_id, name, status) adequately. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, constraints, or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing campaign' clearly states the verb ('update') and resource ('campaign'), but it's vague about what specifically gets updated. It doesn't differentiate from sibling tools like 'update_account' or 'update_lead' beyond the resource name, nor does it specify which campaign attributes can be modified beyond what the schema shows.
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 an existing campaign ID), when not to use it, or how it relates to siblings like 'create_campaign' or 'get_campaign'. The description alone gives no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update a lead' implies a mutation operation, but it doesn't describe what happens during the update (e.g., whether it overwrites or merges fields, if custom_fields are additive or replace existing ones), what permissions are required, or what the response looks like (especially since there's no output schema). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Update a lead'), with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. While it may be overly brief for a mutation tool, it earns full marks for conciseness as every word contributes directly to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters including nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like what the update does behaviorally, how to handle custom_fields, what happens on success/failure, or how it differs from sibling tools. For a tool that modifies data, this minimal description leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 5 parameters clearly documented in the schema (e.g., lead_id as required, company, custom_fields, first_name, last_name). The description adds no additional parameter information beyond what's in the schema, such as examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a lead' clearly states the verb (update) and resource (lead), making the basic purpose understandable. However, it doesn't specify what aspects of a lead can be updated or differentiate this tool from sibling tools like 'update_account' or 'update_campaign' that also perform updates on different resources. The purpose is clear but lacks specificity about scope and distinction from alternatives.
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 lead ID), when not to use it (e.g., for creating new leads, which is handled by 'create_lead'), or compare it to similar tools like 'update_account'. Without any usage context, agents must infer everything from the tool name and schema 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 full burden for behavioral disclosure. 'Create a new lead list' implies a write/mutation operation, but it doesn't disclose permissions needed, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation 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 maximally concise with just four words that directly state the tool's purpose. There's zero wasted language, and it's perfectly front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'lead list' is in this system's context, what happens after creation, or how this differs from similar creation tools. The description should provide more context given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (name and description) with their types and requirements. The description doesn't add any parameter semantics beyond what's in the schema, such as format constraints or examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Create a new lead list' clearly states the verb ('create') and resource ('lead list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_campaign' or 'create_lead' by specifying what distinguishes a lead list from these other resources.
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 multiple sibling tools for creating resources (create_campaign, create_lead), but the description doesn't explain what a 'lead list' is or when it should be created instead of other entities. No prerequisites or exclusions are 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't address important aspects like authentication requirements, rate limits, error conditions, or what format the 'analytics overview' returns. 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 a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what this tool actually returns and how it differs from sibling analytics tools. The current description is too minimal for a tool that presumably returns analytics data - it doesn't indicate what metrics are included in the 'overview' or what format the results take.
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 schema description coverage is 100%, with both parameters ('start_date' and 'end_date') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, but since the schema provides complete coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get analytics overview for all campaigns' clearly states the verb ('Get') and resource ('analytics overview for all campaigns'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_campaign_analytics' or 'get_warmup_analytics', which appear to offer related analytics 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. With sibling tools like 'get_campaign_analytics' and 'get_warmup_analytics' available, there's no indication of what differentiates this 'overview' tool from other analytics tools, nor any mention of prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches an email but lacks details on permissions required, rate limits, error handling (e.g., for invalid IDs), or response format. This is inadequate for a read operation that might have constraints, scoring low due to minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Get a specific email by ID') contributes directly to understanding the tool, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but incomplete. It doesn't cover behavioral aspects like what data is returned or error conditions, which are crucial for effective use. For a basic read tool, more context on output or constraints would enhance 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 mentions 'by ID', which aligns with the single parameter 'email_id' in the schema. Since schema description coverage is 100%, the schema already documents this parameter fully. The description adds no additional semantic context (e.g., ID format or source), so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific email by ID'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'list_emails' by specifying retrieval of a single item rather than listing. However, it doesn't explicitly mention what 'get' entails (e.g., fetching metadata, content, or both), 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. It doesn't mention when to choose 'get_email' over 'list_emails' for bulk retrieval or 'reply_to_email' for interaction, nor does it specify prerequisites like needing an email ID from another operation. Usage is implied but not explicitly stated.
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 the API requirement about array format, which is useful, but fails to describe key behaviors: whether this is a read-only operation, what the return format looks like, if there are rate limits, or authentication requirements. For a tool with 3 parameters and no annotations, 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 concise with two sentences, front-loading the core purpose. The API requirement is relevant but could be integrated more smoothly. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about return values, error conditions, behavioral constraints, and how it differs from sibling tools. The API requirement note is helpful but doesn't compensate for these 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 100%, so the schema already fully documents all parameters. The description adds the API requirement about using an array even for single emails, which provides some additional context beyond the schema, but doesn't explain parameter interactions or semantics like date range effects. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('warmup analytics for one or more accounts'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from sibling analytics tools like 'get_campaign_analytics' or 'get_account_details', 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 like 'get_campaign_analytics' or 'get_account_details', nor does it mention prerequisites (e.g., that accounts must be warmed up). The API requirement note is technical rather than usage guidance.
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 'filters and pagination', hinting at querying behavior, but fails to disclose critical traits: whether this is a read-only operation, potential rate limits, authentication needs, what happens if filters yield no results, or the format of returned data. For a list tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('List emails') and includes key features without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and list functionality. It lacks details on behavioral traits (e.g., safety, limits), return values, or error handling, which are essential for an agent to use it correctly in context with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds minimal value by mentioning 'filters and pagination', which aligns with parameters like 'account_id' and 'starting_after', but doesn't provide additional context beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('List emails') and mentions key capabilities ('with filters and pagination'), which distinguishes it from sibling tools like 'get_email' (singular) or 'reply_to_email'. However, it doesn't specify what type of emails (e.g., marketing, transactional) or fully differentiate from other list tools like 'list_campaigns' 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. It doesn't mention prerequisites (e.g., needing an account), exclusions, or compare it to siblings like 'list_campaigns' or 'get_email', leaving the agent to 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 'filters and pagination' which gives basic behavioral context, but doesn't disclose important traits like whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, error conditions, or what the return format looks like. For a tool with 5 parameters and no output schema, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose ('List leads') followed by key capabilities ('with filters and pagination'). Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is insufficiently complete. While concise, it doesn't compensate for the lack of structured metadata. For a filtering and pagination tool that likely returns complex lead data, the description should provide more context about return format, error handling, or usage examples to help an agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'filters and pagination' which aligns with parameters like 'campaign_id', 'list_id', 'status' (filters) and 'starting_after' (pagination). However, it doesn't provide additional context about parameter interactions or usage patterns beyond what's already in the 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 ('List') and resource ('leads'), and mentions filtering and pagination capabilities. It distinguishes from other lead-related tools like 'create_lead' or 'update_lead' by focusing on retrieval. However, it doesn't explicitly differentiate from 'list_lead_lists' which might be a sibling tool for listing lead collections rather than individual leads.
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 'list_lead_lists' (for listing lead collections) and 'get_campaign' (for retrieving specific campaigns), there's no indication of when this filtered lead listing is preferred over other listing or retrieval methods. No prerequisites or exclusions are 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. While 'Update' implies a mutation operation, the description doesn't specify permission requirements, whether changes are reversible, rate limits, or what happens when updating fails. For a mutation tool with zero annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Update a sending account'), with zero wasted language. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'sending account' means in this context, what values are returned, error conditions, or how this tool relates to other account management tools like 'get_account_details' and 'list_accounts'.
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 schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a sending account'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'update_campaign' or 'update_lead' - it simply describes what it does without comparative context.
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 this should be used instead of other update tools, or what context would make this appropriate. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what information is retrieved, it doesn't cover critical aspects like permissions required, error handling (e.g., for non-existent accounts), rate limits, or response format. For a read operation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about a specific account') and adds specifics without redundancy. It could be slightly improved by structuring usage hints, but it avoids waste and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves detailed account data. It lists information types but doesn't explain the return format, error cases, or dependencies. For a read operation with potential complexity (e.g., warmup status, SMTP settings), more context is needed to ensure the agent can use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'email' clearly documented in the schema. The description adds no additional parameter semantics beyond implying the email is for account identification. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Get detailed information') and resource ('about a specific account'), distinguishing it from sibling tools like 'list_accounts' (which lists multiple accounts) and 'update_account' (which modifies accounts). It also specifies the types of information included (warmup status, SMTP settings, campaign eligibility), making the purpose highly 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 prerequisites (e.g., whether the account must exist), exclusions (e.g., what happens for invalid emails), or comparisons to siblings like 'list_accounts' (for overviews) or 'verify_email' (for validation). Usage is implied but not explicitly stated.
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 describes a read-only check operation, which is safe, but doesn't add context such as whether it requires specific permissions beyond the API key, potential rate limits, or what the return format looks like (e.g., list of features, status). This leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on usage context, behavioral traits, and output format, making it minimally viable but not fully complete for informed agent use.
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 schema description coverage is 100% (though trivial with no properties). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any 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 tool's purpose with a specific verb ('Check') and resource ('premium features'), and specifies the context ('with your current Instantly plan and API key permissions'). It doesn't explicitly differentiate from siblings like 'get_account_details', but the focus on feature availability is distinct enough for a 4.
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 it's appropriate (e.g., before using premium features) or when not to use it, and doesn't reference sibling tools like 'get_account_details' that might overlap in providing account information.
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. 'List all API keys' implies a read-only operation, but it doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, or what 'all' entails (e.g., scope or filters). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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, no output schema), the description is minimally adequate. However, with no annotations and no output schema, it lacks details on return values or behavioral context, making it incomplete for optimal agent use despite the low complexity.
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 doesn't add parameter details, but that's acceptable given the schema completeness, warranting a baseline above 3 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 'List all API keys' clearly states the verb ('List') and resource ('API keys'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_accounts' or 'list_campaigns' beyond the resource type, so it's not fully specific to sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or related tools, leaving the agent to infer usage based on the 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 the full burden of behavioral disclosure. It mentions 'pagination', which is a key behavioral trait not evident from the schema alone, adding value. However, it lacks details on permissions, rate limits, response format, or error conditions, leaving significant gaps for a list 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 a single, efficient sentence that front-loads the core purpose ('List all lead lists') and adds essential context ('with pagination') without waste. Every word earns its place, 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 the tool's low complexity (list operation with 2 parameters) and no output schema, the description is minimally adequate. It covers the basic action and pagination but lacks details on return values, error handling, or integration with siblings. For a tool with no annotations, it should provide more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('limit' and 'starting_after'). The description adds no additional parameter semantics beyond implying pagination, which is already covered in the schema's descriptions. This meets the baseline for high schema coverage but doesn't enhance 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 resource ('lead lists'), making the purpose immediately understandable. It distinguishes from siblings like 'create_lead_list' (creation vs listing) and 'list_leads' (lists vs leads), though it doesn't explicitly contrast with other list operations. The description is specific but lacks explicit sibling differentiation beyond the obvious.
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, timing considerations, or comparisons with other list operations (like 'list_campaigns' or 'list_leads'). The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
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 describes the tool's function (validation and debugging) and output scope ('shows the status of all accounts'), but lacks details on permissions, rate limits, or error handling, which are important for a tool that might involve account data access.
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 efficiently adds context in the second, with no wasted words. Every sentence contributes directly to understanding the tool's use and value.
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 (validation with optional filtering), no annotations, and no output schema, the description is adequate but incomplete. It explains the purpose and usage context but does not cover behavioral aspects like response format or error conditions, which are needed for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides (e.g., it does not explain the format or validation rules for email addresses), relying entirely on the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validate which accounts are eligible') and resources ('campaign creation'), distinguishing it from siblings like 'list_accounts' or 'get_account_details' by focusing on eligibility validation rather than general listing or retrieval.
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 usage ('helps debug campaign creation issues'), but does not explicitly state when not to use it or name specific alternatives among siblings, such as 'check_feature_availability' or 'list_accounts', which might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 and does so comprehensively. It details the pagination algorithm (starting limit, continuation logic, progress reporting), explains that summarized data is returned to prevent size limits, clarifies that filters work with both pagination modes, and specifies that full details require 'get_campaign'. This provides rich behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (COMPLETE PAGINATION, PAGINATION ALGORITHM, FILTERS) and uses bullet points effectively. It's appropriately sized for the complexity, though some sentences could be more concise (e.g., the pagination algorithm explanation is somewhat verbose). Overall, it's front-loaded with key information and most content earns its place.
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 (pagination algorithms, multiple modes) and lack of annotations/output schema, the description does an excellent job explaining behavior and usage. It covers the key aspects an agent needs: purpose, pagination approaches, algorithm details, filter compatibility, and relationship to 'get_campaign'. The main gap is lack of explicit sibling tool differentiation, but otherwise it's quite complete for a list operation with advanced features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds some context about how parameters interact (e.g., 'limit=100+ or limit="all" triggers complete pagination', 'starting_after not needed when using complete pagination'), but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List campaigns with optional filters and complete pagination support.' It specifies the verb ('list') and resource ('campaigns'), but doesn't explicitly differentiate from sibling tools like 'get_campaign' or 'get_campaign_analytics' beyond mentioning that 'get_campaign' provides full details. The purpose is clear but sibling differentiation is only implied.
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 on when to use complete pagination (with three specific approaches) and mentions that 'get_campaign' should be used for full details of specific campaigns. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_campaign_analytics' or 'list_lead_lists', nor does it provide exclusion criteria for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a mutation operation (reply action) and specifies constraints (requires existing email ID, cannot send new emails). However, it doesn't mention authentication needs, rate limits, error conditions, or what the response looks like, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: states the purpose, provides critical constraint, and gives alternative guidance. It's front-loaded with the core functionality and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks behavioral details about permissions, response format, or error handling. The 100% schema coverage helps, but more context about the operation's behavior would be beneficial given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reply to an existing email') and resource ('email'), distinguishing it from sibling tools like create_campaign for sending new emails. It explicitly differentiates from alternatives by stating 'This can only be used to reply to existing emails, not to send new emails.'
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 ('reply to existing emails') and when not to ('not to send new emails'), with a clear alternative named ('Use campaigns for sending new emails'). It also mentions prerequisites ('You must provide the ID of an existing email to reply to').
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 key behavioral traits: it's a validation operation (implied read-only), discloses potential access restrictions (premium plan requirements, 403 errors), and provides troubleshooting guidance. It doesn't mention rate limits or response format details, but covers critical operational constraints.
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 first, followed by important operational details. The troubleshooting list is somewhat lengthy but necessary for the access constraints, making it reasonably efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, usage context, and critical behavioral constraints (access requirements, error handling). The main gap is lack of output format details, but otherwise it's quite comprehensive given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'email' parameter. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('verify') and resource ('email address'), and it distinguishes this tool from all sibling tools which focus on campaigns, leads, accounts, or lists rather than email validation.
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 (to verify email validity) and includes important prerequisites (premium plan, API permissions). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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 does an excellent job explaining the three-stage workflow, auto-detection logic, and how the tool handles missing parameters. However, it doesn't mention potential side effects like rate limits, authentication requirements, or what happens on failure. The description doesn't contradict any annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Intelligent Workflow, Three-Stage Process, Example Usage), but it's quite lengthy at over 500 words. While all content is relevant, it could be more front-loaded with the core purpose. The example usage section is particularly valuable but contributes to the length.
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 complexity (24 parameters, no annotations, no output schema), the description does an excellent job explaining the tool's behavior and workflow. It covers the multi-stage nature, parameter handling logic, and usage patterns. The main gap is the lack of output information - since there's no output schema, the description should ideally mention what the tool returns upon successful creation or at different stages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 24 parameters thoroughly. The description adds some context about parameter usage in different stages and provides example usage patterns, but doesn't add significant semantic meaning beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Create a new email campaign with bulletproof three-stage workflow'. It clearly distinguishes from sibling tools like 'get_campaign', 'list_campaigns', or 'update_campaign' by focusing on creation with a specific workflow. The description goes beyond the name by detailing the three-stage process and intelligent workflow.
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. It details three usage modes (simple, advanced, guided) and explains auto-stage detection. It distinguishes from sibling tools by being the primary creation tool, while tools like 'validate_campaign_accounts' or 'update_campaign' serve different purposes. The example usage section further clarifies appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 and does so comprehensively. It explains the pagination algorithm, progress reporting, validation behavior, and account status filtering for campaign eligibility. It also details the three different approaches to trigger complete pagination, which goes well beyond what the input schema provides.
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 (prerequisite, critical note, pagination approaches, algorithm, account status) and uses bold headings effectively. While it contains multiple paragraphs, each sentence earns its place by providing essential information. The front-loaded purpose statement is clear, though some technical details could potentially be streamlined.
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 of pagination behavior, campaign prerequisites, and account eligibility requirements, the description provides complete context despite having no annotations and no output schema. It explains the tool's role in the workflow, how to use it effectively, what to expect from its behavior, and how to interpret the results for downstream operations like campaign creation.
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 100% description coverage, so the baseline is 3. However, the description adds significant value by explaining the interaction between parameters (e.g., how 'limit' interacts with 'get_all' and 'starting_after'), the practical implications of different limit values, and the three different approaches to trigger complete pagination. This provides context beyond the individual parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all sending accounts') and resource ('in the workspace'), distinguishing it from sibling tools like 'get_account_details' which retrieves details for a specific account. It explicitly identifies the resource as 'sending accounts' rather than generic accounts.
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: 'PREREQUISITE FOR CAMPAIGN CREATION: You MUST call this tool first before creating any campaigns.' It also explains the consequence of not using it: 'Campaign creation will fail if you use email addresses that are not returned by this endpoint.' This gives clear context for when this tool is necessary versus alternatives.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bcharleson/Instantly-MCP'

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