Mailchimp MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation3/5
Despite detailed descriptions, the sheer volume of 227 tools creates overlap and confusion. For example, multiple member tools (add_member, upsert_member, batch_subscribe) and equivalent delete operations (delete_member, delete_member_permanent) make it difficult for an agent to select the correct one without careful reading.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (e.g., create_campaign, list_audiences), but there are minor inconsistencies such as 'upsert_member', 'ping', 'describe_tools', and multi-word verbs like 'resend_to_non_openers'.
Tool Count1/5
With 227 tools, the server is massively over-scoped. The recommended range is 3-15; 227 is an extreme mismatch, making navigation and selection impractical for agents.
Completeness5/5
The tool set covers nearly every aspect of the Mailchimp API: audiences, members, campaigns, automations, e-commerce, templates, landing pages, surveys, file manager, and more. It includes full CRUD lifecycle operations with no obvious gaps.
Average 4.4/5 across 227 of 227 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on July 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description mainly confirms it's a read operation. It adds that it retrieves 'individual responses submitted to the specified survey' but no further behavioral details like error handling or rate limits. Since annotations cover the safety profile, the description adds minimal extra value.
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 one-line summary, a paragraph on pagination, and formatted Args/Returns sections. It is concise without unnecessary detail, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes pagination guidance and a return value specification, but the 'account' parameter is undocumented. An output schema exists, so return type is partially covered. Given the tool's complexity (4 params, one undocumented) and sibling tools, the description could be more complete by explaining the account parameter and possibly mentioning prerequisites or response structure hints.
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 explains three out of four parameters (survey_id, count, offset) with clear meanings and defaults, which adds value beyond the bare schema. However, it omits the 'account' parameter entirely, leaving it unexplained. Given 0% schema description coverage, this is a notable 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 that the tool lists responses for a single survey, using verbs 'List' and 'Retrieves'. It distinguishes from siblings like get_survey (survey details) and get_survey_response (single response) by specifying 'individual responses' and referencing the survey_id. However, it does not explicitly differentiate from list_survey_reports, but the context is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by mentioning pagination with count and offset. However, it does not specify when to use this tool versus alternatives like get_survey_response or list_survey_reports, nor does it give criteria for choosing this tool.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds the return format with specific fields. However, it doesn't mention pagination or rate limits, which would be helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a return format line, which is efficient and front-loaded with the main purpose. No fluff, but the return format could be integrated more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers the return structure but lacks explanation of the 'account' parameter and any pagination or sorting options. This leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'account'. The description does not mention this parameter at all, leaving agents without guidance on its purpose or usage.
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 starts with 'List account export jobs that have been requested for this Mailchimp account' which clearly states the verb and resource. It distinguishes itself from get_account_export by explaining the difference, and from create_account_export by implication.
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 says 'Use this to track export requests and discover export IDs and their status. Use get_account_export for the full record and download URL of a single export.' This gives clear context and directs to an alternative when needed.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds context that removed subscribers no longer receive emails, clarifying the behavioral implication beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and structured with Args and Returns. One sentence is slightly redundant ('no longer receive any emails') but overall efficient.
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 and presence of an output schema, the description adequately explains what is returned. However, the account parameter is undocumented, and the output schema reference is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only mentions workflow_id in Args but ignores the account parameter, leaving its purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'subscribers removed', and the context 'classic automation workflow', distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like get_automation_removed_subscriber or list_automations. It does not mention exclusions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover behavior (readOnlyHint false, etc.). Description adds manual-write context and return format, but lacks details on side effects, validation, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose first, then usage context, parameter list, and return. No fluff, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the key intent, partial update behavior, examples of updatable fields, and return value. Could mention behavior for invalid fields or impact on synced stores, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains store_id, product_id, and additional_fields with examples. However, the 'account' parameter is missing from the description, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update an existing product's ... metadata' and specifies partial update via additional_fields. However, mentioning 'images' as a field creates potential confusion with sibling tool update_store_product_image, slightly reducing clarity.
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?
Provides context that manual writes suit custom/headless storefronts vs automatic syncs, but does not explicitly differentiate from related tools like create_store_product, update_store_product_image, or update_store_product_variant.
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?
Annotations indicate non-readonly, non-idempotent, non-destructive. The description states the subscriber will receive the email once processed and mentions the return type (JSON describing the queued subscriber). It does not disclose whether duplicates are handled, what happens if the automation is paused, or any side effects, but adds some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose statement, a brief explanatory paragraph, then labeled Args and Returns sections. Information is front-loaded and 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?
Considering the tool has 4 parameters (3 required) and an output schema (mentioned as JSON), the description covers the core function and output format. However, it omits details like handling of duplicate queue entries, email format validation, limits, and the optional 'account' parameter's purpose. This leaves some uncertainty for complete 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?
Schema description coverage is 0%, but the description provides meaningful explanations for three of the four parameters (workflow_id, workflow_email_id, email_address). It clarifies each as 'unique id' of related entities. However, the optional 'account' parameter is not documented, leaving a gap. The description adds value but does not fully compensate for the missing schema descriptions.
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 action 'Add a subscriber to the queue of a classic automation email' and elaborates with 'Manually enrolls a subscriber into the sending queue for a specific automation email.' The verb and resource are specific, and the tool is clearly distinguished from siblings like 'add_member' and 'remove_automation_subscriber'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (manually enrolling a subscriber into an automation email queue) but does not give any guidelines on when not to use it or suggest alternatives. It lacks prerequisites or conditions (e.g., subscriber existence, automation status) that would help the agent decide.
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?
Annotations already indicate it's not read-only, idempotent, or destructive, so the description need not reiterate those. It adds value by disclosing the return structure (id, name, count). However, it does not discuss potential side effects, permissions, rate limits, or the behavior of the optional account parameter, 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 relatively concise with a brief intro followed by structured Args/Returns. It front-loads the core purpose. The Args/Returns section adds clarity but could be more compact. Still, no wasted sentences.
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 (2 params, 1 required) and presence of an output schema, the description covers creation, return values, and a sibling tool. However, the missing documentation of the 'account' parameter makes it incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It provides a clear example for 'name' but completely ignores the optional 'account' parameter. This is a significant omission, as the agent needs to know what 'account' refers to and when to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new folder') and the resource ('to organize templates'), distinguishing it from sibling create tools like create_campaign_folder and create_store by specifying 'template' context. The verb and resource are specific and unambiguous.
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?
Description provides context ('group related templates for easier navigation') and directs to list_template_folders for browsing, suggesting a clear workflow. However, it lacks explicit guidance on when not to use this tool or alternatives, e.g., if folders already exist or if other organizational methods are preferred.
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?
Annotations are all false (no readOnly, idempotent, or destructive hints), so the description carries the burden. The description correctly implies it is a mutation (not read-only) and states return value, but does not disclose side effects like irreversible changes, authorization needs, or rate limits. It adds moderate context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear first sentence and structured Args. It includes examples, but the length could be trimmed slightly. Overall, it is well-organized and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality and returns mention, but due to the missing 'account' parameter and assumption of prior knowledge about signup form structure (e.g., specific section names), it is not fully complete. The presence of an output schema (not shown) reduces the need to detail returns, but the parameter gap still holds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description's Args list covers 4 of 5 parameters (list_id, header, contents, styles) but omits the 'account' parameter present in the schema. It provides examples for header and contents, and explains section names, but the missing 'account' parameter is a significant gap, reducing usefulness for correct invocation.
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 customizes an audience's default signup form, specifying the components (header, content sections, and styles). It uses a specific verb ('Customize') and resource ('signup form'), and the presence of sibling tools like list_signup_forms differentiates it from inspection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'At least one of header, contents, or styles must be provided' and 'Use list_signup_forms first to inspect the current form and mirror its structure.' This tells when to use the tool and a prerequisite, but does not explicitly mention 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?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that deletion is irreversible and that templates become unfiled. However, it does not clarify behavior on repeated calls (idempotency) or provide additional context like authorization requirements or rate limits.
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, behavioral notes, usage tip, and parameter details. It is concise without unnecessary filler, though the 'Args' and 'Returns' sections are somewhat redundant given the schema and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: purpose, behavior, and usage guidance. However, lacks completeness for the 'account' parameter, error handling, and example usage. Given the simplicity of the tool (2 params, destructive operation), the description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only describes the required parameter 'folder_id' (obtain from list_template_folders) but omits the optional 'account' parameter entirely. This leaves a gap in understanding all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a template folder permanently') and specifies the resource (template folder). It distinguishes from sibling tools like delete_template (which deletes templates inside) and update_template_folder.
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?
Provides explicit guidance: 'Irreversible' and 'Deleting a folder does not delete the templates inside them; they become unfiled.' Also suggests using list_template_folders to obtain folder IDs. However, it does not explicitly mention when not to use this tool (e.g., alternative like updating the folder).
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat those. The description adds error behavior ('returns an error if API key is invalid') and return value details. However, it fails to explain the purpose of the 'account' parameter, leaving a gap in behavioral understanding. The parameter is undocumented despite being present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, usage guidelines, return details, and an example. It is mostly concise, though the return field listing could be slightly more streamlined. Every sentence adds 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?
For a read-only info tool with one optional parameter, the description covers return types and usage guidelines well. However, the missing documentation of the 'account' parameter makes it incomplete. The presence of an output schema (not shown) likely covers return structure, but the parameter gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'account' with no description (0% schema coverage). The tool description does not explain what this parameter does; it only shows an example call without arguments. The parameter's role (e.g., specifying a different account) is entirely unclear, providing no value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Mailchimp account details (name, contact info, total subscribers, industry benchmarks). The verb 'Retrieve' and resource 'Mailchimp account details' are specific. It distinguishes from sibling tools like ping (health check) and list_audiences (per-audience stats).
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?
Explicit guidance provided: 'Use this to verify API connectivity or inspect account-level metrics. Typically the first call in a workflow. Do not use this as a health check; use ping instead... Use list_audiences to get per-audience stats.' Alternatives and when-not-to-use are clearly stated.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: the subscriber is located by hashing the email, and it retrieves queue status. This adds value beyond annotations but does not disclose other behaviors like auth needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses a clear structure with a short paragraph followed by an args list. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description mentions returns. However, it lacks details on potential errors, prerequisites, or the hashing mechanism. The optional 'account' parameter is not addressed, and there is no guidance on when to use this vs list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains the three required parameters (workflow_id, workflow_email_id, email_address) with clear roles but omits the optional 'account' parameter. Thus, it adds meaning to most but not all parameters.
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 gets a single subscriber from the queue of a classic automation email. It uses a specific verb ('get') and resource ('subscriber'), and distinguishes itself from siblings like 'add_automation_queue_subscriber' (adds), 'get_automation_email_queue' (lists all), and 'get_automation_removed_subscriber' (gets removed).
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 the context (inspecting a specific subscriber's queue status) but does not explicitly state when to use this tool vs alternatives like 'get_automation_email_queue'. No direct when-to-use or when-not-to-use guidance 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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral detail beyond mentioning its role in verifying integration and returning empty if no integration. No side effects or auth needs are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the purpose front-loaded and usage guidance separated. The return format is included, but every sentence serves a purpose. Slightly verbose due to repeated returns format in both description and output schema.
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?
Despite having an output schema, the description includes the return format and usage guidance. However, it fails to cover the 'account' parameter, leaving the tool incompletely documented for a simple single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'account' with 0% description coverage. The description does not explain the meaning of 'account' at all, leaving the agent to guess its purpose. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists connected e-commerce stores with platform and currency info, specifying types like Shopify and WooCommerce. It distinguishes from sibling tools by explaining its role in discovering store IDs for other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for discovering store IDs for list_store_orders, list_store_products, and list_store_customers, and for verifying integration status before get_ecommerce_product_activity. This provides clear context, though it lacks explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows it is safe. The description adds that it retrieves reports and returns JSON, but does not elaborate on limits, account filtering behavior, or scenarios like empty results. It adds some context but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a parameter list. It is front-loaded with the main purpose and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description explains the core functionality and paging. However, it misses documenting the 'account' parameter, which limits completeness. Adequate but with a clear gap.
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 explains count and offset with defaults, but does not describe the 'account' parameter. This is a gap, though the two documented parameters add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List reports for all surveys' and specifies it retrieves aggregate performance reports across every survey in the account. This differentiates it from sibling tools like list_surveys (which lists surveys themselves) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides paging guidance with count and offset, but does not discuss when to use this tool versus alternatives or any exclusions. The context is clear but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation), idempotentHint=false, destructiveHint=false. The description adds context such as linking purchase activity and opt_in behavior, but does not mention idempotency, error handling for duplicate customer_id, or authentication requirements. It covers some traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, context, and Args/Returns list. It is front-loaded and each sentence serves a purpose, though a bit lengthy. No wasteful repetition.
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 complexity (6 parameters, no schema descriptions) and presence of output schema, the description covers purpose, usage context, returns, and most parameters. However, it misses the 'account' parameter and could clarify uniqueness constraints. It is mostly complete but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It describes 4 of 6 parameters explicitly (store_id, customer_id, email_address, opt_in_status) and adds detail for additional_fields with examples. The account parameter is entirely omitted, and the descriptions for main parameters only restate names, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a customer in a store' with a specific verb and resource. It also explains the opt_in_status purpose and distinguishes from automatic sync via Shopify/WooCommerce, aiding differentiation from other tools like create_store_cart or create_store_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'manual writes suit custom or headless storefronts' and implies not to use when automatic sync is active. However, it does not name specific alternative tools or provide explicit exclusion scenarios, so it's slightly below top score.
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?
Annotations already indicate destructive and idempotent behavior. The description adds valuable context: the irreversible nature, that Mailchimp stops sending callbacks, and HTTP 204 on success with 404 on invalid ID. This increases transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. Key information is front-loaded in the first sentence. Every sentence provides necessary details about usage, behavior, and return values.
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 simplicity and the presence of annotations and output schema, the description covers most aspects: purpose, irreversibility, consequence, error handling, and return format. The only gap is the optional 'account' parameter, which is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'batch_webhook_id' parameter well (what it is and how to get it), but the 'account' parameter is not mentioned. Partial compensation leads to a mid-range 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 tool deletes a batch webhook permanently. It uses a specific verb+resource combination. However, it does not explicitly distinguish this from the sibling 'delete_webhook' tool for regular webhooks, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite: using 'list_batch_webhooks' to obtain the ID. However, it offers no comparison to alternatives (e.g., update vs delete) and no when-not-to-use guidance. This makes it minimally adequate.
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?
Annotations already declare destructiveHint=true and idempotentHint=true. The description reinforces the destructive nature (cannot be undone) but does not clarify idempotency, leaving ambiguity about repeated calls. It adds value by describing the return format but overall does not significantly surpass annotation hints.
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, with an opening sentence summarizing the action, followed by context and an Args section. Every sentence adds value, though the extra context on store types could be seen as slightly tangential.
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 (delete operation), the description covers the main aspects: what it does, permanence, return values, and source for store_id. However, it lacks details on optional parameters, prerequisites, and behavior on repeated deletion, which 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 lists three of the four parameters (store_id, order_id, line_id) with brief explanations, such as obtaining store_id from list_ecommerce_stores. However, it fails to mention the optional 'account' parameter, and with 0% schema coverage, this omission is notable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it permanently deletes a line item from an e-commerce order, distinguishing it from deleting the entire order or store. It also mentions that for Shopify/WooCommerce, order lines are synced automatically, implying this tool is for manual/custom stores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says manual commerce writes suit custom/headless stores, and that Shopify/WooCommerce integrations sync order lines automatically, providing clear context on when to use this tool versus alternatives. However, it does not explicitly compare to sibling delete tools like delete_store_order.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about returned fields (email, opt-in status, order totals) but does not disclose behavioral details beyond what annotations provide.
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?
Concise: one sentence for purpose, one for usage, then structured Args and Returns. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and usage, references output as JSON object. But misses the 'account' parameter entirely, leaving a gap in completeness for a simple read tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters. It covers store_id and customer_id in Args, but omits the 'account' parameter (anyOf string|null) entirely. Incomplete coverage reduces score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a single store customer with specific fields (email, opt-in status, order totals). Distinguishes from siblings like list_store_customers and create/update/delete variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('inspect a customer's purchase history and subscription state') and references list_store_customers for discovering IDs. Does not mention when not to use, but context from siblings implies alternatives for mutations.
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?
Annotations already confirm readOnlyHint=true and destructiveHint=false. The description adds that it returns a JSON report, consistent with read-only behavior. No additional traits like pagination or authorization are disclosed, but annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded summary, followed by an elaboration, and structured args/returns. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and annotations cover safety. However, the description fails to explain the 'account' parameter and does not detail the contents of the questions report (e.g., counts, percentages). It is adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description partially compensates by explaining survey_id ('The unique id of the survey whose questions to report on') but completely omits the optional 'account' parameter. Users would not know what 'account' is for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the questions report for a single survey' and explains it retrieves aggregate reporting per question. It distinguishes from siblings like get_survey_report (overall report) and get_survey_question_answers (individual answers).
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 says 'Use this to understand how respondents answered across all questions,' providing clear context. However, it does not explicitly mention when not to use it or name specific alternatives like get_survey_report.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds value by mentioning the 404 error case and specifying output fields (status, url), but does not disclose authorization needs, rate limits, or pagination behavior. Given annotations cover the safety profile, the description provides moderate additional 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 efficiently structured: a one-sentence purpose statement, a brief usage paragraph, an error note, and an Args/Returns section. It front-loads the core purpose and avoids unnecessary detail, earning a high conciseness score despite missing one parameter explanation.
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 list tool with an output schema, the description covers the return structure (JSON with total_items and surveys arrays) and typical fields (id, title, status, url, timestamps). It also ties list_id to list_audiences. While pagination and empty result behavior are not addressed, the combination of description and output schema provides sufficient completeness for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (list_id and account) with 0% coeverage. The description only explains list_id ('Audience/list ID (from list_audiences)') and omits account entirely. This incomplete explanation fails to fully compensate for the lack of schema descriptions, leaving parameter meaning partially undefined.
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 'List all surveys for an audience with their status and public URL,' specifying the action (list), resource (surveys), and scope (for an audience). It also distinguishes from sibling tools like get_survey (for full detail) and publish/unpublish_survey (for changing live state), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'to discover survey_id values and see which surveys are live' and directs users to get_survey for full detail and publish/unpublish for state changes. It also mentions the 404 error for invalid list_id. However, it does not explicitly list all circumstances where this tool would be inappropriate relative to other siblings, slightly reducing guidance completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool resumes sending and is thus a mutation (consistent with annotations). It does not elaborate on side effects, idempotency, or what happens if the email is already running. The annotations already indicate non-read-only and non-destructive, so the description adds moderate value.
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 fairly concise, with a clear purpose statement followed by parameter and return details. Minor improvement could be merging the 'Args' section into prose, but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (3 parameters, no nested objects), the description covers the main action and required parameters. It mentions a JSON confirmation return but lacks details on error conditions or prerequisites. For a resume action, it is adequate but not comprehensive.
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 provides basic explanations for the two required parameters 'workflow_id' and 'workflow_email_id', which is helpful since the schema has no descriptions. However, the optional 'account' parameter is left undocumented, and the schema coverage is 0%, so the description should compensate more fully.
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 'start' and the resource 'automation email', specifying that it resumes a previously paused email in a classic automation workflow. It distinguishes itself from siblings like 'start_automation' and 'pause_automation_email' by focusing on a single email rather than the entire workflow.
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 explains that the tool is used to resume a paused automation email, providing context on when to use it. However, it does not explicitly mention when not to use it or offer alternatives, such as using 'start_automation' for the entire workflow.
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?
Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description doesn't need to restate those. The description adds no further behavioral details (e.g., what happens if the name already exists, authorization requirements). It is adequate but not enhanced.
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, with a clear definition, usage guidance, and separated Args/Returns sections. Some redundancy in the first line could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the main purpose, usage context, and return values (id, name, count). It could mention that the account parameter is optional, but completeness is largely sufficient.
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 meaning for the 'name' parameter ('Display name for the new folder') but does not mention the optional 'account' parameter. This partial coverage limits the semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'folder to organize campaigns'. It distinguishes from siblings like update_campaign_folder and list_campaign_folders by emphasizing creation and organization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use to group related campaigns' and gives examples. It also mentions an alternative tool (list_campaign_folders) for browsing. However, it does not explicitly state when not to use this tool.
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?
Annotations indicate readOnlyHint=true, and the description states 'Retrieves the configuration and status,' consistent with a read operation. No additional behavioral detail beyond annotations is provided, and there is no contradiction.
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 a front-loaded purpose sentence followed by a docstring block. It avoids verbosity, though the 'Args' section partially duplicates schema titles.
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?
With an output schema present, the return value is adequately specified as 'JSON with the automation email details.' The description covers the core purpose and parameter roles, but lacks mention of prerequisites or error conditions, which are minor 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's 'Args:' section explains the two required parameters (workflow_id and workflow_email_id). However, the optional 'account' parameter is not described, leaving a gap for that parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a single email in a classic automation workflow,' specifying the verb and resource. It distinguishes from sibling tools like 'get_automation_emails' (plural) by emphasizing the singular email context and requiring workflow_email_id.
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 includes explicit usage context: 'Use this to inspect a specific step before pausing, starting, or queueing subscribers.' It provides clear guidance on when to invoke this tool, though it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it retrieves a report with response rates and engagement, which is consistent and minimally expands beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear heading, a short paragraph, and structured Args/Returns sections. Slight redundancy between first two lines, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers what the tool does and when to use it. It mentions the report content (response rates, engagement) and identifies the required parameter. Missing account parameter explanation is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage. Description explains survey_id as 'the unique id of the survey to report on', which adds meaning for that required parameter. However, the optional 'account' parameter is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'report for a single survey', and distinguishes from sibling tools like get_survey or list_survey_reports by specifying 'single survey' and 'detailed performance report'.
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?
States 'Use this to review response rates and engagement for a specific survey', providing clear context. Lacks explicit exclusions or direct comparisons to alternatives, but the purpose is well delineated.
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?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral disclosure beyond that. It confirms the tool retrieves response details but does not mention any side effects, rate limits, or authorization needs.
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 reasonably concise with a clear structure (brief title, paragraph, Args/Returns sections). The Args section is somewhat redundant with the schema but adds brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with annotations and an output schema, the description covers the main points. The omission of the optional account parameter is a minor gap, but overall it is complete enough for an agent to understand and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains survey_id and response_id briefly but omits the optional account parameter completely. Thus, it adds partial meaning but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single survey response, using specific verbs ('Get', 'inspecting answers') and the resource ('survey response'). It distinguishes from sibling tools like get_survey_responses (list) and get_survey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to use this tool to inspect individual respondent answers, implying when to use vs. listing all responses. It does not explicitly state when not to use, but the context is clear.
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?
Annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds that the tool retrieves aggregate performance reports and returns JSON, with pagination support. While it doesn't disclose rate limits or performance implications, the combination of annotations and description gives sufficient 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 short and front-loaded: a single sentence stating purpose, followed by a paragraph explaining parameters and return. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the return description is adequate. However, the description lacks explanation of the account parameter's behavior (e.g., default account when null). With 3 optional parameters and pagination described, the tool's complexity is moderate, but the missing parameter information leaves a gap 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 explains the 'count' and 'offset' parameters with defaults and purpose (pagination), but completely omits the 'account' parameter. Since schema description coverage is 0%, the description is expected to compensate but fails to describe one of three parameters, leaving its role ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists reports for all landing pages, using verbs like 'list' and 'retrieves' with the resource 'aggregate performance reports across every landing page'. This distinguishes it from sibling tools like list_landing_pages (which lists landing pages themselves) and get_landing_page_report (which likely gets a single report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides pagination guidelines ('Use count and offset to page through large result sets') but does not explicitly state when to use this tool versus alternatives like get_landing_page_report for individual reports or list_landing_pages for landing pages. The context of listing all reports is implied but not contrasted with siblings.
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?
Annotations already indicate non-readOnly, non-idempotent, non-destructive behavior. The description adds that it creates a comment and optionally attaches to a block, but does not elaborate on side effects, permissions, or rate limits. The added context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear structure. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage context, parameter guidance, and return value. It could mention that the campaign must exist or handle errors, but overall it is adequate for 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?
With 0% schema description coverage, the description explains 3 of 4 parameters (campaign_id, message, block_id) in detail, including how to obtain campaign_id. However, the 'account' parameter is not mentioned, leaving a gap. This adds value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a team collaboration feedback comment'), the resource ('campaign'), and its purpose. It distinguishes from sibling tools like list_campaign_feedback (review) and delete_campaign_feedback, making it easy to select.
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 explains when to use the tool ('during campaign preparation') and references an alternative for viewing comments ('Use list_campaign_feedback'). It does not explicitly mention when not to use it, but provides adequate context.
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?
Annotations indicate destructive and idempotent; description confirms 'permanently' and 'Irreversible.' Adds return format details, no contradiction.
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?
Concise, front-loaded with key info, includes structured args/returns. Could be slightly tighter but efficient overall.
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?
Adequately covers purpose, usage, and params for required fields. Missing handling of optional parameter and error scenarios, but output schema and annotations fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description lists required parameters and sources, but omits optional 'account' parameter. Provides moderate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a campaign feedback comment permanently' and distinguishes it from siblings like update_campaign_feedback by emphasizing irreversibility.
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?
Provides context for when to use (remove obsolete collaboration note) and directs to list_campaign_feedback for IDs. Lacks explicit when-not-to-use, but context with siblings is clear.
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?
Annotations already declare destructiveHint=true and idempotentHint=true. Description adds 'Irreversible' and explains consequence (domain unusable until re-verified). This enriches the annotation information without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a one-sentence purpose, a warning, then parameter section. Information is front-loaded and every sentence adds value. No 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?
The description covers the action, consequences, and domain_name source. However, it omits the account parameter and does not mention possible errors or response details (though output schema exists). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only domain_name is described with an example and a source (list_verified_domains). The account parameter is not mentioned at all. Since schema description coverage is 0%, the description should cover all parameters; missing one is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (delete) and resource (verified sending domain), with permanent deletion emphasized. Distinct from siblings like create_verified_domain and verify_verified_domain.
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?
Provides explicit usage context: warns of irreversibility, mentions need for re-verification, and references list_verified_domains to obtain domain names. Does not explicitly state when not to use, but clear enough.
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?
Annotations indicate readOnlyHint=true, so the description adds value by specifying the report contains visits, conversions, and metrics. While the return format is vaguely described as 'JSON with the landing page report', it provides sufficient behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The Args section is redundant with the schema but useful given the schema lacks descriptions. Overall, it earns its place without being verbose.
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?
The description includes return content (visits, conversions, etc.) and distinguishes from similar tools. While it does not mention error handling or pagination, the output schema exists to fill in structural details, making it fairly complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for all parameters. It only documents outreach_id in the Args section, omitting the optional account parameter entirely. This leaves the agent uninformed about when to provide an account, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a detailed performance report for a single landing page using an outreach id. It distinguishes from siblings like get_landing_page (page details) and list_landing_page_reports (list of reports), ensuring no ambiguity.
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 advises using this tool to review visits, conversions, and other metrics for a specific page, which guides its use. However, it does not explicitly mention when not to use it or direct to alternatives like list_landing_page_reports for multiple pages.
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?
Annotations (readOnlyHint: true, destructiveHint: false) already indicate a safe read operation. The description adds that it retrieves answers and returns JSON, but does not detail other behavioral aspects like rate limits or authorization. Value added beyond annotations is moderate.
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?
Description is very concise: one sentence for purpose followed by structured Args section. Every sentence adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return format fully. It covers required params, pagination, and basic return structure. However, the undocumented 'account' parameter is a minor gap, preventing a perfect score.
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 documentation coverage is 0%, so description carries the burden. It explains survey_id, question_id, count, and offset with defaults and purpose. However, it omits the 'account' parameter (present in schema), leaving it undocumented. Thus, partial but not complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List answers for a single survey question' with specific verb 'list' and resource 'answers for a single survey question'. It distinguishes from sibling tools like get_survey_responses by emphasizing 'one specific question' and requiring both survey_id and question_id.
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?
Description provides clear usage context: retrieving answers for a specific question within a survey, with pagination guidance (count and offset). While it does not explicitly state when not to use it or name alternatives, the context of sibling tools makes differentiation clear.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds the return format (JSON with total_items and apps array) and details about the app fields (id, name, description, users). This is useful context beyond annotations, though it does not cover rate limits or auth scopes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs: purpose, usage guidance, and return format. Front-loaded with the core action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return format and usage context, and the annotations provide safety profile. However, the complete omission of the 'account' parameter means the tool is not fully self-explanatory. Given the low complexity and good output schema description, the gap is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has an optional parameter 'account' with 0% schema description coverage. The description does not mention or explain this parameter at all, leaving its purpose and usage completely undocumented. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists OAuth-authorized apps for the Mailchimp account. It explicitly distinguishes itself from the sibling 'get_authorized_app' by noting that tool retrieves full details of a single app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to audit which third-party apps are connected and discover their IDs' and directs to the alternative 'get_authorized_app' for full record of a single app. Provides clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it returns JSON with total_items and webhooks array containing id, url, enabled. This is useful behavioral context beyond the annotation, though pagination details are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus a return line. First sentence states purpose, second explains concept, third provides usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Returns format is explained (total_items and webhooks array) and output schema exists, reducing burden. However, the missing parameter explanation for 'account' leaves a gap in completeness. No mention of empty results or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'account' has no description in the schema (0% coverage) and the tool description does not explain its purpose or effect. The agent cannot determine how to use this parameter from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all configured batch webhooks for the account.' The verb 'list' and resource 'batch webhooks' are specific. It distinguishes from get_batch_webhook by mentioning inspection of individual webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use to discover batch_webhook_id values' and references get_batch_webhook for detailed inspection. Provides context for when to use this tool but does not explicitly mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior. The description adds context about the return format (JSON with total_items and domains array) and the scope (verified domains for the account). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main action in the first sentence, followed by usage guidance and a clear return format description. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with a single optional parameter and an output schema, the description fully covers the purpose, usage, and return format. It provides all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'account' with 0% description coverage. The tool description does not mention this parameter or its meaning, leaving the agent with no additional semantic cues beyond the schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'sending domains verified for use with this Mailchimp account'. It also distinguishes from the sibling 'get_verified_domain', which retrieves a single domain's full record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: to discover approved domains and check verification/authentication state. It also directs users to 'get_verified_domain' for a full record of a single domain, providing an alternative. However, it lacks an explicit 'when not to use' statement.
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?
Annotations indicate non-readonly, non-idempotent, non-destructive. Description adds that it returns 404 on invalid IDs and that toggling enabled does not delete redemption history. This is useful but does not contradict annotations. It doesn't describe additional side effects or authorization needs.
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 reasonably concise, with clear sections for common use, error handling, args, and returns. The Args block repeats param names but is still efficient. Could be slightly more terse.
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 presence of an output schema, the description adequately explains returns. However, it omits the 'account' parameter and does not clarify partial update behavior (e.g., leaving fields null). For a 7-param tool with 0% schema coverage, the description should cover all parameters.
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 clear explanations for most parameters (store_id, promo_rule_id, promo_code_id, code, redemption_url, enabled), including that code is case-insensitive. However, it misses the 'account' parameter present in the input schema, causing a slight gap. Schema coverage is 0%, so description compensates well but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a promo code's string, redemption URL, or enabled state, and explicitly differentiates from moving a code to a different rule (which requires delete and re-create). It distinguishes itself from sibling tools like create_promo_code and delete_promo_code.
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?
Provides a common use case (toggling enabled=false after campaign end) and a limitation (cannot move to different rule). Mentions 404 error for invalid IDs. However, it does not explicitly compare to update_promo_rule or other update tools.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds context about idempotency (unique order_id) and creation behavior, but does not disclose any further side effects or failure modes. Adequate but not exceptional.
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: a few sentences and a bulleted args list. It front-loads the purpose and then details. Efficiently uses space, though the return type mention could be integrated; still good.
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 (6 params, nested objects, many siblings) and presence of output schema, the description covers essential usage. It explains prerequisites, parameter requirements, and return format. Could include more on error handling, but overall 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?
Despite 0% schema description coverage, the description explains each key parameter: store_id, order_id, customer, lines, additional_fields. It adds constraints like 'client-supplied and must be unique', 'customer must include id', and 'lines require id, product_id, product_variant_id, quantity, price'. The account parameter is omitted but optional with default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an e-commerce order in a store with a customer and line items'), specifying the verb, resource, and scope. It distinguishes this tool from siblings like create_store_cart and create_store_customer.
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?
Provides explicit guidance: explains when to use manual commerce vs automated integrations (Shopify/WooCommerce), notes that order_id must be unique and customer must already exist or be provided with required id, and directs to list_ecommerce_stores for store_id. Missing explicit when-not-to-use but sufficient.
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?
Annotations include destructiveHint and idempotentHint, but the description adds valuable context: 'This cannot be undone' and the last variant constraint. These details go beyond the annotations, though some aspects like error handling or permissions are not covered.
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 purpose, followed by key constraints, then parameter listings. It is concise and well-structured, though the Args/Returns section adds some redundancy that could be streamlined.
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 destructive nature and four parameters, the description covers purpose, constraints, parameter roles, and return format. It lacks some details on error states (beyond last variant) and prerequisites, but is mostly 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?
With 0% schema description coverage, the description explains three of four parameters (store_id, product_id, variant_id) with brief descriptions. However, the optional 'account' parameter is ignored entirely, leaving it undocumented.
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 'Permanently delete a single variant from a product in a store', using a specific verb and resource. It distinguishes itself from sibling delete tools like delete_store_product by targeting variants specifically.
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 a clear condition: 'A product must retain at least one variant, so deleting its last variant may be rejected by the API.' This gives context on when not to use the tool, but does not explicitly compare to alternatives like updating a variant's status.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable behavioral context: it's a polling operation, status transitions (pending, started, finished), and the response_body_url condition. However, it doesn't mention idempotency or rate limits, which are minor 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?
Well-structured with paragraphs, Args/Returns sections, and an example. Front-loaded with purpose. Every sentence adds value, though it could be slightly more concise. Minor redundancy in the returns section (e.g., repeated 'finished' status).
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 output schema exists, the description adequately explains return fields and usage pattern. However, the missing account parameter and lack of error handling or edge cases (e.g., what if batch_id is invalid?) reduce completeness. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It thoroughly explains batch_id (format, source, example) but completely ignores the optional account parameter. This is a significant omission for a tool with undocumented 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: 'Check the progress and completion status of an asynchronous batch operation.' It uses a specific verb ('check') and resource ('batch operation'), and distinguishes from siblings by referencing create_batch and list_batches.
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?
Provides explicit guidance: 'Use after create_batch to poll for completion. Call repeatedly until status is finished. Do not use for non-batch operations. Use list_batches to see all recent batch operations.' This clearly states when to use, when not to use, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) already establish the tool as non-destructive and read-only. The description adds that a 404 error occurs for invalid file_id, which is useful but minimal additional behavioral disclosure beyond what annotations provide.
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 three sentences plus a structured arguments/returns section, all within a concise paragraph. Every sentence adds value, with no redundancy. The front-loaded purpose sentence immediately orients the user.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage context, parameter semantics, return value (with a JSON field list), and error behavior. It is complete and self-contained, requiring no additional context from siblings or other sources.
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 compensates by explaining the required file_id parameter (numeric, from list_files), which adds meaning beyond the schema. However, the optional account parameter is not mentioned, leaving it unexplained. This partial coverage justifies a score of 3.
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 'Retrieve full metadata for a single File Manager file', specifying the verb and resource. It further details what metadata includes (hosted URL, dimensions, folder) and distinguishes from siblings like list_files and delete_file. The description fully communicates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool: 'Use when you have a file_id (from list_files) and need its hosted URL, dimensions, or folder.' It also directs users to list_files for discovery. While it does not explicitly exclude alternative scenarios, the guidance is clear and practical.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about return fields and script installation status. No contradictions, and the description adequately supplements annotations with behavioral specifics.
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?
Description is concise and well-structured with purpose first, then usage guidance, then return format. Minor redundancy (e.g., repeating 'sites') but overall efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and return format. However, fails to explain the account parameter, which is a notable gap given the parameter exists and is undocumented. With output schema present, return details are less critical, but parameter omission hinders completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'account' has 0% schema description coverage and the description does not mention or explain it. Although it's optional with default null, the agent receives no guidance on its meaning or usage, failing to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (list all sites) and resource (connected sites). It specifies the context (Mailchimp account for tracking and pop-up forms) and distinguishes from sibling get_connected_site by indicating when to use each tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool for discovering site IDs and checking script installation status, and directs to get_connected_site for full single-site records. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description confirms it is a read-only listing operation. It adds value by detailing the return structure (total_items, folders array with id, name, count of templates). There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured with sections for purpose, usage, and returns. It could be slightly more succinct in the parameter explanation, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately summarizes the return structure. It covers pagination and the main use case. The missing account parameter is a minor gap, but overall the description is complete enough for a list 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?
The description explains the 'count' and 'offset' parameters with ranges and defaults, and hints at their pagination use. However, the schema includes a third parameter 'account' that is not mentioned in the description, and with a schema coverage of 0%, the description should compensate more thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'folders used to organize templates,' and specifies the use case of discovering template folder IDs before creating or organizing templates. This effectively distinguishes it from sibling tools like create_template_folder, get_template_folder, and delete_template_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('discover template folder IDs before creating or organizing templates'), and explains pagination ('Paginate with count and offset when total_items exceeds count'). However, it does not explicitly mention when not to use it or list alternative 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?
The description discloses return behavior: returns an error object if key is invalid/missing, and outlines the return JSON. The annotations (readOnlyHint=true) already indicate a safe read operation, and the description adds context about error handling and return format without contradicting annotations.
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 brief, uses bullet points for return info, and every sentence adds value: purpose, usage hint, error behavior, return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with an output schema, the description covers purpose, usage guidance, and return format. The only gap is the undocumented optional parameter, which for a 'ping' operation may be minor but still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'account' with no description (0% coverage), and the tool description does not explain its purpose or effect. The description fails to add any meaning beyond the schema, leaving the agent uninformed about this parameter.
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 checks API connectivity and validates API keys, using the specific verb 'check' and resource 'connectivity/key validity'. It distinguishes itself from the sibling tool 'get_account_info' by noting that is for account details, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is the 'fastest health check available' and advises using 'get_account_info instead if you need account details', providing clear context for when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context: 'Permanently removes ... cannot be undone through the API.' This goes beyond the annotations (which do not mark it as destructive) by clarifying the irreversible nature of the action. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary sentence, a paragraph on permanence, and clear Args/Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete: it explains the effect (permanent removal, no further emails, irreversible), specifies 'classic automation,' and references an output schema (present in context). No additional context 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?
The description documents two required parameters (workflow_id, email_address) with brief explanations in Args, but the optional 'account' parameter is not mentioned. With 0% schema description coverage, the description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it removes a subscriber from a classic automation workflow. The verb 'remove' and resource 'automation subscriber' are specific, and the tool is distinct from siblings like add_automation_queue_subscriber or get_automation_removed_subscriber.
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 removing subscribers from automations but does not explicitly state when to use it versus alternatives like unsubscribe_member or remove_members_from_segment. No when-not-to-use guidance is provided.
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?
Adds behavioral context beyond annotations: partial update (only supplied fields changed), returns updated store object. Does not mention authorization or idempotency but covers key 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?
Efficient structure: first sentence states purpose, then usage note, then args and returns. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good for a simple update tool, but missing explanation of account parameter and error conditions. Could mention prerequisites like store existence.
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 coverage, description must compensate. It explains store_id and additional_fields with examples, but misses the 'account' parameter. Adds some meaning but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it updates an existing e-commerce store's name, currency, etc., with a specific verb and resource. Distinguishes from create_store and get_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says manual writes suit custom/headless storefronts vs auto-synced stores. No alternative tool names, but context is clear on when to use.
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?
Annotations are all false (no readOnly, idempotent, destructive), but description adds important behavioral context: note is internal, not sent to contact, max 1000 chars, and error responses. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: purpose first, then usage guidance, error conditions, and Args listing. It is front-loaded with key information. Slightly verbose with example notes but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, error conditions, and return fields (implied output schema exists). Missing explanation of the optional 'account' parameter and any authentication/permission requirements. Sufficient but not thorough.
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 description must explain parameters. It explains list_id, email_address, and note with context (source for list_id, existence constraint, note length and format). However, the optional 'account' parameter is completely omitted, leaving one parameter undocumented.
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 adds a CRM-style internal note to a member and emphasizes it is not sent to the contact. It differentiates from sibling tools like update_member_note by explicitly saying to use that for editing.
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?
Provides explicit guidance: useful for sales/support context with examples, and when to use update_member_note instead. Also mentions error conditions (404, 400) which helps the agent decide when to call this tool.
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?
Annotations are neutral; description adds value by noting the URL must be publicly reachable and describing error behavior on rejection. Discloses creation side-effect but does not cover idempotency.
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?
Efficient prose: two sentences for purpose/guidance, then structured Args/Returns. No fluff, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, return values, and error case. Missing explanation of account parameter, but given output schema exists and tool is simple, overall fairly 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?
Describes url parameter well but omits the optional account parameter entirely. Schema coverage is 0%, so description partially compensates but leaves a gap for account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new batch webhook' and explains its function to notify a URL on batch completion. Distinguishes from sibling tools like get_batch_status, update_batch_webhook, and delete_batch_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool instead of polling get_batch_status, and mentions update/delete for modifications. Lacks explicit when-not-to-use guidance, but provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool requires at least one variant and is for manual writes, which aligns with the annotations (non-readOnly, non-idempotent, non-destructive). However, it does not disclose potential side effects like overwriting an existing product_id or required permissions, leaving gaps despite basic 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 well-structured with a brief intro, Args list, and Returns note. It is front-loaded, concise, and contains no unnecessary words or repetition.
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?
The description covers the core functionality, variant requirement, integration context, and parameter details. With an output schema present, return value explanation is sufficient. It lacks error cases and permission requirements but is fairly complete for a creation 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's Args section adds significant meaning for each parameter except 'account'. It explains the format and requirements for 'variants' and 'additional_fields', providing crucial context 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 it creates a product in a store and requires at least one variant, distinguishing it from sibling tools like create_store_product_variant. It also provides context about automatic vs manual storefronts, clarifying its specific use.
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 explains that products need variants and that manual writes are for custom/headless storefronts, providing context for when to use this tool. However, it does not explicitly exclude alternative scenarios or mention 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?
Annotations indicate non-read-only, non-idempotent, non-destructive. The description adds integration context but does not disclose much beyond what annotations imply (e.g., no mention of uniqueness constraints or potential errors). No contradiction.
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 succinct, well-structured with a summary, usage note, and parameter list. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations, the description adequately covers purpose, usage, parameters, and return format. Some missing details about prerequisites or errors, but generally 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?
Schema coverage is 0%, but the description explains all parameters except 'account', providing examples for 'title' and 'additional_fields'. This adds 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 action ('Add a new variant'), the resource ('to an existing product in a store'), and provides context ('distinct SKU, size, or color'). It distinguishes from sibling tools like create_store_product and update_store_product_variant.
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 advises that many stores sync variants automatically via Shopify or WooCommerce, positioning this tool for custom or headless storefronts. This provides clear usage context, though it could explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true and idempotentHint=true. Description adds that deletion is permanent and irreversible, and importantly that campaigns are not deleted but become unfiled. This extra context about side effects goes beyond annotations.
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?
Very concise: three sentences plus Args/Returns sections. Front-loaded with purpose. No unnecessary words. Structured clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, parameter guidance, and return format. Lacks mention of error cases or prerequisites (e.g., permissions). For a simple delete tool, it is fairly complete, especially with output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description explains folder_id well ('Campaign folder ID to delete. Obtain from list_campaign_folders'), but completely ignores the optional account parameter. Partially compensates for the required param but misses half.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a campaign folder permanently' with specific verb and resource. It distinguishes itself from other delete tools by clarifying that campaigns inside are not deleted. This differentiates it from sibling delete tools like delete_campaign.
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?
Provides clear context for when to use (delete folder permanently) and important behavior (campaigns become unfiled). Mentions using list_campaign_folders to get IDs. However, it does not explicitly state when not to use or compare with alternatives like delete_campaign.
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?
Discloses 'Cannot be undone' and 'Permanently delete' beyond annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true). Notes that 404 is returned for nonexistent entities, which adds value. No contradiction with annotations.
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?
Front-loaded with purpose, then usage guidelines, then parameter documentation. Every sentence adds value with no repetition or fluff. Well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: deletion action, permanence, prerequisites, error behavior, and success response format. Missing explanation of the optional 'account' parameter. Overall adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains list_id, email_address, and note_id with origins (list_audiences, member, list_member_notes). However, the optional 'account' parameter in schema is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a note attached to a member' with a specific verb and resource. Distinguished from siblings like delete_member and update_member_note by clarifying it only affects the note, not the member.
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?
Provides explicit guidance: 'Use list_member_notes to find note_ids before calling.' Mentions prerequisites and the 404 return if note or member doesn't exist. Does not compare directly to alternatives but gives clear context for correct usage.
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?
The description adds context beyond annotations: mentions irreversibility, that it doesn't affect campaigns using the template, and returns 404 for invalid IDs. Annotations already indicate destructiveHint=true and idempotentHint=true, so the description complements well.
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: a purpose sentence, then bullet points for behavior, followed by args and returns sections. Every sentence adds value, no fluff.
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 output schema exists, the description does not need to explain return values but includes a return format. It mentions error conditions (404). Missing explanation for the 'account' parameter slightly reduces 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 meaning for template_id: numeric string format and requirement to be type 'user'. However, it does not mention the optional 'account' parameter at all. Schema coverage is 0%, so description should cover all params; it partially covers one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a user-created template permanently.' It specifies the verb (delete) and resource (template) with a qualifier (user-created), distinguishing it from other delete tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Only works for user-created templates; gallery and base templates cannot be deleted.' It also advises using list_templates to find IDs. However, it does not explicitly suggest an alternative for deleting non-user templates.
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?
Annotations already indicate readOnlyHint=true; description adds output format (JSON with total_items, clients array), pagination via offset, and parameter constraints (list_id format). No side effects mentioned but not needed given read-only nature.
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?
Well-structured: summary, usage guidance, then Args and Returns sections. Clear without unnecessary words. Could be slightly more concise in return description but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description provides purpose, usage, parameter details, and return structure. Missing the account parameter is a gap, but the output schema exists (not shown) to supplement. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain all parameters. It covers list_id, count, offset with format, defaults, and usage, but misses the 'account' parameter entirely. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: 'List the top email clients...' with examples (Gmail, Apple Mail, Outlook). It distinguishes from sibling get_audience_top_locations, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (informing email rendering/design decisions) and when not to (use get_audience_top_locations for geographic distribution). Also guides on obtaining list_id from list_audiences.
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?
Annotations already declare readOnlyHint=true, so the description is consistent. It adds context that the tool returns scheduled send times and an example response, which is valuable beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence for purpose, one for usage, then Args, Returns, Example sections. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 3 parameters and an output schema, the description is nearly complete. It explains how to obtain parameter values, describes the return format, and gives an example. The only minor gap is the undocumented account parameter.
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 explains automation_id (obtain from list_automations) and email_id (obtain from get_automation_emails), and provides example values. However, the optional 'account' parameter is not mentioned, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the queue of subscribers about to receive a specific automation email with scheduled send times. It uses a specific verb ('Retrieve') and resource ('queue of subscribers'), and distinguishes from sibling tools like get_automation_emails and add_automation_queue_subscriber.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use get_automation_emails first to obtain email_id values, and states 'Use to see who is waiting to receive a particular email in a workflow.' This provides clear sequential context. It does not specify when not to use, but for a read-only tool, exclusions are less critical.
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?
Annotations already declare readOnlyHint=true, and the description reinforces a read-only retrieve operation. It adds valuable context about the return format (JSON fields) and error handling (404), going beyond annotation data. However, the optional 'account' parameter is not explained.
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, with a clear first sentence, usage note, error note, and structured Args/Returns sections. Every part adds value, though it could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (get one page by ID) and the description covers the required parameter, return fields, and error case. However, the omission of the 'account' parameter leaves a completeness gap, especially since the tool has an output schema described in the description but no explicit schema tag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so the description must compensate. It explains page_id well (alphanumeric, obtained from list_landing_pages), but completely omits the 'account' parameter, leaving its purpose unclear. This partial coverage justifies a mid-range score.
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 'Retrieve full details of a landing page' with a specific verb and resource, and distinguishes itself from siblings like list_landing_pages and create_landing_page by focusing on full details of a single page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Use list_landing_pages to browse all pages and discover page IDs', providing a direct pointer to a sibling tool for discovery. Also notes the 404 error condition for invalid page_id, guiding proper 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat these. It adds that the tool returns a JSON product object including variants array, which provides additional behavioral context. However, it does not disclose other traits like authentication or rate limits, which are not expected given the read-only nature. Overall, adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose statement, usage guidance, parameter descriptions, and return value note. Every sentence adds value, with no unnecessary repetition or fluff.
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 that an output schema exists, the description adequately explains the return value as a JSON product object with variants. It also provides parameter sourcing. It does not cover error conditions or limitations, but for a straightforward retrieval tool, it is sufficiently 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 has 0% description coverage, so the description carries the burden. It provides meaningful guidance for the two required parameters (store_id from list_ecommerce_stores, product_id from list_store_products). It does not describe the optional 'account' parameter, but the majority of parameters are well-explained, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single product from a store with its variants and details. It uses specific verbs ('retrieve', 'inspect') and distinguishes itself from the sibling tool 'list_store_products' which is for browsing and discovering product IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'list_store_products' to browse and discover product IDs, providing a clear alternative for when to use this tool vs. others. It does not mention all possible alternatives but is sufficient for the primary use case.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so safety profile is covered. Description adds no new behavioral traits beyond confirming it lists recent operations, but does not disclose permissions, rate limits, or side effects. Adequate but not enhanced.
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?
Description is front-loaded with purpose, includes a structured Args/Returns block, and is concise. Minor verbosity in the Returns section but overall good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation, 3 parameters, output schema present), the description covers purpose, parameter details, return format, and sibling guidance. No gaps for an agent to misuse the 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?
Description explains count (range, default) and offset (pagination usage) but omits the account parameter entirely. With 0% schema description coverage, this leaves one parameter undocumented, though the other two are well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent batch operations with status/progress, and explicitly distinguishes itself from the sibling get_batch_status by directing users to that tool for detailed progress on a specific batch.
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?
Provides explicit guidance on when to use this tool vs get_batch_status, and includes pagination advice with offset parameter usage.
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?
Annotations already indicate readOnlyHint=true, so the tool is understood as a safe read operation. The description adds return format details but does not mention additional behavioral traits like rate limits or permissions. Still, it complements annotations well.
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?
Concise and well-structured: purpose, usage guidance, parameter explanation, and return format in a few clear sentences. No unnecessary 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 simplicity and the existence of output schema, the description covers essential aspects: what, when, how to get campaign IDs, and return fields. It misses the account parameter and potential pagination, but overall sufficient for a list 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 explains the campaign_id parameter and how to obtain it, adding value beyond the schema. However, it does not mention the optional account parameter, leaving it undocumented. With schema description coverage at 0%, it partially compensates but is incomplete.
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 'List team collaboration feedback comments on a campaign' with a specific verb and resource. It distinguishes from sibling tools like get_campaign_feedback for single comment details.
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?
Provides context for use: 'Use to review internal notes...' and directs to get_campaign_feedback for single details and get_campaign_details for IDs. Lacks explicit 'when not to use' but implies it through differentiation.
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?
Annotations already indicate read-only. The description adds valuable details on return structure (total_items, folders array) and pagination behavior (offset usage). No contradictions.
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?
Concise with a brief purpose, usage guidelines, and clear Args/Returns sections. No extraneous text, though slightly verbose for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and most parameters, but missing explanation for the optional account parameter. Output schema present, reducing need for return details. Not 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?
With 0% schema coverage, the description defines count and offset (range and purpose) but omits the account parameter. Adds meaning for 2 of 3 parameters, partially compensating for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists folders in the account's File Manager, a specific verb+resource. It distinguishes from siblings like list_files and upload_file by explicitly mentioning their use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to discover folder_id for uploads via upload_file. Also directs to list_files for seeing files themselves, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the purpose and return format (JSON with store_id, promo_rule_id, etc.), but doesn't discuss pagination behavior beyond parameters or any other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first line, a brief paragraph explaining codes, followed by Args and Returns sections. Every sentence is informative and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema has 5 parameters (including account), the description covers the main ones. An output schema exists, and the description outlines the return structure. Lacks coverage of the account parameter, but overall sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains store_id, promo_rule_id, count (range and default), and offset (pagination). This adds meaning beyond the schema parameter names, though 'account' parameter in schema is not mentioned.
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 'List the redeemable codes attached to a promo rule' with specific examples like 'SUMMER20', 'VIPONLY'. It distinguishes itself from sibling tools like create_promo_code, delete_promo_code, get_promo_code by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that codes are what customers type at checkout and that a single rule can have many codes, providing context. It also mentions obtaining promo_rule_id from list_promo_rules. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's addition of pagination behavior and return format adds value but does not contradict or significantly expand beyond those annotations.
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?
Concise and well-structured: purpose statement, usage guidance, then Args and Returns sections. No unnecessary 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?
Covers purpose, usage, parameters, and return format. Missing explanation of the 'account' parameter and potential errors, but given the tool's simplicity and the presence of an output schema, it is largely 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?
Describes 4 of 5 parameters (store_id, product_id, count, offset) with defaults and max. Misses the optional 'account' parameter. With 0% schema coverage, this is good but not fully 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 clearly states it lists variants of a product in a store with pagination, distinguishing it from sibling tools like get_store_product_variant (single variant) and create/delete/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using it to browse product variants and discover variant_ids, with pagination instructions. Could mention when to use get_store_product_variant instead, but the context of siblings implies the distinction.
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?
Description adds value beyond annotations by explaining the mutating action and noting that queued subscribers remain queued. No contradictions with annotations. Could mention reversibility (via start_automation_email) for completeness.
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?
Description is concise with a clear summary, behavioral details, and structured Args/Returns sections. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the tool's behavior and return type given the presence of annotations and output schema. Minor gaps: missing account parameter explanation and context on when it is valid to pause (e.g., email must be active).
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?
Args section clearly explains the two required parameters (workflow_id and workflow_email_id). However, the optional 'account' parameter is not mentioned in the description, and schema coverage is 0%, so the description should cover all parameters but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it pauses a specific email in a classic automation workflow, distinguishing it from pausing the entire workflow via the sibling pause_automation. Verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it pauses a single email without pausing the entire workflow, providing context for when to use this over pause_automation. However, it does not mention prerequisites (e.g., workflow must be active) or explicit alternatives beyond pause_automation.
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?
Adds error behavior (404, error object on rejection) but lacks idempotency, permission, or side effect details. Annotations only provide readOnlyHint, destructiveHint, idempotentHint (all false), leaving description to carry more burden.
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?
Concise with clear sections: purpose, usage guidance, error note, args, returns. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, error handling, and two of three parameters. Missing explanation of optional 'account' parameter, but overall sufficient for a simple update tool with existing output schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains batch_webhook_id (source from list) and url (new callback URL), but omits the optional 'account' parameter. With 0% schema coverage, the description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates the target URL of an existing batch webhook, uses a specific verb ('Update'), and distinguishes from sibling tools (list_batch_webhooks, delete_batch_webhook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (point webhook at new URL), directs to list_batch_webhooks to find IDs, and suggests delete_batch_webhook as an alternative for removal.
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?
Annotations are all false, so the description carries burden. It states 'replacing the previous message,' which adds context about mutation. However, it does not disclose additional behavioral traits beyond what annotations imply, such as idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. It includes a short Args/Returns section with no fluff. Minor redundancy in repeating feedback_id explanation but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete: it states the purpose, usage, parameter meanings, and return fields. The existence of an output schema covers return value documentation, so no 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?
With 0% schema description coverage, the description explains each required parameter's meaning and how to obtain values (e.g., campaign_id from list_campaigns, feedback_id from list_campaign_feedback, message as new text). It misses the optional 'account' parameter but covers the key parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'campaign feedback comment,' distinguishing it from sibling tools like create_campaign_feedback, delete_campaign_feedback, and list_campaign_feedback.
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 explains when to use this tool (edit a previously left comment) and how to discover necessary IDs via list_campaign_feedback. It lacks explicit 'when not to use' but provides clear context.
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?
Annotations indicate a mutation (readOnlyHint false) with no destructive behavior, and the description adds that renaming does not affect assigned campaigns, providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loads the main action, and includes structured Args/Returns section without unnecessary words.
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 presence of an output schema and a simple update operation, the description covers key behaviors (rename only, no campaign impact) and references the listing sibling, though omits the account parameter.
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 explains folder_id and name parameters meaningfully, but fails to mention the optional 'account' parameter, which is present in the schema with no description (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename an existing campaign folder' and notes that campaigns assigned are unaffected, distinguishing it from create/delete/get/list operations among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use (rename a folder) and advises using list_campaign_folders to discover folder IDs, but does not explicitly mention when not to use or alternative update 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?
Annotations indicate readOnlyHint=false, so write behavior is expected. The description adds transparency by detailing the creation process (generates a script that must be installed), post-creation verification, and the return value structure (id, domain, site_script, etc.). No behavioral contradictions.
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 with a clear purpose statement, usage guidance, parameter list, and return description. Every sentence provides value; no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema), the description covers the full workflow: pre-check, creation, installation, and verification. It references sibling tools appropriately and explains the return object sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains 'foreign_id' and 'domain' with examples. However, the optional 'account' parameter is not described, leaving a gap. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: connecting a website to Mailchimp and generating a tracking script. It distinguishes from sibling tools like 'create_audience' or 'create_campaign' by specifying its focus on site tracking and pop-up forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (enable site tracking/pop-up forms) and recommends checking existing sites with 'list_connected_sites' first, followed by verification with 'verify_connected_site_script'. It lacks explicit exclusions but offers clear context for correct usage.
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?
Annotations already indicate destructive and idempotent hints. Description adds specific consequences (tracking stops) and return format. No contradiction.
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?
Very concise with clear structure: action, warning, usage, args, returns. Front-loaded with purpose. No wasted words.
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?
With annotations and output schema present, description adequately covers irreversibility, consequences, and return value. Only missing explanation for account parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only explains connected_site_id parameter. The account parameter is not mentioned despite being present in schema with no description. Schema coverage 0% requires compensation, but only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a connected site from the account permanently.' Identifies verb and resource. Distinguishes from siblings by referencing list_connected_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes irreversibility, consequences for tracking and forms, and advises using list_connected_sites first. Provides clear context for when to use.
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?
Annotations already set destructiveHint=true and idempotentHint=true, and the description adds valuable context: what exactly is deleted (link to store purchase data) and what is not (connected audience), plus the permanence. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences) with a clear structure: purpose, caveats, parameter list, return format. No fluff, each sentence serves a purpose.
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 delete tool with low complexity, the description covers key points: action, scope, return format. However, it lacks details on optional parameter (account) and error conditions. Output schema exists but is not fully described. Adequate but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only briefly explains the required parameters (store_id, customer_id) and omits the optional 'account' parameter entirely. Minimal guidance beyond names, lacking format, source, or validation hints.
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 'permanently delete a customer from a store' and distinguishes from siblings like delete_member (audience) and delete_store. It also clarifies what it does not affect (connected audience), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (to remove a customer from store data) and notes it cannot be undone, but does not explicitly exclude use cases or mention prerequisites like permissions. The distinction from sibling tools is implied, making it fairly clear.
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?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context: 'Irreversible' and error case 'Returns 404 error if webhook_id or list_id is invalid.' This adds value beyond annotations, though idempotency is not directly discussed.
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?
Description is concise with a clear structure: main action, usage note, error case, then args and returns. It avoids unnecessary words, though the args section somewhat duplicates schema.
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 output schema exists, return value details are covered. Description covers purpose, usage guidelines, behavior, and param explanations (except account). It is quite complete for a delete operation, but missing account param discussion prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains list_id (format and source) and webhook_id (source). However, the optional 'account' parameter is mentioned in schema but not explained in description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a webhook, immediately stopping event notifications to its URL.' This is a specific verb and resource, and it distinguishes from siblings by noting that it's not for pausing and that a new webhook can be created afterward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Do not use when you want to temporarily pause notifications' and suggests 'Use create_webhook to set up a replacement afterward.' This provides clear when-to-use and when-not-to-use guidance with alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds useful behavioral info: 'Returns 404 error if list_id is invalid.' No contradictions. Could mention idempotency, but not required for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: purpose, usage, error, args, returns. Concise yet comprehensive. A few extra lines about return fields could be trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, the description provides ample context: purpose, usage, error handling, parameter details for one param, and return structure. Lacks coverage for 'account' parameter, but otherwise 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 coverage is 0%, so description must compensate. It fully explains list_id (format, example, source) but completely omits the optional 'account' parameter. Documentation is partial, missing meaning for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve full stats, subscribe URL, and rating for a specific audience.' It identifies a specific verb ('retrieve') and resource ('specific audience'), and explicitly distinguishes from sibling 'list_audiences' which browses all audiences.
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?
Explicit usage guidance: 'Use when you have a list_id and need detailed metrics... Use list_audiences to browse all audiences and discover list_ids instead.' It also provides a prerequisite (list_id from list_audiences).
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?
Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds value by disclosing the return structure (JSON with id, url, enabled) and behavior on invalid ID (returns error). This is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the main purpose. It uses bullet-like sections (Args, Returns) to organize information efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, the description covers most necessary context: purpose, usage, required parameter sourcing, return format, and error behavior. The only gap is the undocumented 'account' parameter, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains 'batch_webhook_id' (obtain from list_batch_webhooks) but omits explanation of the 'account' parameter, which is optional. The missing parameter leaves the agent without guidance on its purpose.
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 'Retrieve' and the resource 'details of a single batch webhook.' It specifies what the tool does (inspect target URL and enabled state) and distinguishes it from the sibling tool 'list_batch_webhooks' which browses all webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (inspect a specific webhook) and when to use the alternative 'list_batch_webhooks' (browse all and discover IDs). It also states how to obtain the required ID.
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?
Annotations already indicate readOnlyHint=true, so the tool is known to be safe. The description adds that it returns the full record with tracking script, but does not exceed the annotation's safety profile significantly. It provides context about the return fields but not additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a one-sentence summary, followed by usage guidelines, parameter details, and return format. Every sentence serves a purpose without redundancy.
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 input schema has two parameters (one required) and an output schema exists, the description sufficiently explains the required parameter and the expected return structure (JSON with specific fields). It is complete for a read tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It describes the required connected_site_id parameter well, including how to obtain it from list_connected_sites. However, it ignores the optional account parameter, leaving its purpose unclear. This partial coverage adds some value but is not fully 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 clearly states the tool retrieves a full record for a single connected site, including its tracking script. It distinguishes from sibling tools like list_connected_sites and explicitly mentions usage when a connected site ID is known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: when you have a connected site ID and need its script snippet or installation status. It also provides clear guidance to use list_connected_sites for browsing instead, offering an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only. Description adds valuable context: scanning behavior based on count parameter, side-channel mechanism for journey emails, and returned structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, note, args, returns). Front-loaded. The note is slightly lengthy but provides necessary context. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description doesn't need to detail returns, but it does so helpfully. It covers parameters (except account), behavior, and results. For a read tool with good annotations, it is sufficiently 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 coverage is 0%, so description must compensate. Description explains list_id, email_address, and count well. However, the 'account' parameter (present in schema) is not mentioned in Args, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves activity events filtered to automation/journey-related actions. This distinguishes it from siblings like get_member_activity and get_member_events. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to answer what automation/journey emails a contact received without scanning full activity. Notes limitation about Mailchimp's API and suggests trigger_customer_journey as an alternative for enrollment.
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?
Annotations already indicate readOnlyHint=true (safe read). Description adds that invalid IDs return 404 and lists returned fields. No contradictions.
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?
Description is concise with about 6 sentences, front-loading purpose and usage. No unnecessary words. Could be slightly more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, description covers purpose, parameter semantics, error handling, and return fields. Missing documentation of the optional account parameter, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain params. It describes store_id, promo_rule_id, promo_code_id with short but clear explanations. However, the optional 'account' parameter is not mentioned, and explanations are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve a single promo code by ID' with specific verb and resource. Mentions returning settings and usage stats, and distinguishes from list_promo_codes for browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use cases: check usage_count before campaign or confirm enabled. Also tells when to use sibling list_promo_codes instead, and notes 404 error conditions.
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?
Annotations already indicate readOnlyHint=true, so the description adds moderate value by describing the return format. It does not discuss side effects or limitations beyond what annotations cover, but there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. First line states purpose, then usage context, then args, then return. Every sentence earns its place.
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 presence of output schema and annotations, the description covers purpose, required parameters, return format, and integration context. No gaps are apparent.
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 carries the burden. It clearly explains the meaning and source of the three required parameters (store_id, order_id, line_id). The optional account parameter is not documented, but it is less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a single line item'), the resource ('e-commerce order'), and specifies the use case ('inspect one product entry's quantity, price, and discount'). It distinguishes this tool from siblings like list_store_order_lines (which lists) and create_store_order_line (which creates).
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 context on when to use the tool (manual commerce writes vs automated sync) and guides the user on obtaining required IDs from relevant list functions. It does not explicitly state when not to use, but the context is sufficient.
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?
Annotations already indicate readOnlyHint=true, and the description adds valuable behavioral context: only works for user-created templates, gallery templates may return limited content, and 404 error on invalid ID. No contradictions.
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?
Description is well-structured with sections, but slightly verbose: first two sentences repeat the main action. However, it is front-loaded with the core purpose and provides necessary details without excessive fluff.
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?
Despite having an output schema, the description explains output keys (html, sections). However, it misses the account parameter entirely, which is a gap for a tool with only two parameters. The overall context for a read-only tool is decent but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must cover all parameters. It describes template_id (required, numeric, origin) but completely omits the account parameter (optional, with default null), leaving ambiguity about its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves default HTML content of a template, specifies the verb 'Retrieve' and resource 'template default content', and distinguishes from siblings like set_campaign_content and list_templates.
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 when-to-use guidance (before customizing campaign content), what templates work (user-created), how to find template IDs via list_templates, and error handling (404 for invalid ID).
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?
Annotations readOnlyHint already indicate safety. Description adds pagination behavior, return structure, and the fact that full audience settings are returned, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, usage, Args, Returns. The Returns section is verbose but informative. Front-loaded with key 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?
Covers purpose, usage, parameters (mostly), and return format. Minor gap with the undocumented account parameter. Overall comprehensive for a read-only list 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?
Explains count and offset well with ranges and usage, but omits the account parameter entirely. Schema coverage was 0%, so description compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists audiences with subscriber counts and engagement rates. Explicitly distinguishes from get_audience_details and search_members, providing 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes it as the first step in most workflows to discover list_id values, and gives explicit when-to-use cues for alternatives like get_audience_details and search_members.
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?
Annotations declare readOnlyHint=true and destructiveHint=false; description adds pagination details, default count, and return format, which are useful beyond annotations. No contradictions.
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, context, args, returns). Front-loaded and concise without extraneous text.
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?
Fully covers parameter usage, pagination, and return structure. Output schema exists, so return explanation is sufficient. No gaps given the tool's 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?
With 0% schema coverage, description adds meaning for store_id (source), count (range/default), and offset but omits explanation for the 'account' parameter, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists promo rules for a store with specific examples of discount types (fixed amount, percentage, free shipping), distinguishing it from related tools like create_promo_rule or get_promo_rule.
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?
Provides context that codes are attached to rules via list_promo_codes/create_promo_code, implying when to use this tool. Lacks explicit when-not or alternatives but is clear enough for an agent to decide.
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?
Annotations (readOnlyHint=true, etc.) are consistent. Description adds return structure and fields, exceeding annotations. No behavioral surprises.
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?
Well-structured with intro, note, args, returns. Front-loaded main purpose. Slightly verbose but clear and earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return structure. Missing explanation for 'account' parameter, but output schema exists to clarify returns. Adequate 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?
With 0% schema coverage, description explains store_id, count, offset well, including source for store_id and pagination. However, 'account' parameter is not addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (list), resource (orders from store), and outputs (totals, fulfillment status). Distinguishes from sibling 'list_store_customers' via explicit note.
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?
Mentions prerequisite of active integration and suggests an alternative (list_store_customers) for different granularity. Lacks explicit when-not-to-use but provides good context.
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?
Annotations indicate mutation but not destructive. Description adds that pause is temporary and reversible, stops scheduled editions, and returns confirmation or error. Provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, includes structured Args and Returns sections. Slightly wordy but no irrelevant content. 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?
Covers purpose, usage, parameter, return value, and error case. References complementary tool. Could mention handling of already paused campaigns, but overall sufficient for 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 coverage 0% but description explains campaign_id parameter with source (list_campaigns or search_campaigns). However, the optional 'account' parameter is not mentioned in the Args section, leaving it unexplained. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool pauses an active RSS-driven campaign to stop scheduled editions. Distinguishes from siblings by specifying RSS-driven, and complements resume_rss_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (temporarily halt RSS campaign), when not (only for RSS type), and how to confirm with get_campaign_details. Also references resume_rss_campaign for later 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?
Annotations indicate write operation; description adds partial update behavior. No mention of side effects, authorization, or idempotency details beyond annotations.
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?
Concise, well-structured with brief opening, behavior explanation, Args list, and Returns. Front-loaded with purpose. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters, behavior, return value, and store type context. Missing error handling or validation details, but output schema exists.
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 has 0% description coverage; description explains all parameters, especially additional_fields with examples and merge semantics. Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update a line item on an existing e-commerce order.' Distinguishes from create/delete/get line item tools. Mentions store type context (custom/headless vs integrated).
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?
Provides partial update behavior ('Only the fields you pass... are changed'). Implies use for manual stores, but no explicit when-not-to-use or alternative comparisons.
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?
Annotations indicate a mutation (readOnlyHint=false, destructiveHint=false). The description adds that only fields in additional_fields are changed (partial update), which is important behavioral context beyond annotations. No contradictions.
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 structured with paragraphs and includes an args/returns section. It is front-loaded with purpose but could be slightly more concise. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description explains the update behavior, partial update, and return format. It covers most aspects but omits the 'account' parameter.
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 lists the required parameters (store_id, product_id, variant_id) and explains additional_fields with examples. However, the 'account' parameter in the schema is not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing product variant's attributes like price, SKU, inventory, with a specific verb and resource. It distinguishes from siblings like create/delete/get variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that only supplied fields are changed and warns about automatic syncing from Shopify/WooCommerce, providing context for when manual updates are appropriate. However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description correctly implies a non-idempotent mutating operation. The description adds context about the step-by-step process (email, code submission) and the post-verification behavior (domain can authenticate). This provides useful behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a usage guideline, then parameter explanations labeled 'Args', and a 'Returns' section listing output fields. Every sentence adds value without redundancy.
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 an output schema exists (context signals indicate true), the description lists all return fields (domain, verified, authenticated, verification_status, authentication_status). It covers prerequisites, inputs, and expected outputs completely. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for two required parameters: domain_name (e.g., 'mail.example.com' and source list_verified_domains) and code (emailed code from create_verified_domain). However, the optional 'account' parameter is not mentioned, leaving a gap. The description compensates partially but not fully for the missing schema descriptions.
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: 'Complete domain verification by submitting the code emailed to the verification address.' It specifies the verb 'verify' and resource 'domain', and distinguishes it from create_verified_domain (which triggers the email) and list_verified_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to run create_verified_domain first, then pass the received code here. It also explains the outcome: 'Once verified, the domain can authenticate and be used as a sending address.' While it doesn't state when not to use it, the context is clear and provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true. The description adds context on why (arbitrary DELETEs) and explains asynchronous behavior, which extends beyond the annotation.
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?
Well-structured with front-loaded purpose, usage, and parameter detail. Slightly verbose but each section adds value; could tighten the destructive explanation.
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?
Covers purpose, usage, async behavior, destructive classification, parameter details, and return value. Output schema exists, so no need to detail return structure further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 params with 0% coverage. Description explains operations as JSON array with method, path, and optional body but fails to mention the account parameter, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it submits multiple API operations as a single asynchronous batch request, distinguishing it from sibling tools like batch_subscribe by mentioning limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (bulk operations exceeding limits) and mentions alternatives (batch_subscribe). Covers async nature and polling with get_batch_status.
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?
Annotations are all false, so description carries full burden. It discloses that the option becomes available on signup forms (unless category type is 'hidden'), requires unique name, and returns subscriber_count starting at 0. This adds meaningful behavioral context beyond the annotations.
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, usage, args, returns, example). Front-loaded with a concise first sentence. Every part adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, return format, example, and relationships to other tools. The optional 'account' parameter is not addressed, and error behavior is not described. Output schema existence is noted, reducing the need for return detail. Overall complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains list_id, category_id, and name with sources and constraints (e.g., name must be unique). However, it omits the optional 'account' parameter present in the schema, leaving it undocumented.
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: 'Create a new interest option within an interest category'. It provides an example and distinguishes from sibling tools like create_interest_category by explaining it adds options to an existing category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use after create_interest_category'. Provides alternatives: 'Use list_interests to check existing options' and 'Use delete_interest to remove'. Also specifies prerequisites for parameters (e.g., obtaining list_id from list_audiences).
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?
Annotations are all false, so the description carries the burden. It discloses that promo_rule_id is client-supplied and describes the return object. However, it does not discuss idempotency or error behavior on duplicate IDs, which would be useful 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 concise and well-structured: a brief purpose statement, follow-up on related tools, pattern examples, a clean list of parameters with short explanations, and a return object description. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 6 required) and zero schema description, the description covers all necessary details: parameter semantics, common use patterns, and return format. The presence of an output schema supports completeness further.
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 adds significant meaning by explaining each parameter with examples and valid ranges (e.g., amount for percentage, target options). This goes beyond the raw schema and provides actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a promo rule (discount mechanic) and distinguishes it from the create_promo_code sibling by noting that codes are attached afterwards. This provides a specific verb+resource and differentiates 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use (creating a promo rule first, then attaching codes via create_promo_code) and provides common pattern examples. It does not explicitly state when not to use it, but the guidance is sufficient for an agent.
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?
Discloses that it sends a verification code to the email, domain derivation, and further steps. Annotations are minimal, so description carries the burden well. Could mention idempotency or error conditions, but overall good 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?
Concise and well-structured: first sentence states purpose, followed by step details, then parameter and return sections. No unnecessary words.
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?
Explains the verification flow and references sibling tools. Missing details about the account parameter and potential error cases, but otherwise complete for a multi-step process.
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?
Adds meaning for the required verification_email with an example and its role. However, the optional account parameter is not described at all. With 0% schema coverage, description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it begins domain verification by sending a verification code. It distinguishes from siblings like list_verified_domains and verify_verified_domain, making the tool's role in the workflow explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises checking existing domains with list_verified_domains before starting, and to use verify_verified_domain after receiving the code. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent. The description adds context about permanence, irreversibility, and loss of redemption history, which are valuable beyond annotations.
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 front-loaded purpose, consequences, alternatives, error condition, then args and returns. Every sentence is useful and concise.
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 output schema exists, the description's return details are extra. It covers purpose, side effects, alternatives, errors, and parameter descriptions. Missing 'account' parameter is a minor gap.
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 lists three parameters (store_id, promo_rule_id, promo_code_id) with brief explanations, but omits the 'account' parameter from the schema, leaving 25% undocumented. The explanations are minimal but add basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it permanently deletes a promo code and distinguishes it from update_promo_code (disabling) and delete_promo_rule (removing rule and all codes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs alternatives: using update_promo_code to disable and preserve stats, or delete_promo_rule to remove rule and all codes. Also notes 404 error for invalid IDs.
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?
Annotations already indicate destructive and idempotent behavior. The description adds that deletion is irreversible, members remain in the audience, and returns a 404 error if the segment does not exist. This goes beyond annotations by clarifying non-destructive impact on members and error cases.
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: first sentence states purpose, then behavioral notes, alternative tool references, error case, followed by parameter documentation and return type. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sibling delete tools and the presence of an output schema, the description covers purpose, behavior, error handling, parameter details, and return format. The only minor gap is the undocumented 'account' parameter, but it is optional and likely not needed for typical 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?
Input schema has 3 parameters (account, list_id, segment_id) with 0% schema description coverage. The description documents list_id and segment_id with examples and origin instructions, but completely omits the optional 'account' parameter. This adds value for the two required parameters but leaves a gap.
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 starts with a clear verb-resource pairing: 'Delete a segment or tag from an audience.' It distinguishes from sibling tools like update_segment (rename/modify) and list_segments (find IDs), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (delete) and when to use update_segment instead (to rename or modify conditions). Also advises using list_segments to find segment IDs, providing clear navigation among alternatives.
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?
The description discloses critical behavioral traits beyond annotations: the destructive cascade (removing products, variants, customers, carts, orders) and irreversibility. This adds significant value as annotations only provide destructiveHint and idempotentHint, which are consistent and not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences plus Args/Returns), front-loaded with the essential action and warnings, and structured with clear sections. No superfluous 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 and existing output schema, the description covers the key points: deletion scope, irreversibility, return format. Could mention that the store must exist beforehand, but overall sufficient.
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 explains the required parameter (store_id) meaningfully. However, with 0% schema coverage, the optional parameter (account) is not described at all. The description partially compensates for low schema coverage but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete an e-commerce store'), identifies the specific resource (store), and distinguishes it from sibling delete tools (e.g., delete_store_cart) by emphasizing the cascade effect.
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 by warning that the operation is destructive and cannot be undone, advising careful verification of store_id. However, it does not explicitly state when to use this tool versus alternatives (e.g., deleting sub-entities separately), missing explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so the tool is read-only. The description adds behavioral context about polling and the need to wait for status 'finished' to obtain the download URL. This extra detail goes beyond annotations. However, it does not mention idempotency or rate limits, which are minor omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating purpose, followed by usage instructions, and a structured Args and Returns section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the use case, how to obtain the export_id, and what the return looks like (JSON fields). It also mentions the output schema implicitly. The only gap is the missing explanation of the 'account' parameter, which slightly reduces 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 explains the required export_id parameter and how to obtain it, but fails to mention the optional 'account' parameter. Since schema description coverage is 0%, the description should cover both parameters. This omission leaves the agent without guidance on the account parameter, reducing semantic 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 tool retrieves status and download URL for a single account export job, using a specific verb and resource. It distinguishes itself from sibling tool list_account_exports by explicitly stating that list_account_exports is for browsing and discovering IDs, thus preventing confusion.
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 instructions: 'Use to poll an export until its status is finished and then read its download_url. Use list_account_exports to browse all exports and discover IDs instead.' This clearly tells when to use this tool and when to use the sibling, offering strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds context about ordering (newest first) and return structure (JSON with list_id and history array of months with aggregate ints), which enhances transparency beyond annotations.
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?
Efficiently structured with a brief intro and clear Args/Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter details for most parameters, and return structure. Missing mention of the 'account' parameter, but overall sufficient for a read-only historical data tool with existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains list_id and count with examples, ranges, and defaults, but does not mention the optional 'account' parameter. Adds meaningful detail for 2 of 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve monthly growth history for an audience' with specific metrics (subscribes, unsubscribes, cleaned). Distinguishes from sibling get_audience_details by noting it provides historical trends not current totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use get_audience_details instead for current totals, providing clear when-to-use and when-not-to-use guidance. Also specifies the ordering (newest first) and parameter details.
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?
Annotations already indicate readOnlyHint=true, so safety is clear. Description adds return structure (id, name, description, users), which is helpful context beyond annotations. No mention of rate limits or auth, but sufficient for a read-only 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?
Well-structured with clear title, usage guidance, args, and returns sections. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with output schema, description covers return fields and main parameter. Could mention possible errors or limitations, but not required. Slight gap on 'account' parameter purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 params (app_id required, account optional) with 0% schema description coverage. Description only explains app_id ('the authorized app ID to inspect. Obtain from list_authorized_apps') but does not explain the 'account' parameter, leaving its purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the full record for a single OAuth-authorized application, specifying verb 'retrieve' and resource 'authorized app'. Distinguishes from sibling 'list_authorized_apps' by noting it's for a single app when ID is known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you have an app ID and need its name, description, or the users that authorized it' and suggests using list_authorized_apps to browse and discover IDs, providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by stating 'Returns all emails regardless of status' and detailing the return structure. Given that annotations already declare readOnlyHint=true, the additional information about what data is returned is appropriate and helpful.
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 with a clear purpose sentence, usage notes, and an Args/Returns section. It is concise, using only a few sentences to convey all necessary information without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema that explains return values, and annotations covering safety, the description adequately covers purpose, usage, and parameter details. It is complete for a read-only list operation, though it could optionally mention error conditions or pagination.
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?
Although the schema description coverage is 0%, the description provides valuable semantics for the required automation_id parameter, including an example and source (list_automations). The optional account parameter is not mentioned, but its purpose is common and likely inferred from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'individual emails within an automation workflow', and includes specific details like sequence, delays, and send counts. It also distinguishes itself from sibling tools like get_email_activity and get_automation_email_queue, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to confuse this tool with get_email_activity and advises using get_automation_email_queue for queued subscribers. This provides clear context for when to use each tool, though it does not cover all possible alternatives or edge cases.
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?
Annotations already declare readOnlyHint=true, so the description need not repeat safety. It adds context about the specific data returned (abuse reports), which is beyond the annotation. No contradictions, and it does not conceal any behavioral traits.
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 front-loaded with the main action, followed by usage guidance, parameter details, and return format. It is slightly lengthy but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description covers the return format (JSON with total_items and abuse_reports) and fields, providing sufficient context for effective usage. The output schema further reduces the burden.
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?
Given 0% schema description coverage, the description adds moderate value: it explains 'campaign_id' (where to obtain it) but does not mention the 'account' parameter. Thus, it partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists abuse complaints for a sent campaign, uses a specific verb ('List') and resource ('abuse reports'), and distinguishes from siblings 'get_campaign_abuse_report' and 'get_campaign_report'.
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?
Provides explicit guidance on when to use this tool (to monitor deliverability health) and alternatives ('get_campaign_abuse_report' for single complaint, 'get_campaign_report' for overall stats), making it clear when to select this over similar tools.
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?
Annotations already indicate readOnlyHint=true. The description adds that it returns JSON with id, name, and count, which is consistent with read-only behavior. No contradictions; it effectively complements the annotations.
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: three sentences plus args/returns. It front-loads the purpose and provides essential information without any fluff. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool, the description covers the main behavior and return structure. However, the omission of the account parameter means incomplete guidance. Given the output schema exists, the return details are adequate, but the param gap reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It explains folder_id well (ID, source from list_campaign_folders) but completely ignores the optional 'account' parameter. Users are left uninformed about its purpose, a significant gap.
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 tool name and description clearly state it retrieves details for a single campaign folder. It distinguishes itself from sibling tools like list_campaign_folders by specifying a single folder, and mentions confirming name and campaign count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use it ('to confirm a folder's name and how many campaigns it contains before organizing campaigns') and directs to list_campaign_folders for discovering folder IDs. This provides clear context and alternatives.
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?
Annotations already set readOnlyHint=true. Description adds that the tool returns is_ready boolean and an items array with type, id, heading, details, which is beyond annotations. No contradictions.
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?
Description is concise (~80 words), well-structured with Args/Returns sections, no fluff, and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, return structure, and references siblings. However, missing explanation for the 'account' parameter, and no mention of potential errors or caching, though read-only tool reduces need. Slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains campaign_id (source from list_campaigns/search_campaigns) but ignores the optional 'account' parameter entirely. Schema coverage is 0%, so description should cover both parameters; missing one leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve the pre-send readiness checklist for a campaign', specifying verb and resource. It distinguishes from sibling get_campaign_details by noting that IDs come from that tool, and from send_campaign by positioning as a pre-check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use before sending, resolve 'error' items before calling send_campaign, and get IDs from get_campaign_details. Provides clear when-to-use and alternatives.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying that the tool returns a JSON with total_items and chimp_chatter array, and describes the structure of each entry. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with every sentence adding value. It front-loads the purpose, provides usage guidance, lists args, and describes return format. No unnecessary words.
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 simplicity, the description covers purpose, usage, parameters (mostly), and return format. The presence of an output schema in the description further aids completeness. However, the 'account' parameter is left unexplained.
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 0% description coverage. The description explains count (range 1-1000, default 10) and offset (pagination usage), but does not explain the 'account' parameter. This partially compensates for the missing schema descriptions.
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 states 'Retrieve the account activity feed (Chimp Chatter) of recent events across the account.' It uses a specific verb ('Retrieve') and resource ('account activity feed'), and distinguishes from sibling tool get_campaign_report by explicitly stating its use for metrics on a single campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use to review a chronological stream of account-wide activity'. It also provides a clear alternative: 'Use get_campaign_report for metrics on a single campaign instead.' This helps the agent decide between 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?
Annotations already indicate read-only and non-destructive behavior. The description adds useful context: it only works for sent campaigns and details the return format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage, args, returns, and example. It is not overly verbose, but could be slightly more concise by removing redundant phrasing.
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 presence of an output schema, the description provides a complete picture: purpose, usage, parameter details, return structure, and an example. All necessary context is present.
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 meaning for the required parameter 'campaign_id' with format and constraint ('Must be a sent campaign'). However, the optional 'account' parameter is not described, and schema coverage is 0%. The description compensates partially but not fully.
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: 'Retrieve campaign performance broken down by recipient email domain'. It specifies the verb, resource, and scope, and distinguishes from the sibling tool 'get_campaign_report' which provides overall aggregate metrics.
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?
Explicit usage guidance is provided: 'Use to identify deliverability issues with specific providers or compare engagement across domains. Use get_campaign_report for overall aggregate metrics. Only works for sent campaigns.' This clearly informs when to use this tool and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=false. The description adds behavioral details: reliance on e-commerce integration (returns empty result if not connected) and 404 error for invalid campaign_id. This provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (prerequisites, Args, Returns) and uses concise language. It avoids unnecessary words but could be slightly tighter; the Args list could be more compact. Still efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, having an output schema (described in Returns) and a straightforward purpose, the description covers all needed context: prerequisites, error handling, pagination, and output format. It is complete for an agent to decide to use it.
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 description must compensate. The Args section provides meaningful details for campaign_id (format), count (range 1-1000, default 20), and offset (pagination). The 'account' parameter is not mentioned, but it's optional and default null. Overall, the description adds significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Retrieve e-commerce product activity for a campaign showing revenue per product.' This is a specific verb+resource, and it distinguishes from sibling tools like get_store_product (which handles store product details) and get_campaign_report (broader campaign stats).
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?
Description specifies prerequisites: 'Requires an active e-commerce integration; returns total_items: 0 if none is connected. Use list_ecommerce_stores to verify status. Only works for sent campaigns.' It also mentions error behavior for invalid campaign_id. It provides clear context for when to use, but could be more explicit about when not to use or suggest alternatives like get_campaign_report.
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?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds behavioral context: it retrieves a timeline, includes specific actions, and mentions pagination via offset. No additional traits like rate limits are provided, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose sentence, bullet-point alternatives, parameter list, return value. Every sentence adds value, and it is front-loaded with the most important 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?
For a tool with 4 parameters and an output schema, the description is largely complete. It explains the return structure and most parameters. However, the missing 'account' parameter is a notable gap that could lead to incorrect usage.
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 explains campaign_id, count, and offset with examples and constraints, but it omits the 'account' parameter entirely. This missing parameter reduces completeness.
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: 'Retrieve per-recipient activity timeline for a sent campaign (opens, clicks, bounces).' This is a specific verb and resource, and it distinguishes from siblings by naming them explicitly.
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?
Provides explicit when-to-use guidance by naming alternative tools: 'Use get_open_details for open data only. Use get_campaign_report for aggregate totals. Use get_campaign_recipients for delivery status only.' This helps the agent select the correct tool.
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?
Annotations already mark it as readOnly (safe read). Description adds return content details (lines, customer, totals) and specific fields. No contradictions. Good context beyond annotations.
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?
Concise and front-loaded: first sentence states purpose. Two short paragraphs plus Args/Returns. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return fields, usage context, and parameter sources. Missing mention of optional 'account' parameter. Output schema exists, so return structure detail is not needed. Adequate for 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?
Schema description coverage is 0%. Description compensates by explaining how to obtain store_id and order_id from other tools. The optional 'account' parameter is not mentioned, but required params are well-documented.
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 'Retrieve a single e-commerce order' with a specific verb and resource. It distinguishes from siblings like list_store_orders (listing) and create_store_order (creation) by specifying 'single' and indicating use after listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'to inspect one order's full detail after finding it via list_store_orders or list_account_orders.' Provides context on store types. Lacks explicit 'do not use' but is clear enough.
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?
Annotations already declare readOnlyHint=true, so the description's mention of 'retrieve' and the return format ('JSON with the image object') adds value beyond annotations. No contradictions, and it discloses that the tool inspects one image without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a purpose sentence, a context sentence, an Args section, and a Returns section. No fluff, well-organized, and front-loaded with the main action.
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 4 parameters (3 required) and an output schema, the description covers required parameters, return value, and integration context (manual vs synced). It omits the optional account parameter but is otherwise complete for typical 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?
Despite 0% schema description coverage, the description explains the three required parameters (store_id, product_id, image_id) with clear instructions on how to obtain them. The optional 'account' parameter is not explained, but it is the only gap.
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 specifies the verb 'retrieve' and resource 'a single image attached to a product', clearly distinguishing it from sibling tools like list_store_product_images and get_store_product. It also mentions inspecting URL and variant associations, making the purpose concrete.
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 states when to use the tool (inspect one image's URL and variant associations) and provides context about manual vs synced stores, implying when automated alternatives exist. It does not explicitly list exclusions but references list_store_product_images to obtain image_id, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns JSON with id, name, and template count, which is useful context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the purpose, then usage guidance, followed by parameter and return descriptions. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema (mentioned but not shown), the description covers purpose, usage, key parameter, and return fields. It omits the account parameter but is otherwise 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 coverage is 0%, so the description must compensate. It documents folder_id, explaining its purpose and source (list_template_folders). However, the optional account parameter is left undocumented, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a single template folder, specifying it can confirm the folder's name and template count. This distinguishes it from sibling tools like list_template_folders and create_template_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (to confirm folder details) and directs users to list_template_folders for discovering folder IDs, providing clear guidance on alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false. Description adds value by specifying the exact return fields (verified, authenticated, etc.) and the condition of use. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus concise Args and Returns sections. No redundant information, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, description covers the return fields and use case. Could optionally mention error handling for missing domains, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains domain_name with an example and how to obtain it, but does not mention the optional account parameter. Thus only partially covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the full verification/authentication record for a single sending domain, with specific verb ('Retrieve') and resource ('verified/authentication record'). It distinguishes from sibling list_verified_domains by indicating it is for a single known domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you have a domain name and need its exact verified/authenticated state before sending') and when to use an alternative ('Use list_verified_domains to browse all domains and discover names instead').
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?
Annotations already provide readOnlyHint=true, so the description adds value by describing the return structure (JSON with orders array and total_items) and pagination behavior. However, it does not mention authorization requirements or rate limits, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses bullet points with Args and Returns sections, and front-loads the purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are provided, the description covers the tool's purpose, usage guidance, and most parameters. The missing description of the 'account' parameter is a gap, but overall it is sufficiently complete 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 coverage is 0%, so the description must compensate. It explains count (max 1000, default 10) and offset (default 0) clearly, but fails to describe the 'account' parameter present in the schema. This omission means not all parameters are semantically covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists e-commerce orders across all stores in the account. It uses a specific verb-resource pair and distinguishes itself from the sibling tool list_store_orders by specifying account-wide vs single store scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for account-wide reporting without iterating store by store. Also directs to list_store_orders for single store scope. Mentions manual vs automated integration contexts, providing clear guidance on alternatives.
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?
Annotations already indicate readOnlyHint=true (safe, no destructive actions). Description adds context: pagination via offset, required list_id from list_audiences, and return format. Does not mention rate limits or other constraints, but sufficient 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?
Concise yet complete: single-line purpose, usage context, and structured Args/Returns sections. No wasted words, front-loaded with core action.
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 list tool, covers purpose, parameters (except account), return format, and pagination. With output schema available but not shown, description compensates reasonably. Missing account parameter detail is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 params with 0% description coverage. Description adds meaning for list_id, count, and offset (type, range, default, usage). However, account parameter is not mentioned, leaving its purpose unexplained. Adequate but not fully compensating for missing param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists abuse reports filed against an audience, uses specific verb 'list' and resource 'audience abuse reports'. Distinguishes from sibling get_audience_abuse_report by mentioning it for single report inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for monitoring deliverability health and identifying spam campaigns, and directs to get_audience_abuse_report for detailed inspection of a single report. Provides clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds pagination details, output structure, and status filter, but omits the 'account' parameter, which is present in the schema but not explained.
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?
Description is well-structured with clear headers, lists, and an example. Every sentence adds value, and it is front-loaded with purpose and usage guidelines.
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 (5 parameters, output schema), the description is thorough, covering most parameters and return structure. The omission of the 'account' parameter and slight overlap with schema details prevent a perfect score.
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 description must compensate. It explains list_id, count, offset, and status with examples and constraints. However, it fails to mention the 'account' parameter, leaving a gap for a significant parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List members of a specific audience' and distinguishes from siblings like search_members and list_segment_members, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('browse members of a known audience') and provides alternatives for finding specific members or segment members.
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?
Annotations already declare readOnlyHint=true. Description adds return format details (JSON with total_items and files array) and notes pagination behavior via offset. No contradictions.
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?
Concise and well-structured: purpose line, usage guidance, then Args/Returns sections. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use case, parameters, and return format. However, missing documentation for the 'account' parameter, which leaves a minor gap. Overall adequate given output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description documents 3 of 4 parameters (count, offset, type) with ranges and options, but misses the 'account' parameter. Provides meaningful info beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists images and files from the File Manager, used to discover file_id and hosted URLs for embedding. It distinguishes itself from get_file, upload_file, and list_file_folders, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to discover file_id and URLs for embedding. Also mentions alternatives: get_file for full metadata, upload_file to add, list_file_folders for folder structure.
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?
Annotations already declare readOnlyHint=true, so no safety concerns. The description adds that landing pages are standalone web pages, not emails, and describes the return format. This adds behavioral context beyond annotations.
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 with a header, explanation, Args section with parameter details, and a Returns section outlining the output. It is concise and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the return structure and key fields. It is complete for the tool's purpose, with no missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters: count, offset, account. Description explains count and offset but omits the 'account' parameter. With 0% schema description coverage, the description needed to cover all parameters but does not, leaving the 'account' parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists landing pages with specific fields, and distinguishes itself from get_landing_page (for full details) and list_campaigns (for email campaigns), providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (list landing pages) and when not to (do not use for email campaigns, use list_campaigns instead), along with an alternative for full details (get_landing_page).
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?
Annotations declare readOnlyHint=true, no contradiction. Description adds context: operation is read-only, lists defaults always present, explains pagination behavior. No hidden destructive actions disclosed, but sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections, Args list, Returns, Example. Somewhat lengthy but every sentence adds value. Could be slightly more concise but still efficient.
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 4 parameters, output schema exists, description is comprehensive: covers purpose, usage, all params (except account), return format, example. No missing context for effective tool selection and 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 coverage is 0%, so description compensates: explains list_id source, count range/default, offset pagination. However, misses the 'account' parameter entirely, leaving a gap. Other parameters well described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists merge fields for an audience (specific verb+resource). It distinguishes from sibling tools like create_merge_field by explaining its role in discovery before member updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to discover merge fields before adding/updating members. Mentions default fields always present and directs to create_merge_field for custom fields. Also explains usage of merge tags in content and other 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?
Annotations already confirm read-only and non-destructive behavior. The description adds behavioral context: it returns JSON with image array and total_items, and explains pagination via count and offset defaults. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose stated first, followed by usage guidance, then parameter explanations. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, presence of output schema (implied by return description), and sufficient annotations, the description covers purpose, parameters, usage context, and return format completely. No gaps remain for effective use.
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 explaining each parameter's purpose, including how to obtain store_id and product_id from other tools, and specifying count limit and defaults. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists images attached to a product, using specific verb+resource. It provides context for use before adding/updating images. However, it does not explicitly differentiate from sibling tool get_store_product_image, which retrieves a single image; the distinction is implied but not stated.
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 advises using this tool to review images before add/update operations and notes that Shopify/WooCommerce integrations handle syncing automatically, guiding when to use manual listing. It lacks explicit when-not-to-use guidance but provides sufficient context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds value by describing return format (JSON with total_items, templates array) and fields (id, name, type, date_created, active). It also mentions it lists both user-created and gallery templates.
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?
Concise and well-structured: purpose, usage guidelines, parameter specs, return description. All sentences add value. Front-loaded with key purpose.
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 it's a list tool with read-only annotations and an output schema (mentioned), the description explains the return structure well. However, it fails to mention the 'account' parameter and doesn't specify default sorting or ordering. Still, it is largely 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 coverage is 0%, so description must compensate. It describes count (1-1000, default 20) and offset (pagination). However, it omits the 'account' parameter entirely. With 3 parameters, 2 are explained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists email templates (user-created and Mailchimp gallery). It distinguishes from sibling tools like get_template (single), get_template_default_content (extract HTML), create_template (add templates), and list_campaigns (for campaigns). Verb 'list' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (browse templates, find IDs), when not (for campaigns), and points to alternatives: get_template_default_content and create_template. This is full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. The description adds value by detailing the return structure (total_items, webhooks array with fields) and explicitly stating what the tool does not do (delivery logs). No contradictions. Slight deduction for not mentioning potential rate limiting or authentication requirements, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose sentence, usage guidelines, then a clear Args and Returns section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, with annotations and output schema covering much. The description adds usage guidance and partial parameter semantics. Missing account parameter description is a small gap, but overall the tool is well-documented for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides detailed semantics for list_id (format, example, source) but completely omits the optional account parameter. This partial coverage earns a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists webhooks for an audience, showing callback URLs, events, and source filters. It distinguishes itself from sibling tools like delete_webhook by specifying its use for auditing and finding IDs before deletion, and explicitly contrasts with checking delivery history.
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 (audit integrations, find webhook IDs before deletion) and when not to use (checking delivery history, with reason that Mailchimp doesn't expose logs). It also directs the user to list_audiences for obtaining the list_id.
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?
Annotations are minimal, but description adds behavioral details: required campaign state, rounding to nearest quarter hour, and error conditions beyond what annotations provide.
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?
Well-structured with args and returns sections, plus an example. Clear and efficient, though slightly long due to example; still earns its sentences.
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 sibling context and output schema presence, the description covers prerequisites, parameter details, return format, and example, making it fully adequate for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so description carries the burden. It explains campaign_id and schedule_time in detail, but omits the optional 'account' parameter, leaving it undocumented.
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 schedules a campaign draft for future sending, and distinguishes it from siblings like send_campaign and unschedule_campaign, making the purpose specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for scheduled delivery), prerequisites (content set, 'save' status), and alternatives (send_campaign for immediate, unschedule_campaign to cancel, send_test_email to preview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations, such as campaign status requirement, overwriting behavior, size limit, and merge tag support. However, there is a contradiction: the description says it overwrites content (destructive), but annotations have destructiveHint=false. This inconsistency reduces reliability.
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 with separate sections for purpose, workflow, args, returns, and example. It is concise, front-loaded with the main purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema coverage is 0% and there is an output schema, the description covers most necessary information: purpose, parameters (2 of 3), return format, and usage context. The only gap is the lack of explanation for the account parameter, but it is optional.
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 compensates by explaining campaign_id and html parameters in detail, including format, constraints, and examples. The optional account parameter is not described, but it's minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set the full HTML body of a campaign draft, replacing any existing content entirely.' It uses a specific verb and resource, and distinguishes from sibling tools like update_campaign (for settings) and create_campaign (for creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a workflow (create_campaign -> set_campaign_content -> send_test_email -> send_campaign) and contrasts with update_campaign for settings, giving clear guidance on when to use this tool vs alternatives.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, matching the description's write operation. Returns status 'unpublished' or error. Does not mention idempotency consequences, but annotations already hint at non-idempotent.
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?
Concise with clear Args/Returns sections. First sentence states purpose directly. No 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?
Describes return value well. But missing explanation of the 'account' parameter limits completeness. Has output schema documented, reducing need to detail return structure.
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?
Covers two required params (list_id, survey_id) with origin notes, but omits the optional 'account' parameter. Schema coverage is 0%, so description should explain all params; missing one is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it unpublishes a live survey, taking it offline. It distinguishes from publish_survey and list_surveys by referencing them as prerequisites/alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use list_surveys to find survey_id and confirm published state, and that publish_survey can restore it. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses partial update behavior ('Only provided fields are changed'), error return (404 if invalid IDs), and typical use cases. Annotations (readOnlyHint=false) align with mutation. Adds value beyond annotations.
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?
Concise opening, followed by usage paragraph, return info, and structured Args list. No wasted sentences, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameters, return format, error handling, and use cases. Output schema exists but not detailed; description says 'Returns: JSON with...' which is sufficient. Missing 'account' parameter mention reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description lists all 10 parameters (missing 'account' from schema) with brief explanations (e.g., 'type: New type ('fixed' or 'percentage')'). Compensates well for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update an existing promo rule' and provides example use cases like toggling enabled, extending end date, adjusting amount. Distinct from siblings like create_promo_rule, delete_promo_rule, and list_promo_rules.
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?
Gives when-to-use scenarios (toggle rule, extend end date, adjust amount) and references list_promo_rules to find IDs. Does not explicitly state when not to use, but context is clear.
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?
Annotations are all false. Description adds operational details: mutation behavior, partial update for non-line fields, and error response. Does not contradict annotations. Could mention idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, uses bullet points, and is efficient. Minor redundancy with schema but overall clear and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, return fields, and error condition. Missing details like rate limits or authentication, but given no output schema, return info is helpful. Adequate for a relatively simple update operation.
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 compensates fully by listing all parameters with clear, concise explanations, including the special behavior for lines_json.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates an existing cart, lists specific updatable fields (totals, currency, checkout URL, line items). Distinct from sibling create_store_cart and delete_store_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that only provided fields change and that partial line-item updates are not supported, guiding users to alternative methods. Mentions 404 error for invalid IDs. Lacks explicit comparison to other tools but provides clear context.
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?
Annotations indicate a write operation (readOnlyHint false) and the description confirms it updates a customer. It specifies that only fields provided in additional_fields are changed and returns the updated JSON object. Does not detail permissions or side effects, but adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, partial update behavior, context, then Args and Returns sections. Every sentence adds value without fluff.
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 4 parameters and an output schema, the description covers inputs and output adequately. It provides context about automatic sync vs manual updates. Could mention error handling or required permissions, but is largely 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?
Schema description coverage is 0%, but the description compensates by explaining store_id, customer_id, and additional_fields (with examples like opt_in_status, first_name, etc.). The account parameter is not described, but it is optional and the main parameters are well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing store customer'), lists specific updatable fields (name, opt-in status, address, company), and notes that manual writes are for custom/headless storefronts. This distinguishes it from create, delete, get, and list customer tools.
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 explains when to use the tool (manual updates for custom/headless stores) and notes that many stores sync automatically. It does not explicitly state when not to use or name alternative tools, but the context is clear.
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?
Annotations show it's a write operation; description adds merge behavior (only changed fields) and integration caveats. Could mention side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-paragraph structure: behavior first, then args. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers merge behavior, integration context, parameter sources. Missing error handling and permission details, but output schema exists for 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?
With 0% schema description coverage, the description explains store_id, order_id, and additional_fields with examples. However, the 'account' parameter is not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'e-commerce order's fields'. It distinguishes from create, delete, and get operations among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (partial field updates) and contrasts with automatic sync for Shopify/WooCommerce, providing context for manual vs. integrated stores.
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?
Annotations indicate the tool is not idempotent and not destructive. The description adds context that templates are unaffected, which clarifies nondestructive behavior. It also specifies the return structure (id, name, count), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear one-line purpose, usage note, and separate Args/Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple rename tool: it covers purpose, effect, prerequisite, and return structure. The missing documentation of the 'account' parameter is a minor gap, but overall the tool is understandable.
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 details two of three parameters: folder_id (including how to obtain it) and name (new display name). The optional 'account' parameter is not mentioned, but the required parameters are well-explained. Schema coverage is 0%, so the description compensates adequately.
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 ('Rename') and resource ('existing template folder'). It also explains that templates assigned are unaffected, which distinguishes it from other folder operations like create or delete.
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 the tool ('rename a folder's display name') and mentions a prerequisite tool ('list_template_folders' to discover IDs). It does not explicitly exclude other scenarios, but the simplicity of the operation makes that acceptable.
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?
Annotations already indicate non-readonly, non-idempotent, non-destructive. The description adds behavioral context: the title must be unique, type controls form interaction, and the operation creates a container. It does not conflict with annotations and provides useful constraints beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~150 words) and well-structured: summary sentence, usage guidance, Args, Returns, Example. Every sentence adds value, with no fluff. The format makes it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is complete. It explains the workflow, parameter roles, return value fields, and provides an example. All necessary information for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well. It defines three required parameters (list_id, title, type) with examples and valid values for type. The optional 'account' parameter is not described, but it is default null and not required. The description covers the key parameters thoroughly.
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: 'Create a new interest category (group container) in an audience for organizing subscriber preferences.' It specifies the verb (create), resource (interest category), and its role as a container. It distinguishes from sibling create_interest by describing the typical workflow, avoiding confusion.
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 explains when to use the tool ('to create a container for interest options'), provides a typical workflow (create_interest_category -> create_interest), and suggests checking existing categories with list_interest_categories. It gives guidance on the type parameter's behavior. It does not explicitly state when not to use, but the context is sufficient.
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?
Annotations are sparse (non-readonly, non-idempotent, non-destructive). The description adds value by noting case-insensitive matching, default enabled=true, and that usage_count starts at 0. It also describes the return JSON structure, which annotations lack.
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 compact yet comprehensive: a one-line summary, behavioral notes, error codes, bullet-arg descriptions, and return format. No fluff; every sentence 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?
For a creation tool with 7 parameters, output schema, and known error states, the description covers the essential usage context. It omits rate limits or auth details, but these are not critical given the sibling context and annotations.
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 has 0% description coverage; the description compensates fully with an Args section that explains each parameter's meaning and purpose (e.g., 'code' as the string customers type, 'promo_rule_id' sourced from list_promo_rules, 'promo_code_id' as client-supplied unique ID).
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 starts with a clear verb and resource: 'Create a redeemable code under an existing promo rule.' It explains the tool's purpose, distinguishes it from siblings like list_promo_codes and delete_promo_code, and provides the shopping context.
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 advises using list_promo_codes to avoid duplicates and mentions error codes (400/409) for missing rule or duplicate ID. It implicitly requires an existing promo rule, but does not explicitly contrast with update_promo_code.
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?
Beyond annotations, the description reveals that there are no destructive side effects, explains parameter dependencies for static/dynamic behavior, and describes the return structure. It adds significant behavioral context, though it could mention error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, guidance, and parameter list. It is suitably concise while providing necessary details, though the Args section is slightly 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 (6 parameters, 0% schema coverage) and the presence of an output schema, the description covers purpose, usage, parameters, and return. It could include error handling or idempotency, but overall it is sufficiently 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, the description provides detailed explanations for most parameters (list_id, name, static, match, conditions_json), including format, source, and conditional requirements. However, the 'account' parameter is omitted, leaving its role unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a segment or tag, distinguishes between static and dynamic segments, and contrasts with sibling tools like tag_member. The action is well-defined and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use static vs dynamic, mentions prerequisites for list_id, and directs users to alternative tools (add_members_to_segment, tag_member) for related tasks. This provides excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent nature, but description adds specific details: immediate URL unavailability, analytics retention, return format, and 404 error handling. These go beyond annotation values.
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, front-loaded action, and no unnecessary words. Each sentence contributes meaningful 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?
Covers action, side effects, error handling, return value, alternative tool, and parameter details. Output schema exists but description supplements it with usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Describes page_id parameter with source (list_landing_pages), adding meaning beyond schema. However, account parameter is not described. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a landing page' with specific verb and resource. Distinguishes from unpublish_landing_page by contrasting permanence versus temporary offline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (permanent deletion) and when not to (use unpublish_landing_page for temporary). Includes side effects and error case, guiding agent decision-making.
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?
Annotations already mark destructive and idempotent. Description adds 'Cannot be undone', 'Does not affect related orders or customers', and return format. This provides additional behavioral context beyond annotations, though it omits details like required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one sentence on purpose, one on usage, one on side effects, one on error, plus structured Args/Returns. Front-loaded with key info, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage, errors, and return format. With only 3 parameters and simple behavior, the description is fully adequate for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must fully explain parameters. It describes store_id and cart_id with brief meanings but omits the optional 'account' parameter entirely. Partial coverage reduces usefulness.
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 'Permanently delete a cart from a store' with a specific verb and resource. It distinguishes from related delete tools by noting it does not affect orders or customers, and provides a specific use case (completed or expired carts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when an external system reports the cart has been completed or expired'. Also specifies error behavior (404) and what is not affected, giving clear context for decision making.
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?
The description adds significant behavioral context beyond annotations: it explicitly states the permanent, irreversible deletion and the return format (empty body on success or error object). Annotations already mark destructiveHint=true and idempotentHint=true, so the description reinforces and supplements these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short paragraphs front-load the action and separate purpose from arguments/returns. Every sentence adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with four parameters, the description covers all necessary aspects: action, permanence, use-case distinction, parameter meanings, source hints, and return behavior. No gaps remain for the agent to invoke the tool correctly.
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 guidance for all three required parameters (store_id, product_id, image_id), including the source for store_id. The optional 'account' parameter is not described, but the core parameters are well-covered.
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 verb-resource pair ('Permanently delete an image from a product') and distinguishes this tool from integrated platform sync (Shopify/WooCommerce), differentiating it from sibling tools like update_store_product_image or other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: manual/custom stores vs integrated platforms where sync handles images. It also mentions a prerequisite (obtain store_id from list_ecommerce_stores). However, it could more explicitly state when not to use this tool (e.g., for integrated stores), though it's strongly implied.
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?
Annotations already declare readOnlyHint=true, but the description adds 'No network call. Read-only, safe to retry,' providing context about behavior and retry safety beyond annotations. No contradictions.
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?
Concise and well-structured: a clear purpose statement, usage guidance, behavioral note, and a structured Returns section. Every sentence adds value with no redundancy.
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 zero parameters and an output described clearly, the description is complete. It explains the tool's purpose, usage context, behavior, and return format, enabling full understanding.
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?
Input schema has zero parameters, so parameter semantics are not applicable. However, the description explains the return structure in detail (summary and tools array), which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List every tool with its machine-readable risk classification for policy enforcement,' which clearly states the verb and resource. It also distinguishes from the tools/list endpoint, enhancing clarity among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to discover which tools are reads, reversible writes, or destructive... before granting access or building automation.' Also mentions an alternative (tools/list), but does not explicitly say when not to use, which would be ideal.
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?
Annotations already declare readOnlyHint=true, so the tool is clearly non-destructive. The description adds behavioral context such as including repeat and unique clicks, click percentage, and constraints like requiring a sent campaign. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (purpose, usage, args, returns, example). Every sentence adds value, and it is front-loaded with the purpose.
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 that an output schema exists, the description does not need to detail return values, but it still provides an example and explains each field. It also covers prerequisites and usage context, making it complete for a read-only retrieval 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 explain parameters. It adequately explains campaign_id (with example and requirement) and count (range and default). However, the optional 'account' parameter is not mentioned, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves per-link click data for a campaign, specifying the verb 'Retrieve' and resource 'per-link click data'. It distinguishes from siblings like get_campaign_report and get_email_activity by mentioning their different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to analyze which links drove engagement' and provides alternatives for aggregate totals and per-recipient timelines. Also notes prerequisite: 'Only works for sent campaigns.'
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?
Annotations already declare readOnlyHint=true. Description adds that it's a 'high-level overview' and only works for sent campaigns. This is valuable context beyond annotations, but doesn't detail failure modes or post-conditions for unsent campaigns.
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?
Description is concise: one-line summary, then usage hints, parameter details, and return format. Every sentence adds value, no fluff. Front-loaded with key info.
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 output schema (explicitly listed return fields), annotations, and sibling tools, the description covers all necessary aspects: parameters, constraints, return structure, and alternatives. No missing 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 coverage is 0%, so description must compensate. It adds helpful meaning for campaign_id (format 'abc123def4', prerequisite sent status, source). However, the optional account parameter is not described, leaving a gap. Overall adds some value but incomplete.
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 'Retrieve aggregate performance metrics for a sent campaign', using a specific verb and resource. It distinguishes from sibling tools by directing to get_campaign_click_details, get_open_details, and get_campaign_recipients for different granularities.
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?
Clear when to use: only for sent campaigns. Provides explicit alternatives (get_campaign_click_details for per-link data, get_open_details for per-recipient opens, get_campaign_recipients for delivery status) and instructs how to obtain campaign_id via list_campaigns(status='sent').
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?
The description states 'Read-only, no side effects,' which aligns with annotations (readOnlyHint=true). It adds valuable context about returning empty data for regular campaigns and varying format by campaign type, going beyond the annotation alone.
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?
Very concise: one sentence for purpose, brief usage guidelines, and structured Args/Returns sections. No unnecessary words, all sentences earn their place.
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 output schema exists, the description still provides useful return format details (A/B vs RSS). It covers prerequisites, type checks, and parameter source, making the tool usage clear and 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?
With 0% schema description coverage, the description must compensate. It describes campaign_id with format example, type constraints, and source, but does not mention the optional account parameter. This partially covers parameter semantics.
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 starts with a clear verb and specific resource: 'Retrieve child report data for A/B test, variate, or RSS campaign sub-items.' It explicitly distinguishes from the sibling tool get_campaign_report for regular campaigns, leaving no ambiguity.
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 when-to-use and when-not-to-use guidance: 'Returns empty data for regular campaigns; use get_campaign_report instead. Check campaign type with get_campaign_details first.' This clearly outlines prerequisites and alternatives.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds that it returns only the last 50 events and returns an error if the member is not found, providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief header line, a usage paragraph, clearly labeled Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, read-only, output schema present), the description covers all critical aspects: purpose, usage guidance, parameter details for required params, return format, error case, and limits. It is sufficiently complete for correct tool invocation.
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 0% description coverage, so the description must compensate. It explains the two required parameters well (list_id format and source, email_address handling) but omits the optional 'account' parameter entirely. Given the baseline for low coverage is low, this is adequate but not 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 clearly states the tool retrieves the last 50 Goal events for a specific audience member. It uses a specific verb ('Retrieve') and resource ('Goal events'), and distinguishes itself from the sibling tool get_member_activity by noting the latter is for broader email activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('to see which tracked website Goals a member has hit') and provides alternatives: use get_member_activity for broader email activity and search_members to locate a member first. This gives clear guidance on tool selection.
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?
Annotations already declare readOnlyHint=true. Description adds that it returns 404 for invalid store_id or promo_rule_id, and lists returned fields, which provides context beyond annotations. Rate limits or auth are not mentioned but are acceptable for a simple read 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?
Description is well-structured: purpose sentence, usage guidance, error behavior, args list, return list. No wasted words, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers all essential aspects: purpose, when to use, alternatives, error conditions, parameters, and return values. No gaps given that an output schema exists and annotations are present.
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 description must explain parameters. It explains store_id and promo_rule_id briefly but omits the optional account parameter entirely. The returned fields list helps but doesn't cover all params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single promo rule by ID with full configuration, using a specific verb and resource. It distinguishes from siblings like list_promo_rules for browsing IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: inspect before updating or confirm existence before attaching codes. Provides alternative: use list_promo_rules to discover IDs. Also notes 404 for invalid IDs.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns a JSON store object with configuration and connection details, including sync status. This provides sufficient behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the main purpose front-loaded. It includes a clear Args and Returns section without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (documenting return values), the description sufficiently covers the tool's purpose and key usage. It references the sibling list_ecommerce_stores for discovery, making it complete for a simple read 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 adequately describes the store_id parameter (obtain from list_ecommerce_stores), which is the only required param. However, the optional account parameter is not described. With 0% schema description coverage, the description should cover both parameters; the omission of account reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single e-commerce store with specific details (configuration, connection, currency, audience, sync status). It distinguishes from list_ecommerce_stores, which is used for browsing and discovering store_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (inspect a store's details) and points to list_ecommerce_stores as the alternative for browsing and finding store_ids. Provides clear context.
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?
Annotations already indicate readOnlyHint=true. Description adds value by specifying 404 error for invalid IDs and listing return fields (id, title, status, etc.), which are not covered by annotations. No contradiction.
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?
Description is 132 words, front-loaded with purpose, then usage, error, and clearly labeled Args/Returns. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (get a single survey) and output schema exists, the description provides sufficient details: purpose, usage, error behavior, parameter sources, and return preview. It is 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?
Schema has 0% description coverage, so description must compensate. It explains list_id as 'Audience/list ID (from list_audiences)' and survey_id as 'Survey ID (from list_surveys)', adding source context. The optional account parameter is not mentioned, but it is less critical.
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 'Retrieve full details for a single survey' with specific verb and resource. It differentiates from siblings like list_surveys and get_survey_report by focusing on full details including questions, status, and URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when you have a survey_id from list_surveys and need questions/status/URL. Also directs to publish/unpublish for changing liveness. However, it does not explicitly mention when not to use or list all alternatives among siblings.
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?
Annotations already declare readOnlyHint=true. The description adds value by disclosing the 404 error behavior when the member does not exist, and explains the return format including fields like email_address, total_items, and notes array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the primary purpose, adds a clarifying note about internal use, mentions related tools, an error case, then lists parameters and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (including optional 'account'), and the description explains 4 of them. The return format is fully described. For a read-only list tool with good annotations, the description is largely complete, though the 'account' parameter is omitted. No output schema is provided, so the return description is 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?
Schema description coverage is 0%, but the description compensates by providing detailed parameter explanations: list_id (10-char alphanumeric, source), email_address (must exist), count (range 1-1000, default 20), offset (pagination). Return structure is also described. Only the optional 'account' parameter is not mentioned, but its default null makes it less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'CRM-style notes attached to a member', and distinguishes from sibling tools like add_member_note, update_member_note, delete_member_note. It also specifies that notes are internal and not visible to contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Notes are internal annotations... not sent to the contact' and references related tools for creating, updating, and deleting notes. It lacks explicit when-not-to-use instructions but gives sufficient guidance for proper usage.
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?
Annotations already indicate readOnlyHint=true, so description adds value by specifying error condition (404 on invalid list_id) and return format. No contradictions.
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?
Concise, front-loaded with core purpose, no fluff. Structured docstring adds clarity without extra length.
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 output schema exists and annotations cover safety, description adequately covers usage, error, and return format. Complete for a read-only inspection 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 has 0% description coverage. Description documents list_id as 'from list_audiences', adding context, but omits account parameter. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets signup forms for an audience, listing components (header, body, styles). It distinguishes from customize_signup_form by instructing to use this to inspect before changing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use to inspect... before changing them with customize_signup_form', providing clear when-to-use and alternative. Also notes 404 error for invalid list_id.
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?
Annotations already indicate readOnlyHint=true (safe read operation). Description adds detail: pagination via offset and total_items, required active integration, and return structure. No contradiction, but could mention idempotency or rate limits. Still adds significant value beyond annotations.
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?
Highly concise: single introductory sentence, followed by usage guidelines, then Args, Returns, and Example. Front-loaded purpose, no redundancy.
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 4 parameters, output schema, and context signals, the description provides purpose, usage guidelines, parameter details, return format, and an example. Covers all essential information for a list 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 coverage is 0%, so description bears the burden. It explains store_id, count (with range 1-1000, default 20), and offset (pagination), but does not mention the 'account' parameter. While the output schema provides return structure, the missing parameter weakens completeness.
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 states a specific verb (list) and resource (customers from a connected e-commerce store), and distinguishes itself from sibling tools like list_store_orders (per-order detail) and list_segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (analyze customer behavior, identify high-value customers) and when not to (use list_store_orders for order detail), and provides prerequisite: requires active integration and to find store IDs via list_ecommerce_stores.
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?
Annotations already declare readOnlyHint=true. Description adds that it returns total_items: 0 if no integration configured, and provides example. No contradictions.
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 separate sections for description, args, returns, and example. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description explains return fields. Covers use cases, parameters, return behavior, and edge case (no integration). Fully adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description documents store_id, count, offset, and their usage. Missing account parameter, which is not explained. Example clarifies usage.
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?
Clear verb 'List' and resource 'products from a connected e-commerce store', with specific output fields. Distinguishes from sibling tools like get_store_product, create_store_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (browse catalog, verify sync, find product data for campaigns) and directs to alternatives (list_ecommerce_stores, get_ecommerce_product_activity).
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?
Annotations provide no behavioral info, but description adds that resuming continues sending scheduled editions and returns a JSON confirmation or error. Could mention idempotency or side effects, but it's fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: functional description first, then usage context, then args and returns. No fluff, sentences earn their place.
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 simple action and presence of output schema, the description covers prerequisites (paused state, RSS type), parameter source, and return type. Complete for the tool's 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 0%. The description explains campaign_id well (source and purpose), but the optional account parameter is not described. Partially compensates for lack of schema descriptions.
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 'Resume' and the resource 'paused RSS-driven campaign'. It distinguishes from siblings by specifying it only applies to RSS campaigns and is the counterpart to pause_rss_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for restarting an RSS campaign paused with pause_rss_campaign, notes it applies only to 'rss' type, and advises using get_campaign_details to confirm type. Provides clear context and alternatives.
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?
The description adds behavioral details beyond the annotations, such as the query length restriction and the structure of the return data. Annotations already indicate read-only, and no contradictions exist. Minor missing detail: pagination behavior is mentioned but not fully elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear introductory sentence, usage guidance, parameter list, and return description. No redundant 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?
For a search tool with an output schema present, the description covers input parameters (mostly), output format, usage context, and constraints. It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given the schema has 0% description coverage, the description covers three of four parameters: query (with min length), count (with default and range), and offset (pagination). However, the 'account' parameter is not mentioned, leaving a gap.
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 campaigns by keyword across titles, subject lines, and list names.' It also distinguishes itself from the sibling tool list_campaigns, providing clear differentiation.
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?
Explicit guidance is provided: 'Use to find campaigns when you do not know the ID. Use list_campaigns to browse by status or date instead.' Also warns about query length: 'Queries under 3 characters return an error.'
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds detailed behavioral context: tags are case-insensitive, created if new, silently ignored if absent, idempotent, and returns 404 if member doesn't exist. It also clarifies that profile data and subscription status are unaffected. This goes beyond annotations to fully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose sentence, behavioral details, usage guidance, parameter list, return format. Each section is concise and adds value. While it could be slightly tighter, it is not overly verbose and is easy to scan.
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 (5 parameters, annotations, output schema), the description covers purpose, usage guidelines, behavioral transparency, parameter semantics (mostly), return format, and error cases. The missing 'account' parameter description is a gap, but overall the tool is well-documented. The output schema exists, so return format details are not required.
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. The 'Args' section explains list_id, email_address, tags_to_add, and tags_to_remove with clear formats and examples. However, the parameter 'account' (present in the schema) is not described in the Args section, leaving its purpose unclear. This omission prevents full compensation for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource: 'Add or remove tags from a single member.' It also explicitly states what it does not modify ('Does not modify profile data or subscription status'), which distinguishes it from other member tools. Sibling differentiation is provided later when listing alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool vs alternatives: 'Choose the right member tool: tag_member for per-member tag changes, add_members_to_segment for bulk-adding members to a tag/segment, add_member with tags param for tagging at signup, update_member for profile/status changes, get_member_tags to check current tags.' This is comprehensive and leaves no ambiguity.
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?
Discloses that 'Choices are replaced entirely (old choices are lost),' which is a destructive-like behavior beyond annotations. Also mentions 404 error for invalid merge_id. Annotations have destructiveHint: false, which is consistent since this is an update, not deletion. Provides useful context beyond structured fields.
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?
Well-structured with clear sections: purpose, caution, error info, args, returns. Front-loaded with main action. Some redundancy in args section (e.g., 'Only provided fields are updated' could be implicit), but overall efficient and easy to parse.
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 7 parameters, 0% schema coverage, and no enums, the description covers all aspects: parameter semantics, constraints, error handling, and return format (JSON with fields). Output schema exists but description adds valuable detail. No gaps for an update 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, the description fully carries parameter meaning. It explains all 7 parameters, including format of list_id (10-char alphanumeric), merge_id (numeric string), and the comma-separated format for choices, plus their constraints (choices ignored for non-dropdown/radio types). This goes far 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?
Description clearly states 'Update a merge field's name, default value, required flag, or dropdown/radio choices.' This verb+resource combination is specific and distinct from siblings like create_merge_field and delete_merge_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states not to use for changing field type or tag, instead directing to delete_merge_field then create_merge_field. Also provides sources for list_id and merge_id. However, lacks explicit when-not conditions for other scenarios like partial updates vs. full replacement.
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?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the partial update behavior and that it mutates data, which aligns with annotations and provides useful context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear sections (Args, Returns), and front-loaded with the essential purpose. Every sentence adds value, and there is no unnecessary 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 tool has 5 parameters and an output schema, the description covers purpose, usage context, parameter details, and return type. It addresses the partial update behavior and integration scenarios, making it complete for effective 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?
Despite 0% schema description coverage, the description provides meaningful explanations for store_id, product_id, image_id, and additional_fields. It includes examples (url, variant_ids) and how to obtain store_id. Only the 'account' parameter is not described.
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 'Update an image attached to a product in an e-commerce store.' It uses a specific verb (update) and resource (product image), and it distinguishes itself from sibling tools like create_store_product_image and delete_store_product_image.
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 explains that only fields in additional_fields are changed (partial update) and provides context about manual vs automatic sync for different store types. It also tells how to obtain the store_id. However, it lacks explicit guidance on when not to use this tool or alternatives.
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?
Annotations are present but the description adds behavioral context: it explains that the tool updates the script installation status in the returned record. This goes beyond the readOnlyHint=false annotation, clarifying that the operation is not read-only and modifies state. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences plus Args/Returns sections) and front-loaded with the main purpose. Every sentence adds value with no redundant 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 tool's simplicity, the description covers all essential aspects: what it does, when to use it (after create_connected_site), what it returns (updated record), and how to get the required parameter. An output schema exists, so return values don't need further elaboration.
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 provides meaningful detail for the required parameter 'connected_site_id' (explaining its purpose and how to obtain it). The optional 'account' parameter is not mentioned, leaving some gap. Baseline 3 is appropriate as the description adds necessary context but does not fully compensate for the missing schema descriptions.
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: 'Verify that the Mailchimp tracking script is correctly installed on a connected site.' It uses a specific verb (verify) and resource (connected site script), and distinguishes itself from siblings like 'create_connected_site' and 'get_connected_site' by specifying the workflow step.
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?
Explicit guidelines are provided: 'Run after installing the script returned by create_connected_site' and 'Use get_connected_site to check the current installation status instead.' This tells the agent when to use this tool and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide basic behavioral hints (non-readonly, non-idempotent, non-destructive). Description adds useful context: prerequisites (members must exist), return format (total_added, total_removed, errors array), and implicit mutability. No contradictions.
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?
Description is structured with a clear paragraph and Args/Returns sections. Though slightly verbose, every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, constraints, parameter details, prerequisites, return format, and differentiation from siblings. No output schema exists, but description provides enough return info. Complete for a tool of this 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?
Schema description coverage is 0%, but description compensates well: provides format and source for list_id ('10-char alphanumeric, e.g. 'abc123def4'. Obtain from list_audiences'), segment_id, and emails. The 'account' parameter is not described, but the three required ones are clearly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Add members'), resource ('static segment or tag'), and method ('by email address'). Distinguishes from dynamic segments and mentions sibling tool 'tag_member' for single-member management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Only works on static segments (tags), not dynamic segments. Members must already exist in the audience.' Provides alternative: 'Use tag_member for single-member tag management instead.'
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?
Annotations provide no behavioral hints beyond non-destructiveness. Description adds transparency about asynchronous nature, polling requirement, and return of download URL. Does not mention rate limits or data retention but sufficiently discloses workflow.
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?
Concise, with front-loaded purpose and usage, followed by parameter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema and description explains return fields. Parameters are covered. Lacks error conditions or prerequisites but is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains include_stages with examples and meaning. Account parameter is optional and nullable but lacks explanation. Overall, description adds value beyond 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 it starts an account export job covering requested categories. It distinguishes from sibling tools like list_account_exports and get_account_export by specifying the action and 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?
Explicitly tells when to use it (request archive), how to poll for completion, and suggests checking existing exports with list_account_exports before starting a new one.
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?
Annotations are minimal (readOnlyHint false, etc.), so the description carries the burden. It discloses that the type cannot be changed after creation and that fields are populated via add_member/update_member. It does not cover all behavioral aspects like error handling or rate limits.
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 with a brief overview, a clear 'Args' section, a 'Returns' section, and an example. It is concise yet comprehensive, with no wasted words.
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?
The description is fairly complete, covering the purpose, parameters, return value, and linking to list_merge_fields. However, it does not mention the sibling delete_merge_field or handle potential error scenarios. The output is described despite the presence of an 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?
Schema has 0% coverage, so the description compensates by explaining most parameters (list_id, name, type, tag, required, default_value, choices) including the relationship between choices and type. However, it misses the 'account' parameter from 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 tool's purpose: 'Create a new custom merge field in an audience for storing additional member data.' It distinguishes from sibling tools like list_merge_fields and update_merge_field by its specific verb and resource.
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 guidance: 'Use to add custom data fields beyond the defaults' and advises using list_merge_fields to check existing fields first. It also mentions prerequisites like obtaining list_id from list_audiences.
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?
Annotations (readOnlyHint=false) are consistent with a creation operation. Description adds behavioral context: line_id uniqueness requirement, product existence prerequisite, and that it's a manual vs synced operation. No contradiction.
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?
Concise and well-structured: purpose in first sentence, context paragraph, then bulleted args. Every sentence adds value without redundancy.
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?
With 7 required parameters, output schema exists (though not detailed), and the description covers return format, usage context, and integration differences. No gaps for an agent to safely execute.
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 coverage is 0%, but the description thoroughly explains all 9 parameters, including the optional additional_fields and the unique constraint on line_id. The 'Args' section adds meaning beyond property names.
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 'add' and resource 'line item to an existing e-commerce order,' distinguishing it from sibling tools like create_store_order (creating an order) and update_store_order_line (updating).
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?
Provides clear context: it's for custom/headless stores, while integrations sync automatically. Specifies constraints like unique line_id and existing product/variant. Lacks explicit 'when not to use' but sibling tools imply alternatives.
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?
Discloses that image_id must be unique within product and url must be publicly reachable. Annotations indicate it's a write operation (not read-only), and description adds context beyond annotations. However, doesn't specify behavior if image_id already exists (overwrite vs error).
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 overview, parameter details in list, and return description. No superfluous content; every sentence adds value. Appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, usage context, and return value. Output schema exists so return details are sufficient. Minor gap in not describing the 'account' parameter, but overall comprehensive for a creation 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?
Adds meaning for 5 of 6 parameters (store_id, product_id, image_id, url, additional_fields) beyond schema. Provides examples and usage notes. Missing description for 'account' parameter, which is optional but still undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add an image to a product in an e-commerce store' with specific verb and resource. Distinguishes from siblings like delete_store_product_image and other store operations by specifying the action and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool for manual/custom stores versus when not (Shopify/WooCommerce sync automatically). Also provides prerequisite by mentioning how to obtain store_id from list_ecommerce_stores.
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?
Annotations already indicate it's a write operation (readOnlyHint false). The description adds meaningful context: the created template has type 'user', active boolean, date_created, and the HTML must be valid with inline CSS and merge tags. However, it does not discuss error conditions or prerequisites beyond the schema.
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 a concise summary, usage instructions, parameter list, and return description. No unnecessary text; front-loaded with the core purpose.
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 presence of an output schema (implied by return description) and annotations, the description covers the essential workflow, parameters, and return value. Missing documentation for the 'account' parameter and no guidance on error handling, but otherwise 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 description provides clear explanations for name, html, and folder_id parameters, including examples and constraints. However, the 'account' parameter is not documented in the description, leaving a gap despite schema description coverage of 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a reusable email template from HTML content, distinguishes from sibling tools like set_campaign_content (for one-off emails) and mentions get_template_default_content and list_templates for related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (save HTML designs for reuse), when not to use (for one-off emails, use set_campaign_content), and provides workflow context (retrieve HTML later with get_template_default_content, browse with list_templates).
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?
Beyond annotations (destructiveHint: true), the description adds critical behavioral details: irreversible action, consequence of broken images for referencing campaigns/templates, and return format. No contradiction with annotations.
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: purpose first, then warnings and instructions, then arguments and returns. It is concise with no fluff.
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 two parameters and annotations for safety, the description covers usage flow, consequences, and return type. However, the undocumented account parameter and lack of output schema in the definition reduce completeness slightly.
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 documents file_id with type and source (numeric string from list_files), but does not mention the optional account parameter, leaving a gap. Schema coverage is 0%, so description must compensate but only partially succeeds.
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 'Permanently delete a file from the File Manager.', which specifies the verb and resource. It also distinguishes from sibling delete tools by specifying the File Manager context.
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: 'Use list_files to find the file_id and get_file to confirm the target before deleting.' This tells the agent when and how to prepare for using this tool.
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?
Describes that the interest and its subscriber associations are removed, and that an error is returned if the interest does not exist. Annotations already indicate destructive and idempotent behavior; the description adds practical context but does not fully explain idempotency implications.
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: first sentence defines purpose, then usage guidance, then Args list, Returns, and Example. Each part is concise and front-loaded with key 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?
Covers purpose, parameters, return format, and example. Missing a note about the 'account' parameter and could elaborate on error handling, but overall sufficient for a simple delete 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 description explains the meaning and source for three required parameters (list_id, category_id, interest_id), adding value beyond the schema. However, the optional 'account' parameter is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a single interest option from a category, preserving others. It distinguishes from the sibling tool delete_interest_category, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('remove one specific option') and when to use the alternative ('delete_interest_category instead'). Also provides guidance on how to obtain required IDs from other tools.
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?
The description adds value beyond annotations by detailing that the order and its lines are permanently removed and that the action cannot be undone. Annotations already indicate destructive and idempotent hints, and these descriptions align without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, effect and caution, store type context, and an Args/Returns section. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the destructive nature, scope of deletion, how to get parameters, and expected return. It could mention error cases (e.g., order not found), but given the simple delete operation, it is reasonably 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 description explains the two required parameters (store_id and order_id) and how to obtain store_id from list_ecommerce_stores. The optional 'account' parameter is not mentioned, but with 0% schema coverage, the description compensates well for the critical parameters.
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 action: 'Permanently delete an e-commerce order from a store.' It specifies the verb (delete) and the resource (order), and distinguishes it from siblings by focusing on orders, not carts or customers.
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 advises that the operation cannot be undone and provides context about store types (manual vs. integrated), implying when to use it. However, it does not explicitly state when not to use it or compare to alternatives like update actions.
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?
Annotations already declare readOnlyHint=true, so description doesn't need to reiterate. Description adds valuable context: pagination details (count, offset), return structure (JSON with total_items and activity array), and field semantics (day, emails_sent, etc.). No contradictions.
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: purpose, usage guidance, parameters, returns. Each section is concise and informative. No fluff. Front-loaded with the most important 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?
Description covers purpose, parameters, return structure, and alternatives. Missing explanation for the 'account' parameter, but since it's optional and likely obvious from context, the gap is minor. With output schema present, lack of full return description is 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?
Schema description coverage is 0%, so description must compensate. It describes 3 out of 4 parameters (list_id, count, offset) with format, examples, and constraints. The 'account' parameter is missing from the description, which is a minor gap. Overall adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve the recent daily activity for an audience' with specific verb and resource. It explicitly distinguishes from get_audience_details and list_campaigns, listing what those alternatives provide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'to inspect an audience's day-by-day engagement history over its recent lifetime.' Also provides clear alternatives: 'use get_audience_details for aggregate stats and list_campaigns for per-campaign performance.'
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?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds the return field list, which helps the agent understand the response. No side effects are mentioned, but the annotations cover the primary behavioral aspect.
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 very concise and well-structured: a purpose sentence, usage guidance, then parameter and return details. It front-loads the critical information and uses minimal words efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the two required parameters, it omits the optional 'account' parameter present in the schema. Additionally, with output schema available, listing return fields is helpful but somewhat redundant. The gap in parameter coverage reduces completeness.
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 the campaign_id and report_id parameters, including how to obtain each. This adds significant semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single abuse complaint for a sent campaign, with a specific verb ('retrieve') and resource. It distinguishes from sibling 'get_campaign_abuse_reports' which lists reports, so the agent can select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('to inspect the details of one complaint') and how to obtain required IDs from the list endpoint. This provides clear guidance on tool selection and prerequisites.
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?
Annotations declare readOnlyHint=true, so the description correctly aligns with read behavior. It adds context about sent-only restriction and detailed return format, though it doesn't elaborate on rate limits or auth requirements beyond what annotations imply.
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?
Front-loaded with purpose and usage, followed by Args, Returns, and Example. Every sentence is necessary and efficiently written.
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?
With an output schema present, the description still explains the return format. It covers the main use case and parameter behavior. The undocumented 'account' parameter and lack of error handling details prevent a perfect score.
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?
Despite 0% schema description coverage, the description explains campaign_id, count, and offset with constraints (range, default, pagination). The 'account' parameter from schema is not mentioned, which is a minor gap, but overall adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb-resource ('Retrieve the delivery roster') and clearly distinguishes from sibling tools by naming get_email_activity and get_campaign_report as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('verify who received a campaign and whether they opened it'), provides alternatives with different purpose, and notes the constraint 'only works for sent campaigns'.
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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral details beyond annotations, such as returning 404 for invalid IDs and empty arrays for unsent campaigns. It does not mention rate limits or authentication, but these are covered by the tool's annotation profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (around 100 words) and well-structured with clear sections: purpose, usage guidance, error cases, arguments, and return format. It is front-loaded with the primary action, making it easy to scan.
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 4 parameters, no nested objects, and an output schema exists (the description outlines the return structure), the description is largely complete. It covers error handling, pagination, and output format. The only missing element is the 'account' parameter, which may be relevant for multi-account contexts, so a slight deduction applies.
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 4 parameters with 0% schema description coverage. The description compensates by explaining campaign_id (required, format), count (range 1-1000, default 20), and offset (pagination). However, the 'account' parameter is not mentioned in the description, which is a minor gap.
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 'Retrieve members who unsubscribed from a specific sent campaign, with reasons.' It uses a specific verb+resource combination and distinguishes itself from sibling tools like get_campaign_report, which provides aggregate counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using get_campaign_report for aggregate counts instead of this tool. It also specifies when to use it (for a specific sent campaign) and covers error cases (404 for invalid campaign_id, empty array for unsent campaigns).
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?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds context on pagination (count, offset) and return structure, but does not mention any additional behavioral constraints like rate limits or permissions. No contradiction.
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?
Front-loaded with purpose and sibling references, followed by a clear Args section. Each sentence serves a purpose; no fluff. Well-organized and appropriately sized.
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?
With output schema existing, description doesn't need to detail return values, but it includes a helpful returns summary. Covers usage, parameters, and state constraints. Missing description of the 'account' parameter is a minor gap, but overall complete for a read-only paginated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains campaign_id (with example and constraint), count (range and default), and offset (pagination usage). However, the 'account' parameter is left undocumented, leaving a gap. Overall, adds significant meaning beyond 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?
Description clearly states verb 'retrieve', resource 'per-recipient open data', and scope 'for a sent campaign'. Explicitly distinguishes from siblings like get_campaign_report and get_email_activity, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use vs alternatives: 'Use get_campaign_report for aggregate open rates. Use get_email_activity for all activity types combined.' Also states prerequisite: 'Must be a sent campaign.'
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?
Annotations already declare readOnlyHint=true, so description adds value by specifying 404 error behavior and detailing return structure. No contradictions; idempotency hint is not addressed but not required.
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?
Description is concise and well-structured with overview, usage guide, error handling, bulleted args, and returns. No redundant sentences, every line serves a purpose.
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 presence of an output schema and read-only annotations, the description covers key aspects: purpose, parameter sources, error case, and return shape. Only minor gap is the undocumented account parameter, but overall sufficient for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains store_id and cart_id with sources (list_ecommerce_stores, list_store_carts). However, the optional 'account' parameter is left undocumented, leaving one parameter with no meaning added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single cart with full details (line items, customer, total breakdown). Differentiates from siblings like list_store_carts by specifying it returns a single cart and explicitly mentions use case of inspecting abandoned carts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (inspect abandoned cart before recovery email) and directs to list_store_carts for browsing cart IDs. Also notes that invalid IDs return 404, providing error handling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns JSON with specific fields, which is additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences for purpose and guidance, then Args list. No fluff.
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?
Description specifies return format (JSON with variant object) and mentions included fields, though no output schema provided. Overall adequate for a retrieval tool with 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?
Description explains three required parameters with context (e.g., 'Variant ID. Obtain from list_store_product_variants'). Misses the optional 'account' parameter, but still adds value beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve a single product variant' with specific attributes (price, SKU, inventory). Differentiates from sibling tool list_store_product_variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('to inspect one variant's attributes') and when to use alternative ('Use list_store_product_variants to browse and discover variant_ids').
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?
Annotations already indicate readOnlyHint=true. Description adds pagination behavior and filtering context. No contradictions, but does not disclose any additional behavioral traits beyond what annotations imply.
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: overview, usage guidelines, parameter list, return format, example. Front-loaded and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main parameters, output shape, and example. The missing 'account' parameter reduces completeness slightly, but overall adequate for a list tool with 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?
Schema coverage is 0%, but description adds meaning for count, offset, status, and since_send_time with valid values and format. However, it omits the 'account' parameter present in the schema, which is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists campaigns with metadata and filtering, and explicitly distinguishes from sibling tools like get_campaign_details, get_campaign_report, and search_campaigns.
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?
Provides explicit guidance on when to use this tool (browse, discover IDs) and when to use alternatives, including specific method names.
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?
Annotations already indicate no read-only, idempotent, or destructive hint. The description adds that publishing makes the survey live at its public URL and returns a status response. No hidden behaviors or contradictions.
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 first paragraph and bullet-like argument descriptions. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters, return values, valid states, and related tools. It lacks detail on error handling but mentions an error object. Given the simple action, it is nearly complete. Minor gap: no mention of prerequisites like authentication.
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 meaning for 'list_id' and 'survey_id' beyond schema titles by stating their sources (from list_audiences, list_surveys). However, the optional 'account' parameter is not mentioned. With 0% schema coverage, this is a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Publish a survey, making it live at its public URL') and the resource. It distinguishes from siblings like 'unpublish_survey' and 'list_surveys'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states valid states for the survey (draft, unpublished, edited), suggests using 'list_surveys' to find IDs, and mentions 'unpublish_survey' as an alternative. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: 'Non-existent members silently skipped' and 'Returns 404 if invalid IDs'. Annotations only indicate not read-only, not idempotent, not destructive, but description adds error handling and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then structured with bullet points for args and return. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers constraints (static only, silent skip), error handling, and return fields (total_added, total_removed, errors). Missing description for optional 'account' parameter, but overall complete for a mutation tool with 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?
Schema has 0% description coverage, but description explains list_id (10-char alphanumeric, from list_audiences), segment_id (numeric string, from list_segments), and emails (comma-separated). Optional 'account' parameter not described, but main parameters well documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Remove' and resource 'members from a static segment or tag'. Clearly distinguishes from 'tag_member' for single-member removal and states members remain in audience, differentiating from sibling tools like 'delete_member'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Only works on static segments (tags), not dynamic segments' and provides alternative 'Use tag_member with tags_to_remove for single-member removal'.
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?
Discloses non-idempotence: 'Not idempotent: calling twice creates two separate drafts.' and describes behavior like inheriting content and settings. This adds context beyond annotations (readOnlyHint=false, destructiveHint=true) without contradiction.
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?
Concise yet informative: first sentence states purpose, then covers idempotence, workflow, restrictions, error, and parameter details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects: purpose, usage, behavior, and return values. Minor gap is the missing description for the 'account' parameter. Overall, sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Campaign_id is well explained with example and source. However, the optional 'account' parameter is not described at all. With 0% schema coverage, the description should explain all parameters but fails to do so for account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Create a new draft campaign targeting only recipients who did not open the original.' This distinguishes it from siblings like create_campaign, replicate_campaign, etc., by specifying the targeting condition.
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?
Provides explicit workflow: 'resend_to_non_openers -> update_campaign (change subject) -> send_campaign or schedule_campaign.' Also states when not to use: 'Do not use for A/B test campaigns or campaigns sent less than 24 hours ago.' and error condition: 'Returns error if the original campaign status is not sent.'
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?
Discloses side effect: 'sends a real email.' Adds context beyond annotations: tests not counted against limits and not tracked. This is critical behavioral information not captured in structured fields.
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?
Concise and well-structured: first sentence states purpose, then notes side effect, then lists parameters with examples. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description explains the return format and error case. 3 of 4 parameters are explained (account missing). Differentiates well from siblings. Adequate for a test/preview 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?
Despite schema coverage of 0%, the description provides detailed explanations for campaign_id (example, prerequisite), test_emails (comma-separated, max 10), and send_type (default html, plaintext). The account parameter is not explained, slightly reducing completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sends a test/preview email to specific addresses without affecting the real audience. The verb 'send' and resource 'test/preview email' are specific, and it distinguishes from siblings like send_campaign by emphasizing it does not affect the real audience.
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?
Provides explicit guidance: 'Recommended before send_campaign or schedule_campaign' and prerequisite 'Campaign must have content set via set_campaign_content.' Also notes tests do not count against send limits and are not tracked in reports, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but description adds that only provided fields are updated (partial update) and returns 404 for invalid template_id. These are useful behavioral details beyond annotations.
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?
Description is concise with a clear structure: purpose, constraints, parameters, return value. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 params, no enums, has output schema), description covers update behavior, constraints, error handling, and return fields. Missing account parameter in description is a slight omission, but overall 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?
Schema coverage is 0%, but description covers 3 of 4 parameters (template_id, name, html) with clear usage details. Missing account parameter is a minor gap. Overall adds significant value beyond 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 'Update an existing template's name or HTML content' with a specific verb and resource. It also distinguishes from create_template by noting gallery templates cannot be modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user-created templates) and when not (gallery/base templates). Provides alternative: 'Use create_template to create a new template instead of modifying a gallery template.' Also mentions to obtain template_id from list_templates.
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?
Annotations indicate write operation (readOnlyHint=false) and non-destructive. Description adds crucial behavioral detail: side effect of sending double opt-in email for pending members. Does not mention rate limits or auth requirements, but covers key trait beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three clearly structured paragraphs: summary, usage guidelines with side effect, then parameter descriptions. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage, parameters, side effect, and return values. Complete for the tool's complexity with 4 parameters and existing 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?
Input schema has 0% description coverage. Description compensates by explaining list_id format and source, members_json structure and limits, update_existing behavior. Does not explain 'account' parameter, but overall adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool adds or updates up to 500 members synchronously. It distinguishes from siblings by specifying batch_subscribe is for 2-500 members, add_member/update_member for single, and create_batch for larger imports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: bulk operations. Provides alternatives: add_member/update_member for single, create_batch for >500. Clear context for choosing the right tool.
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?
The description discloses that the action is irreversible, cannot recall delivered emails, and only succeeds if the campaign is currently sending. Annotations are all false, but the description adds essential behavioral context beyond them without contradiction.
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?
Concise and well-structured: a brief statement followed by bullet points for conditions, arguments, and return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema not displayed, the description mentions the return JSON structure. It covers constraints, prerequisites, and error conditions adequately for a cancellation 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?
The description explains 'campaign_id' format and requirement, but does not cover the optional 'account' parameter. With 0% schema description coverage, the description partially compensates but leaves a gap.
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 cancels a campaign mid-send, using a specific verb ('Cancel') and resource ('campaign'). It distinguishes from sibling 'unschedule_campaign' by noting it's for scheduled campaigns, not sending ones.
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?
Clear guidelines: only works on campaigns with status 'sending', and advises using 'unschedule_campaign' for scheduled campaigns. Explicitly states when to use and when not.
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?
Annotations are minimal (readOnly=false, etc.), but description adds context: campaign is draft, cannot send until content set, return fields, error conditions. Slightly more detail on side effects would push to 5.
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?
Well-structured with sections, front-loaded purpose. Slightly long but all content earns its place. Could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (10 params, A/B variant, output schema exists), description covers prerequisites, return fields, error conditions, and example. Complete for decision-making.
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 has 0% description coverage, but description fully documents each parameter with purpose, defaults, fallbacks, constraints, and examples for A/B settings. Greatly aids correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a new email campaign in draft status with optional segment targeting or A/B testing. It distinguishes from sibling replicate_campaign and other campaign tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides typical workflow steps, directs to use replicate_campaign for cloning, and specifies when to use campaign_type='variate' for A/B testing. No misuse guidance needed.
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?
Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds context about the store's role and integration options, but does not elaborate on potential side effects, permissions, or error handling beyond creation.
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 summary paragraph and an Args list. It is slightly lengthy but every sentence adds value. No redundant 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 presence of an output schema, the description covers the tool's purpose, usage context, parameter details, and distinguishes from siblings. It provides complete context for an AI agent to select and invoke correctly.
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%, but the description's Args section explains each parameter with examples and context (e.g., store_id as unique ID, currency_code as ISO 4217, additional_fields as optional dict). This compensates fully for the missing schema descriptions.
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 'e-commerce store', and specifies its role as a top-level container for products, customers, carts, and orders. This distinguishes it from sibling create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions that many stores sync automatically via Shopify/WooCommerce integrations, and that this manual write suits custom or headless storefronts, providing clear guidance on when to use this tool vs alternatives.
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?
Annotations already declare it's not read-only, not idempotent, not destructive. Description adds key behavioral details: cart_id is client-supplied (no auto-generation), customer must exist before creation. This goes beyond annotations without contradiction.
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?
Well-structured: brief intro, then list of args with descriptions, plus return info. Front-loaded with purpose. Example for lines_json is helpful but slightly lengthy; overall efficient for the complexity.
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?
Covers purpose, usage, all parameters, return value, and preconditions. Output schema exists but description still provides useful return field list. Complete for a tool with 9 parameters and external dependencies.
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%, but description explains all 9 parameters in detail, including examples for lines_json and clarifying currency_code, checkout_url, etc. Adds significant meaning beyond the schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a cart in a store with line items and a customer reference.' and specifies the use case 'push abandoned-cart data from an external system into Mailchimp for recovery workflows.' This distinguishes it from sibling tools like create_store_order and update_store_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (abandoned-cart recovery), preconditions (customer must already exist via create_store_customer), and alternative (use update_store_cart for modifications). Provides clear context and exclusions.
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?
Annotations provide no safety hints (all false). Description fully compensates by detailing side effect (validation GET), default behavior (all events/sources enabled if omitted), return format, and error condition on validation failure.
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?
Description is well-organized with clear sections (overview, side effect, args, returns). Each sentence adds value. Slightly verbose but still efficient; could be more concise by omitting the explicit enumeration of events/sources since they are listed in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, side effects, defaults, and return value. Output schema exists but description adds detail (boolean flags for events/sources). Missing parameter 'account' is a gap. Compared to similar tools, this is quite thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description explains 4 of 5 parameters (list_id, url, events, sources) with format, defaults, and valid values. Missing documentation for 'account' parameter, which is present in schema but not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a webhook for audience event notifications. Distinguishes from sibling tools like create_batch_webhook by specifying audience events and explicitly advising against using for polling or batch data retrieval.
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?
Provides explicit usage context: when to use (audience event notifications) and when not to use (polling, batch data retrieval) with alternative tools listed. Also describes side effect (validation GET request) and prerequisite (publicly accessible URL returning 200).
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?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds that deletion is permanent, only works on non-sent campaigns, and returns an error for sent ones. It also details the return format (status, campaign_id), providing significant behavioral context beyond annotations.
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 main sentence, bulleted usage notes, and explicit Args/Returns/Example sections. Every sentence adds value, and it 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.
Completeness5/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 (1 required), annotations, and an output schema, the description covers purpose, constraints, parameter usage, return format, and an example. It is complete and leaves no critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description explains campaign_id with example and constraint ('Must not be a sent campaign'), but does not document the optional account parameter (anyOf string/null). So only one of two parameters gets semantic information, partially compensating.
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 starts with 'Permanently delete a campaign from the account', clearly stating the verb (delete) and resource (campaign). It further specifies it only works on unsent campaigns, distinguishing it from other delete tools like delete_audience or delete_member.
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?
Provides explicit guidance: 'Use to remove unwanted draft or scheduled campaigns. Only works on campaigns that have not been sent... Sent campaigns cannot be deleted and will return an error.' Also suggests using replicate_campaign before deleting to preserve settings, giving clear when-to-use and alternatives.
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?
Annotations indicate destructive and idempotent; description adds irreversible deletion, cascading effect on promo codes, and specific error handling. No contradiction.
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 key actions, clearly structured with Args/Returns, and concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the return value and error cases. For a delete tool, it is complete and informative.
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 explains `store_id` and `promo_rule_id` but omits the optional `account` parameter. With 0% schema coverage, more detailed parameter documentation would be beneficial.
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 specifies the tool deletes a promo rule and all associated promo codes permanently. It distinguishes from `update_promo_rule` by offering an alternative for disabling without deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs. `update_promo_rule` (enabled=false to disable). Also mentions irreversible nature and 404 error for invalid IDs, guiding the agent on expected behavior.
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?
The description is consistent with annotations (readOnlyHint=true) and adds useful behavioral context about hashing the email. It does not contradict any annotations and provides transparency beyond the core metadata.
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: a brief purpose statement, followed by a detailed paragraph, then Args and Returns sections. No unnecessary words, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (JSON with removed subscriber details), the description adequately covers the tool's purpose, parameters, and retrieval mechanism. It is complete for a simple get 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?
The description adds meaning for two of three parameters (workflow_id and email_address) with clear explanations in the Args section. The optional account parameter is not documented, but the schema provides its structure. Since schema coverage is 0%, the description compensates well for most params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single subscriber removed from a classic automation workflow.' It uses a specific verb and resource, and distinguishes from siblings like list_automation_removed_subscribers and remove_automation_subscriber.
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 explains when to use this tool (to retrieve details of a specific removed subscriber) and how it works (hashing the email). It does not explicitly mention alternatives, but the sibling list tool is obvious from context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds value by detailing the return fields (feedback_id, message, is_complete, etc.), which goes beyond what annotations provide. No contradictory or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, usage guidance, then parameter descriptions, and return fields. Every sentence serves a purpose with no redundancy.
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 low complexity (single read operation), the description fully covers how to obtain required parameters, what the tool does, and what it returns. The output schema is described in detail, and sibling tools provide context for discoverability. No gaps detected.
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%, but the description adds meaning for two required parameters: campaign_id ('Obtain from list_campaigns') and feedback_id ('Obtain from list_campaign_feedback'). The optional 'account' parameter is not described, but it is likely seldom needed. The descriptions enhance understanding beyond the schema titles.
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 verb 'Retrieve' and the resource 'a single team feedback comment on a campaign.' It also distinguishes from sibling 'list_campaign_feedback' by noting it is for discovering feedback IDs, making the purpose clear and specific.
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 clear context for when to use this tool (to read one collaboration comment) and explicitly directs users to 'list_campaign_feedback' for discovering feedback IDs. It also advises obtaining campaign_id from 'list_campaigns', offering practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that data is aggregated from IP geolocation at open time and only for sent campaigns, which is useful context beyond annotations.
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 overview, usage guidance, parameter docstring, and return description. Concise with no unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool, it covers all aspects: purpose, usage, parameters, output structure, and limitations (only sent campaigns). Output schema exists and description explains the JSON structure.
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?
Despite 0% schema description coverage, the docstring explains each parameter (campaign_id, count, offset) with types and defaults, plus return format. Missing 'account' parameter but overall adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves geographic open data for a sent campaign, broken down by country and region. It uses specific verbs ('Retrieve') and resources, and distinguishes from sibling tool 'get_domain_performance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (mapping opens for follow-ups, timezone-aware sending, audits) and when not to (use get_domain_performance for provider stats). Also states it only works for sent campaigns.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that tool only works for sent campaigns with eepurl tracking enabled, and describes return structure without contradicting annotations.
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?
Description is three short paragraphs: summary, usage guidance, then args/returns. Concise and front-loaded with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, parameter semantics, preconditions, and return structure. Output schema exists for return values, so description completes the picture. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains campaign_id with example and constraint ('Must be a sent campaign'). For account param, no additional details are given, but it is optional and likely not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves social sharing stats for a campaign's eepurl (Mailchimp's short-URL share link). It distinguishes from get_campaign_click_details, which is for in-email link clicks.
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?
Provides explicit when to use (measure social sharing via 'Share this' link), when not to use (use get_campaign_click_details for in-email clicks), and precondition (only works for sent campaigns with eepurl tracking enabled).
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?
Annotations already declare read-only, non-destructive. Description adds that it returns empty if no events and describes return structure, complementing annotations without contradiction.
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?
Concise one-sentence purpose followed by usage guidance, parameter docs, return type, and example. Well-structured with no fluff.
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 low schema coverage and availability of output schema in description, the description fully covers purpose, parameters, return structure, and usage context – comprehensive for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description documents list_id, email_address, and count with context (e.g., list_id from list_audiences, email must exist, count default 20). However, account parameter is present in schema but not described in args; slight gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve custom API-triggered events for a specific member', distinguishing from get_member_activity which is for email engagement. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (custom application events) and when not (email interactions) and directs to get_member_activity as alternative. Also notes empty return if no events.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds behavioral context by describing the return structure (JSON with email_address, total_items, tags) and provides an example. No contradictions. Slight gap: doesn't mention that it's a read operation, but annotations cover that. With annotations, bar is lower; description adds value beyond them.
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: one-line purpose, usage guideline, args list, returns, and example. Every sentence adds value, no fluff. Front-loaded with the main action. Highly concise yet comprehensive.
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 presence of output schema (though not shown), the description explains the return format thoroughly. It also places this tool in context of related operations. The sibling list is large, but description distinguishes clearly. For a read tool with good annotations, it provides everything needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden for parameter meaning. It explains list_id (including how to obtain it), email_address, and count (with range and default). However, it omits the 'account' parameter present in schema. For 4 params, it covers 3 well, which is a high value-add. Score 4 due to slight incompleteness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all tags for a specific member. It distinguishes from siblings like 'tag_member' (add/remove) and 'list_segments' (all available tags), providing clear purpose and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to see which tags a member has before modifying them.' and recommends alternatives ('Use tag_member to add or remove tags. Use list_segments to see all available tags/segments.'). Gives clear guidance on when and why to use this tool.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the return fields and example, but does not contradict annotations or reveal additional behavioral traits beyond what's implied by 'retrieve'.
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?
Description is concise: two paragraphs and an example. Purpose and usage front-loaded. Every sentence adds value; no filler.
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?
With output schema present, description still fully explains return fields (id, name, member_count, type, timestamps, options) and provides a realistic example. All context needed for correct invocation and interpretation is covered.
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 description bears full burden. It explains list_id (Mailchimp audience ID format, source) and segment_id (numeric string, source) with examples. However, the optional 'account' parameter is not mentioned, missing coverage for one of three parameters.
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 retrieving full segment details, including member count and filter conditions. It explicitly distinguishes from list_segments (browse all) and list_segment_members (view individuals).
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 when-to-use guidance ('inspect a segment’s conditions or verify its type and member count') and when-not-to-use alternatives ('Use list_segments to browse... Use list_segment_members to see...').
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?
Annotations already declare readOnlyHint=true. Description adds useful error info (404 for invalid ID), but no additional behavioral traits beyond that.
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?
Well-structured with sections, but slightly verbose; every sentence is valuable though, so minor deduction.
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?
Covers purpose, usage, parameters, return fields (with output schema), errors, and context, making it fully complete for this simple read 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 coverage is 0%, but description explains the only parameter (template_id) with format and source (list_templates), adding complete semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves template metadata without HTML content, and distinguishes from get_template_default_content and list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (inspect settings, verify existence) and when to use alternatives (get_template_default_content for HTML, list_templates for browsing IDs).
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it makes no network call, never returns API keys, and specifies the return format, providing value beyond annotations.
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?
Description is well-structured, concise, and front-loaded with purpose. Each sentence adds value without redundancy.
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 it's a simple listing tool with no params and an output schema, the description is complete: covers purpose, usage, behavior, and return format thoroughly.
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?
Input schema has zero parameters, so schema coverage is 100%. Description does not need to add parameter info, and baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists configured Mailchimp accounts, distinguishes from get_account_info (live stats), and explains its role in discovering account names for other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool to discover account names, and directs to get_account_info for live stats. Also explains multi-account setup with environment variables.
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?
Discloses ordering by creation date descending, exclusion of Journeys due to API limitations, and return structure. Adds significant context beyond annotations (readOnlyHint=true) without contradiction.
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?
Efficiently front-loaded with purpose, then scope clarification, alternatives, concise Args, and Returns section. Every sentence adds value without redundancy.
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?
Comprehensive: explains ordering, API limitations, alternatives, pagination, and return JSON shape with key fields. Sufficient for a list tool with output schema.
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?
Adds meaning for count (range and default) and offset (pagination usage) via Args section, compensating for 0% schema coverage. However, the 'account' parameter is not described, leaving one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists Classic Automation workflows, including status and send counts. Explicitly distinguishes from Customer Journeys and siblings like get_automation_emails and search_automation_campaigns.
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?
Provides explicit when-to-use (Classic Automations) and when-not-to-use (Customer Journeys) with clear alternatives: search_automation_campaigns, get_automation_emails, get_automation_summary.
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?
Annotations already declare readOnlyHint=true, but description adds context: returns empty array if no folders exist, pagination details, and non-destructive nature. No contradiction.
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?
Concise and well-structured: front-loaded purpose, then clarifying sentence, followed by bulleted Args and Returns. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, but description still summarizes return format (total_items, folders array with id, name, count). Given sibling count and no output schema details, this is complete and sufficient.
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 explains count (1-1000, default 50) and offset (pagination) with usage context. However, the 'account' parameter is not explained. Schema coverage is 0%, so description compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'campaign folders'. It explicitly distinguishes from sibling tools by stating 'Do not use to find campaigns; use list_campaigns or search_campaigns instead.'
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 when-not-to-use guidance: 'Do not use to find campaigns; use list_campaigns or search_campaigns instead.' It also clarifies that folders are organizational only, no behavioral impact.
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?
Annotations already set readOnlyHint=true, so description reinforces safe read. It adds value by detailing the return JSON structure (total_items, categories with id, title, type, list_id). No contradictions.
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?
Concise two-paragraph structure with no redundant sentences. Parameter explanations are bulleted, return format is clear. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple listing nature, annotations present, and output schema exists, description covers all essential aspects: purpose, parameters, return structure, pagination, and relation to siblings. No 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?
Description explains list_id format and source, count range and default, offset pagination use. Account parameter is omitted (optional with null default), but coverage is high. Schema descriptions are absent (0% coverage), so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists interest categories for an audience, showing titles and form types. It explicitly differentiates from sibling list_interests and mentions create_interest_category for adding, ensuring 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use to discover category IDs, then list_interests for options; use create_interest_category to add new categories. Also explains how to obtain list_id from list_audiences, giving clear context.
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?
Annotations indicate readOnlyHint=true, and the description confirms it lists data. It adds behavioral context: returns 404 for invalid category_id and describes the return structure. No contradictions. Does not repeat annotation info verbatim but adds useful 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?
Concise but thorough: a summary sentence, usage guidance, error note, and clearly labeled Args and Returns sections. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately describes the return format (JSON with total_items and interests array, each interest's fields). It provides context with sibling tools and error behavior. Minor omission: the 'account' parameter is not explained, but overall complete for intended use.
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 schema coverage at 0%, the description explains the purpose and source for list_id and category_id, and details count and offset parameters including defaults and pagination. Only the 'account' parameter is not explained, but the rest are well-covered, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists interest options within a category with subscriber counts. It distinguishes from associated tools like list_interest_categories and add_member/update_member, specifying that this tool's output is needed for setting member preferences.
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?
Explicit guidance: use after list_interest_categories to see individual options. It advises not to use for managing member preferences directly and notes that interest IDs are needed for add_member/update_member. Also describes error behavior for invalid category_id.
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?
Annotations already declare readOnlyHint=true. The description adds details on pagination, return structure, and example output, which enhances transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, usage, args, returns, and example. Slightly verbose but front-loaded and each section earns its place.
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?
Comprehensive: covers purpose, usage guidelines, parameter details, return structure, integration with sibling tools, and an example. Nothing essential is missing given the output schema existence.
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?
Despite schema coverage being 0%, the description's Args section explains the purpose and example values for each parameter (list_id, segment_id, count, offset), and the account parameter is noted as optional. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists members of a specific segment or tag, and distinguishes itself from sibling tools list_audience_members and get_segment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('to see who is in a segment') and provides alternatives: use list_audience_members for full audience, get_segment for metadata and count first.
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?
The description fully aligns with annotations (readOnlyHint=true) and adds behavioral context such as pagination parameters (count max 1000, offset for skipping) and return format. No side effects are expected, and the description accurately reflects 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 concise with a clear structure: purpose, usage context, parameter list, and return format. Every sentence provides useful information without redundancy.
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?
The description covers all necessary aspects: purpose, parameters, return type, and usage context. The schema annotations provide full read-only safety, and the output is described. For a listing tool with a well-defined input and output, this is 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 description adds significant meaning to 4 out of 5 parameters: explains store_id source (list_ecommerce_stores), order_id purpose, count limits, and offset for pagination. One parameter (account) is not described, but overall coverage is high and the existing descriptions add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the line items of a single e-commerce order' with a specific verb and resource. It distinguishes from sibling tools like create_store_order_line, delete_store_order_line, and get_store_order_line, as well as other order-related tools.
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 explains when to use the tool ('review the individual products, quantities, and prices attached to an order') and provides context about manual vs automated commerce integrations. However, it does not explicitly give alternatives or when not to use it, but the context is clear.
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?
Annotations indicate mutating but not destructive. Description adds significant behavioral details: queue preserved, new subscribers enter but no emails, reversible, and error states. No contradiction with annotations.
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?
Concise with a clear structure: single-sentence purpose, behavioral note, Args section, Returns section. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description adequately covers purpose, usage, parameters, and return format. Complete for a pause action.
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?
For the required 'automation_id', description provides an example and source ('e.g. 'auto123'. Obtain from list_automations.'), adding value beyond the raw schema. Optional 'account' param is not described, but coverage is 0%, so partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it pauses an automation workflow, stopping delivery while preserving the queue. Distinguishes from 'start_automation' and sibling 'pause_automation_email' is listed, making the specific resource clear.
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?
Provides clear context on when to use (pause automation) and behavior (queue preserved, subscribers resume on start_automation). Mentions error conditions (already paused, draft status). However, does not explicitly contrast with 'pause_automation_email'.
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?
Describes idempotence (aligns with idempotentHint) and error handling, adding value beyond annotations. No contradictions.
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?
Concise with clear sections (Args, Returns) and front-loaded main purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly covers behavior, parameter source, error codes, and return format. Output schema further aids understanding.
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?
Adds meaning for page_id by specifying it's obtained from list_landing_pages. Account parameter not mentioned, but overall good context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'publish' and resource 'landing page', distinguishing it from siblings like unpublish_landing_page and get_landing_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternatives (unpublish_landing_page for taking offline, get_landing_page for confirmation) and mentions error conditions (400, 404) that help determine prerequisites.
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?
Discloses that the new campaign is created in 'save' (draft) status, lists return fields, and provides an example. Annotations are minimal (non-readOnly, non-idempotent, non-destructive), and the description adds sufficient behavioral context without contradiction.
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?
Concise yet comprehensive: starts with a clear purpose, then usage guidance, parameters, return format, and example. Every sentence adds value, and the structure is logical and easy to parse.
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 it has an output schema and annotations, the description fully covers what the agent needs: how to use, what to expect in return, and how to obtain required inputs. The missing account description is minor as it's optional and defaults to null.
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 'Args' section describes campaign_id with source and example, but the optional 'account' parameter is not explained. With 0% schema coverage, the description should cover all parameters, but it leaves one undocumented, reducing helpfulness for the agent.
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 first sentence clearly states the tool clones a campaign into a new draft with identical settings, recipients, and content. It distinguishes from create_campaign and update_campaign, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (reuse successful campaign) and provides alternatives: create_campaign for from-scratch builds, update_campaign and set_campaign_content for modifications after cloning. Also notes it works on any campaign status.
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?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds specific behavioral context: it activates delivery, and returns errors if the automation is already sending or in draft status. This builds on annotations without contradicting them.
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 efficient with 6 sentences, starting with the main purpose, then usage guidance, parameter explanation, return format, and an example. No wasted words; front-loaded key 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 tool's moderate complexity and the presence of an output schema, the description fully covers prerequisites (obtain automation_id from list_automations), expected behavior, error conditions, and return format. The example solidifies understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides a clear explanation for automation_id ('The automation workflow ID (e.g. 'auto123'). Obtain from list_automations.'), adding value beyond the schema's title and type. However, the optional account parameter is not described, leaving a gap.
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 'Start or resume' and the resource 'automation workflow', specifying the action 'activating delivery to queued subscribers'. It distinguishes itself from sibling tools like pause_automation and list_automations by mentioning them, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('activate a new automation or resume a paused one') and provides alternatives: 'Use pause_automation to temporarily stop. Use list_automations to check current status.' This gives clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, non-idempotent, non-destructive. The description adds key behavioral context: side effect of immediate email sending, required subscription, and error handling for missing subscription or invalid step. It does not contradict annotations and enriches the safety profile for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, followed by side effect, prerequisites, alternatives, error info, and parameter details. It is concise but covers all key aspects. Minor redundancy (subscription requirement repeated) and missing account param prevent a top score.
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 and good annotations, the description covers purpose, usage context, parameter details, errors, and side effects. It lacks description of the optional 'account' parameter and does not mention potential rate limits or permissions, but is otherwise comprehensive for a 4-parameter 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 useful semantics for the three required parameters (journey_id, step_id, email_address), including how to find journey IDs, valid step types, and subscription requirement. However, the optional 'account' parameter is not mentioned, leaving a gap for that parameter.
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 triggers a contact into a specific step of a Customer Journey workflow. It uses a specific verb ('Trigger') and resource ('contact into a step of a Customer Journey') and distinguishes from siblings by explicitly naming alternatives: 'start_automation' for Classic Automations and 'send_campaign'/'create_campaign' for one-time 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 when-to-use and when-not-to-use guidance, including prerequisites (contact must be subscribed), side effects (emails start immediately), alternative tools (list_automations, start_automation, send_campaign, create_campaign), and error conditions (not subscribed, invalid step). This gives an agent clear decision criteria.
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?
Annotations are minimal but not contradicted. Description adds what happens (URL stops serving), error handling (404 for invalid page_id), and reversibility. Provides context beyond annotations.
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: purpose statement, reversibility note, error handling, then clearly labeled Args and Returns. Every sentence adds value without redundancy.
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 low complexity (2 params, 1 required, output schema exists), description covers purpose, usage, parameters, error case, and return format. Complete for agent's needs.
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 has 0% description coverage. Description explains page_id: 'Landing page ID to unpublish. Obtain from list_landing_pages.' Adds meaning beyond schema. Account parameter has no description but is optional with default null, so minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Take a published landing page offline' with the specific resource (published landing page). It distinguishes from sibling tools like delete_landing_page and publish_landing_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to unpublish a published page) and when not to (use delete_landing_page for permanent removal). Also notes reversibility via publish_landing_page.
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?
Discloses that the operation transitions the status from 'schedule' to draft, only works on scheduled campaigns, returns an error otherwise, and provides the return format along with an error scenario. This adds significant value beyond the annotations which merely indicate non-readonly and non-idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 150 words, well-structured with clear sections (use case, args, returns, example), and front-loads the core purpose. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects, has output schema), the description covers all essential aspects: purpose, preconditions, postconditions, error handling, parameter details, and return format. The example validates the expected behavior. No gaps detected.
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 explains the 'campaign_id' parameter with type, example, and validity constraints, compensating for the schema's 0% coverage. However, it omits any mention of the optional 'account' parameter, leaving a gap. For low coverage, this is partially helpful but incomplete.
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 ('Cancel'), resource ('scheduled campaign send'), and outcome ('returning it to draft status for editing'). It distinguishes this tool from siblings like schedule_campaign, send_campaign, and pause_rss_campaign by specifying the exact action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use to cancel a scheduled send before it goes out'), when not to use ('returns error for drafts or sent campaigns'), prerequisite ('Only works on campaigns in 'schedule' status'), and provides a method to obtain valid campaign IDs ('Obtain from list_campaigns(status='schedule')'). Also mentions post-unscheduling steps.
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?
Annotations already indicate non-read-only, non-destructive, but description adds that it preserves history, is reversible, and returns 404 on missing member. Adds useful context beyond annotations.
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?
Six sentences covering purpose, reversibility, alternatives, error condition, and parameters in bullet points. No wasted words, well-structured.
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 context (annotations, output schema described, sibling tools), the description covers behavior, parameters, return format, error handling, and usage guidance comprehensively.
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 has 0% coverage, but description provides detailed semantics for list_id (10-char alphanumeric, example, how to obtain) and email_address (valid email, must exist). However, the optional 'account' parameter is not described, so not fully 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?
Description clearly states the tool unsubscribes a member from an audience while preserving profile and history. It distinguishes from siblings like delete_member (permanent removal) and update_member (reversible), making the purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (unsubscribe), when to use alternatives (delete_member for GDPR, update_member to reverse), and notes the 404 error condition for non-existent members.
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?
Description adds behavioral context beyond annotations: partial update behavior ('Only provided fields are changed'), error condition (404 for invalid page_id), and lists return fields. Annotations already indicate non-read-only and non-idempotent. Missing concurrency or rate limit info, but overall good 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?
Very concise: first sentence summarizes, then constraints, alternatives, error, Args list, Returns. Front-loaded and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param tool with 1 required, 0% schema coverage, and output schema present, the description covers all parameters, output, errors, and immutability constraints. It is fully adequate for an agent to use this tool correctly.
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 coverage, description provides brief but clear parameter descriptions (e.g., 'New internal name' for name, 'Landing page ID. Obtain from list_landing_pages' for page_id). Could explicitly state that null means skip, but the phrase 'Only provided fields are changed' implies this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update settings of an existing landing page' with specific verb and resource. It explicitly distinguishes from siblings like create_landing_page, delete_landing_page, publish/unpublish_landing_page, and get_landing_page by noting immutable fields and alternatives for live status changes.
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?
Provides explicit when-to-use (updating settings), when-not-to-use (changing list_id/template, changing live status), and alternatives (publish/unpublish, create new page). Also advises inspecting current settings with get_landing_page before updating.
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?
Description discloses that it replaces the entire note body, returns 404 if note/member doesn't exist, and returns JSON with fields. Annotations are neutral. Missing details on idempotency or concurrency, but overall good.
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?
Concise and well-structured: purpose, usage guidance, args, returns. No redundant 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 output schema is described, annotations are basic, description covers prerequisites, behavior, error handling, and return format. Fully complete for the 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?
Description explains all required parameters (list_id, email_address, note_id, note) with sources and max length. However, it omits the optional 'account' parameter from the schema, which lacks description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates the text of an existing member note, replacing the entire note body. It differentiates from sibling tools like add_member_note (create) and delete_member_note (remove).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: use add_member_note to create, delete_member_note to remove, and list_member_notes to find note_ids. Also provides prerequisites for obtaining IDs.
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?
Annotations already declare idempotentHint=true and readOnlyHint=false. The description adds behavioral context: only provided fields are updated, idempotent reapplication, cannot change segment type, and error handling for invalid segment_id. No contradiction.
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: core purpose first, then behavioral details, error info, and bulleted arg descriptions. Concise without redundancy. Front-loaded with the key action.
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 6 parameters (2 required) and the existence of an output schema, the description covers all relevant behaviors, constraints, error cases, and return values. It complements the schema and output schema well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden. It explains list_id, segment_id, name, match, and conditions_json with examples and constraints. However, it does not describe the 'account' parameter present in schema, leaving a small gap.
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 'Update a segment's name or dynamic filter conditions,' specifying the resource (segment) and the actions. It distinguishes from siblings like create_segment, delete_segment, and membership management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (update segment) and when not to (for static membership, use add_members_to_segment or remove_members_from_segment). Also explains constraints such as cannot change static/dynamic type and that match must be provided with conditions_json.
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?
Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. Description adds that file_data must be base64-encoded (not URL or raw bytes) and explains folder_id usage. No contradictions.
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: summary, usage advice, Args list, Returns list. Each sentence adds value. No fluff.
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?
Covers all parameters, provides return value details (id, full_size_url, etc.), and gives usage context for campaign/template content. Output schema exists but description still explains return fields. Sibling tools are many but tool is well-differentiated.
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%, but description explains name (extension, shown in File Manager), file_data (base64-encoded), and folder_id (optional, from list_file_folders). Missing account parameter (not described) but covers 3 of 4 well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'upload', resource 'image or file', and context 'File Manager (base64-encoded)'. Distinguishes itself from siblings like list_files, delete_file, and list_file_folders by mentioning their use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for programmatic image hosting in campaigns/templates. Provides alternatives: use list_file_folders to target a folder, list_files to browse, delete_file to remove. Gives clear context.
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?
Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) are consistent. The description adds valuable context: a side effect (status='pending' triggers double opt-in email) and an error condition ('Member Exists' if duplicate). It doesn't cover auth or rate limits, but the added details go beyond annotations.
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: a concise one-line summary, then an overview, a sibling tool comparison, a detailed Args section, and a Returns section. Every sentence contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 2 required, and an output schema, the description covers all essential aspects: purpose, usage, parameters, return values, errors, side effects, and sibling distinctions. No significant gaps remain.
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%, but the description fully explains each parameter (list_id format, email requirement, status options with defaults, first/last name as merge fields, tags as comma-separated). This adds significant meaning beyond the raw schema types.
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 starts with a clear action ('Add a new member') and resource ('to an audience'), and explains it creates a new contact. It distinguishes from siblings like update_member, tag_member, etc., satisfying the specific verb+resource+differentiation criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists alternative tools (update_member, tag_member, batch_subscribe, unsubscribe_member, delete_member) and when to use each. This provides excellent guidance on choosing the right tool.
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?
The description adds significant context beyond annotations: it notes that subscriber associations are removed but subscribers themselves are unaffected, and mentions error handling for non-existent categories. Annotations already indicate destructiveHint=true, but description enriches understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: action statement, effects, alternatives, param definitions, return format, and example. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, effects, parameter sourcing, return type, and error case. Minor omission of the optional 'account' parameter, but overall provides sufficient context for correct tool invocation.
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 explains the required parameters list_id and category_id with type examples and provenance (e.g., 'Obtain from list_audiences'). However, the optional 'account' parameter is not mentioned, leaving a gap despite schema coverage being 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete an interest category and all its interest options at once.' It distinguishes from sibling tool delete_interest by specifying the scope (entire category vs single option). The verb-resource pairing 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives when-to-use vs alternatives: 'Use delete_interest instead to remove a single option while keeping the category.' Also advises using list_interest_categories to find IDs, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: includes abandoned carts, returns 404 for invalid store_id. Annotations already declare readOnlyHint=true and non-destructive, so description complements well.
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?
Efficiently structured: first sentence states purpose, then context, comparisons, Args, Returns. Every sentence adds value without redundancy.
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?
Complete for a read-only list tool with 4 parameters. Provides return shape in detail, with output schema already present. Covers all necessary information.
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?
Despite 0% schema description coverage, the Args section fully documents all parameters: store_id (with source from list_ecommerce_stores), count (default and range), offset. This compensates completely.
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: 'List carts for a store, including abandoned ones, with customer and total info.' It distinguishes from siblings like get_store_cart and list_store_orders by specifying scope and use case.
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?
Explicit guidance provided: 'Use for abandoned-cart workflows... Use get_store_cart for a single cart with line items. Use list_store_orders for completed purchases.' Also notes error condition for invalid store_id.
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?
Beyond annotations (readOnlyHint=true), the description adds valuable context: it explains that the tool filters /campaigns, describes the return structure (JSON with total_items and campaigns array), and states the limitation regarding Customer Journeys. This fully discloses behavior and purpose.
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: it opens with the core purpose, then provides context, usage guidance, parameter details, and return information. Every sentence serves a distinct purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, annotations, and an output schema, the description covers purpose, usage, and most parameters thoroughly. However, the missing 'account' parameter documentation reduces completeness slightly. Overall, it is highly informative.
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 documents most parameters (count, offset, list_id, status, since_send_time, before_send_time) with their meanings and defaults, adding significant value beyond the schema. However, it omits the 'account' parameter present in the schema, leaving a gap in coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List campaigns originated by an automation or a Customer Journey (campaign type='automation')', providing a clear verb+resource. It distinguishes from siblings by referencing list_automations and list_campaigns, ensuring the agent understands its specific niche.
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: 'most practical workaround for the lack of a public Customer Journeys read API.' It also specifies alternatives: 'Use list_automations for Classic-only metadata' and 'Use list_campaigns for the full campaign feed.' This clearly helps in tool selection.
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?
Annotations declare readOnlyHint=true, idempotentHint=false, destructiveHint=false. Description adds details on fuzzy vs exact matching, result ordering (exact first), query constraints (min 3 chars), and response structure. No contradictions.
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?
Description is well-structured: concise summary, usage guidelines, parameter descriptions, return format, and an example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are partially covered. Description includes main use case, parameters, and example, but misses documenting the account parameter, which is a minor gap.
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 description must explain parameters. It details query (min 3 chars, exact vs fuzzy) and list_id (optional, from list_audiences), but does not mention the account parameter, leaving it undocumented.
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 function: searching for members across all audiences by email or name, returning exact and fuzzy matches. It distinguishes from siblings like list_audience_members and get_member_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (looking for a specific person, unknown audience) and when to use alternatives (list_audience_members for browsing, get_member_activity/tags after finding member). Provides clear guidance.
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?
Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds critical behavioral traits: changes apply only to newly created campaigns (no retroactive effect) and only provided fields are updated (partial update). This provides valuable context that annotations alone cannot convey.
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 brief yet comprehensive, front-loading the purpose and behavioral notes, then listing parameters with clear explanations and a Returns section. Every sentence adds value, avoiding redundancy or fluff. The structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (1 required) and an output schema (though not detailed in context description), the description covers the key behavior (partial update, effect on new campaigns) and parameter semantics thoroughly. It also references a related tool (get_audience_details) for completeness. For a moderately complex update tool, this is fully adequate.
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 input schema has 0% description coverage, but the description explains each parameter in detail: list_id format and source, length limits for subject, verification requirement for from_email, and explains permission_reminder as required by CAN-SPAM. This adds substantial meaning beyond the schema, fully compensating for the lack of schema descriptions.
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 updates audience-level settings (name, default sender, subject, permission reminder) and distinguishes between updating audience settings versus checking them (get_audience_details). It also clarifies the scope (affects only new campaigns), making the purpose very specific and distinct from sibling tools like update_campaign.
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 guidance on when to use this tool by suggesting to use get_audience_details to check current settings first. It implies this tool is for updating settings, not for reading. However, it does not explicitly list when not to use it or direct to alternatives for other types of updates (e.g., campaign-level settings), which prevents a perfect score.
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?
Discloses side effect of creating a billable audience, error conditions, and return values. Annotations are minimal but consistent; description adds substantial behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, side effect, error info, args list, and returns. Front-loaded with key info. Slightly verbose but necessary details; could be more concise but still clear.
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 16 parameters (12 required), description covers all params, errors, return values, side effects, and sibling tools. No gaps for an AI agent to use correctly.
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 has 0% description coverage, but description provides detailed explanations for all 16 parameters, including constraints (max length, format) and defaults, fully compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new audience (list)' and distinguishes from siblings like update_audience, delete_audience, and list_audiences, providing specific verb+resource and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (create), mentions side effect (billable), error condition (400 if missing fields or plan limit), and names alternatives (update_audience, delete_audience, list_audiences) for different needs.
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?
Annotations readOnlyHint=false, idempotentHint=false, destructiveHint=false are consistent with a creation tool. The description adds further transparency: the page is created unpublished, status will be 'unpublished', URL null until published, and tracking defaults (true). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidance, error info, parameter details, and returns. It is comprehensive but slightly long; however, every sentence adds value. Could be tightened slightly but still efficient.
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 9 parameters and an existing output schema, the description is complete. It covers creation flow, lifecycle (draft->publish), dependencies on template_id and list_id, optional store linkage, and expects return fields (id, status, url). No gaps.
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%, but the description compensates fully by explaining each parameter in the Args section: name (internal name), title (browser tab), list_id (audience ID, with source), template_id (with source), store_id (optional, with source), description (optional), tracking_opens and tracking_clicks (defaults). It adds meaning beyond raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new landing page in draft status from a template, optionally linked to a store.' It clearly identifies the verb (create), resource (landing page), and key constraints (draft, from template, optional store link). It distinguishes from siblings like update_landing_page and publish_landing_page.
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: 'Use update_landing_page to edit settings or publish_landing_page to make it live' and 'Use list_landing_pages or get_landing_page to inspect existing pages.' It also mentions error conditions (400 for invalid template_id or list_id), helping the agent decide when to use this tool.
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?
Annotations declare destructiveHint=true and idempotentHint=true. Description adds side effects ('removes every member and historical data'), irreversibility, error case (404 if list_id not found), and idempotent behavior (delete already deleted returns error). Goes beyond annotations.
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?
Very concise and well-structured: first sentence states action and scope, then side effect, alternative, backup advice, error info, and finally Args/Returns sections. No wasted words, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the description covers prerequisites (list_id from list_audiences), side effects (cascading deletion), error handling (404), return format (JSON with status), and alternatives. Combined with annotations and output schema, it is fully complete for an AI agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the required list_id parameter with format ('10-char alphanumeric'), example, source (list_audiences), and caution. The optional account parameter is not described, but it is optional and defaults to null; the main parameter is well-covered.
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 begins with 'Permanently delete an audience and all its members, segments, campaigns, and stats', which is a specific verb and resource with scope. It distinguishes from sibling delete tools by detailing cascading effects and from update_audience by noting it is for archiving. Purpose is crystal clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (permanent deletion) and when not to, advising alternative tools like update_audience and listing backup steps with list_audience_members. Also notes prerequisite: obtain list_id from list_audiences.
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?
Describes permanent data loss of activity history, merge fields, tags. Annotations already indicate destructive nature; description adds specific context without contradiction.
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 sections: summary, usage, args, returns, example. Concise yet comprehensive, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all needed aspects: purpose, usage, behavior, parameters, returns with example. Output schema not shown but description explains return fields. Complete for a simple delete 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?
Provides clear explanations for list_id and email_address including format and requirements. However, misses the optional 'account' parameter. Schema coverage is 0%, so description compensates well but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it permanently deletes a member and all data. Distinguishes from sibling tools like unsubscribe_member and delete_member_permanent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (complete data removal, GDPR) and when not (use unsubscribe_member). Also explains no undo and how to get list_id.
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?
Adds value beyond annotations by detailing irreversibility, data deletion, prevention of re-import, and HTTP 204 response. No contradictions with annotations.
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?
Concise, front-loaded with purpose, uses caps for emphasis, structured with Args and Returns. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, parameters, return value, and usage alternatives. Given the annotations and schema, no 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?
Despite 0% schema description coverage, the description explains list_id format and source, and notes email_address hash derivation. Account is optional and not explained, but the two required params are well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states permanent deletion of audience member with GDPR-style wording. Distinguishes from delete_member (equivalent) and unsubscribe_member (alternative for non-permanent action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (permanent deletion) and when not to use (use unsubscribe_member to keep member for reporting). Also notes equivalence with delete_member.
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?
The description adds significant behavioral context beyond the annotations. It explicitly states that all stored data is permanently lost, aligning with destructiveHint:true. It also discloses that default fields will return an error, which is not in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, gives usage guidance, explains parameters, describes return value, and provides an example. Every sentence adds value, and it is front-loaded with the most important 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?
For a delete operation, the description is complete. It covers the action, input parameters, constraints, return value format, and an example. Given the output schema is described in text and the sibling tools list, no additional context is needed.
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?
Although the schema has 0% description coverage, the description provides clear semantics for both required parameters: list_id (with example and source) and merge_id (with type, source, and constraint). The 'account' parameter is not explained, but it is optional and likely not needed, so the description compensates well for the key params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a custom merge field and all its stored data from an audience.' This is a specific verb+resource combination that distinguishes it from sibling tools like update_merge_field or create_merge_field. It also specifies that default fields cannot be deleted.
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 includes explicit usage guidance: 'Use only when you no longer need the field.' It warns that default fields cannot be deleted and will return an error, and it advises using list_merge_fields to find merge_id values. This clearly tells when and when not to use the tool.
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?
Adds value beyond annotations by describing irreversibility, cascading deletion of variants, and the need for verification, which aligns with destructiveHint=true.
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?
Concise, with a clear structure: purpose, cautionary notes, Args, Returns. No redundant 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?
Provides sufficient information for a destructive tool, including irreversibility, scope, return value, and parameter details for required fields.
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?
Documents the two required parameters (store_id, product_id) with brief but clear descriptions, but omits the optional 'account' parameter, which is not explained in the schema either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Permanently delete a product and all of its variants from a store,' using a specific verb and resource, and distinguishing it from sibling tools like delete_store_product_variant.
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?
Includes explicit warnings: 'This cannot be undone,' 'Verify the product_id before calling,' implying cautious use, and contrasting with alternatives like delete_store_product_variant.
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?
Describes return fields, error conditions, and aligns with annotations (readOnlyHint). Provides full 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?
Well-structured with purpose, usage, args, and returns sections. No superfluous content.
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?
Covers all aspects: purpose, parameters, return schema, and error behavior. Even with high sibling count, it is 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?
Adds detailed descriptions for list_id and report_id (including format and source), though the optional 'account' parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a single abuse report for an audience, distinguishing from sibling list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus list_audience_abuse_reports, including how to obtain report_id.
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?
Annotations already show readOnlyHint=true; description adds valuable behavioral details: return format (total_items, locations array with country, cc, percent, total), pagination (offset when total_items exceeds count), and default count. No contradictions.
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?
Concise and well-structured: purpose sentence, usage guidance, then Args and Returns sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no nested objects, output schema), the description fully covers behavior, constraints, and return structure, enabling confident 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?
Schema coverage is 0%, but description explains list_id format and source, count range (1-1000) and default, offset usage. However, it omits the optional 'account' parameter, leaving a minor gap for a non-essential field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List the top geographic locations (countries) of an audience's members', defining verb and resource. Explicitly distinguishes from sibling get_campaign_locations for single campaign opens, ensuring differentiation.
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?
Provides explicit when-to-use ('regional targeting or reporting') and when-not-to-use ('Use get_campaign_locations for the geographic breakdown of a single campaign's opens instead'), giving clear context and alternatives.
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?
Beyond annotations (readOnlyHint=true), the description states 'Read-only, safe to retry' and explains the internal behavior: combining two API calls with details on each. No contradiction with annotations.
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-organized: front-loaded purpose, then internal mechanics, usage context, safety note, parameter explanation, and return structure. Every sentence adds value without redundancy.
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 presence of output schema, sibling tools, and annotations, the description provides complete context: what it does, when to use, how it works, safety, parameter details, and return format. No gaps for an audit-focused 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?
Despite 0% schema description coverage, the description adds meaning for the 'days' parameter (lookback window, 1-365 range, default 30) and explains the return structure. However, the 'account' parameter is not mentioned in the description, leaving its purpose unclear.
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 summarizes automation activity across Classic Automations and Customer Journeys, combining two API calls. It distinguishes itself from siblings like list_automations and search_automation_campaigns by mentioning them as alternatives for raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool as the starting point for 'what's my automation stack doing right now?' during audits, and provides clear guidance on when to use siblings instead (list_automations for raw Classic list, search_automation_campaigns for raw recent feed).
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?
Discloses 404 error for invalid campaign_id and empty advice array for no suggestions, beyond annotations which already indicate read-only.
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?
Concise, well-structured with sections: purpose, usage, error cases, arguments, return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, errors, parameter semantics, and return structure. Output schema exists to detail return, so 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?
Describes campaign_id with example and constraint, but account parameter is not explained (though optional and default null). Schema has 0% coverage, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves Mailchimp's automated post-send feedback on a campaign, differentiating from siblings like get_campaign_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to surface algorithmic suggestions') and when not ('use get_campaign_report for raw metrics'), plus constraint 'only works for sent campaigns'.
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?
Annotations already mark the tool as read-only and non-destructive. The description adds substantial context: return format (JSON with campaign_id and plain_text, optional html), handling of A/B campaigns (variations array), content length caps (truncated field), error conditions (invalid ID or no content), and an example. All behaviors are disclosed transparently.
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 with a concise first sentence stating purpose, followed by usage guidelines, parameter details, return value description, and an example. Each sentence adds meaningful information without redundancy or excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only content retrieval tool, the description covers all necessary aspects: what it returns, how to identify campaigns, handling of A/B variations, truncation behavior, error cases, and an example. With an output schema present, the description does not need to detail return structure further. It is complete for the tool's 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 description explains campaign_id and include_html clearly, including their defaults and usage. However, the optional 'account' parameter (present in schema with anyOf null/string) is not mentioned. Given the schema coverage is 0%, the description should ideally cover all parameters. This omission is a minor gap, but the two main parameters are well explained.
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 starts with a clear verb and resource: 'Read the rendered body copy of a campaign (plain text, optionally HTML).' It distinguishes itself from sibling tools like get_campaign_details and get_campaign_report by specifying what each is used for, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for content audits, analysis, or repurposing'), when to use alternatives (get_campaign_details for settings, get_campaign_report for performance), and how to obtain the required campaign_id via list_campaigns or search_campaigns. This provides clear guidance without ambiguity.
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?
Annotations already indicate readOnlyHint=true; description adds return structure and error handling details, enriching behavioral understanding.
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?
Concise yet comprehensive with clearly separated sections for args, returns, and example; no redundant 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 simple tool with 2 params and output schema fully described in returns, the description covers purpose, usage, and all necessary details.
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?
Provides clear explanation and example for campaign_id, though optional 'account' parameter is not documented. Schema coverage is 0% so description compensates well for the required param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' and resource 'configuration of a specific campaign', clearly distinguishing it from similar tools like get_campaign_report and listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (inspect subject line, sender, etc.) and when not to (use get_campaign_report for post-send performance), plus guidance on finding campaign IDs.
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?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses important behavioral details: it returns both static and dynamic segments, includes member counts and types, and explains pagination with offset. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet complete, with a clear structure: a purpose statement, a usage note, explicit args with descriptions, and a return format. Every sentence adds value without redundancy.
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 presence of an output schema and the detailed explanation of returns in the description, the tool is fully described. The description covers purpose, parameters, behavior, and return structure, making it complete for an AI agent.
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 adds substantial meaning for three of four parameters: list_id (format and source), count (range and default), offset (pagination usage). The account parameter is not described, but it is optional and default null. Overall, the description compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists segments and tags for an audience with member counts and types, and explicitly distinguishes from the sibling get_segment by noting to use that for full details including filter conditions. It also mentions discovering segment IDs for campaign targeting, making the purpose precise and unique.
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 (to discover segment IDs for campaign targeting or membership management) and when to use an alternative (get_segment for full details with filter conditions). It also mentions obtaining the list_id from list_audiences, which provides a clear prerequisite.
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?
Annotations indicate destructiveHint=true, but description adds that 'emails cannot be recalled' and explains return JSON with possible errors, providing context beyond annotations.
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 for usage, args, returns, and example. Every sentence adds value without redundancy.
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?
Covers purpose, prerequisites, usage guidelines, parameter explanation, return format, and error conditions. With an output schema present, return value explanation is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains campaign_id meaning, how to obtain it, and gives an example. The optional account parameter is not mentioned, which is a minor gap.
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 'Send a campaign immediately to all targeted recipients', specifying the verb 'send' and resource 'campaign'. It distinguishes itself from sibling tools like schedule_campaign and send_test_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (immediate delivery, campaign must be in 'save' status with content set) and when to use alternatives (schedule_campaign for future, send_test_email for preview). Also mentions unschedule_campaign for campaigns in schedule status.
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?
Discloses behavioral traits beyond annotations: only works on draft status, only provided fields updated, and returns JSON structure. No contradiction with annotations.
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?
Front-loaded with purpose and constraints, followed by structured Args, Returns, and Example sections. Each part serves a purpose without unnecessary repetition.
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 (9 params, many sibling tools) and lack of schema descriptions, the description provides complete guidance on usage, parameter dependencies, constraints, return values, and an example, making it highly usable.
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?
Adds significant meaning for 8 of 9 parameters, including how to obtain IDs, dependencies (list_id required when changing segment_id), and constraints (reply_to must be verified domain). However, the 'account' parameter is not explained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates campaign settings and segment targeting, distinguishes from sibling set_campaign_content for HTML body changes, and specifies the resource (existing campaign draft) with a specific verb.
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?
Provides explicit when-to-use: before sending, only on draft campaigns, and when-not-to-use: returns error for sent/scheduled campaigns. Also suggests alternative set_campaign_content for changing HTML body.
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?
Discloses that it returns a JSON confirmation or error, and that on success the API returns an empty body (HTTP 204). Annotations already show readOnlyHint=false, consistent with a write operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no filler. Purpose is in the first sentence, usage guidance follows, then parameter details and return behavior. All sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all five parameters, return behavior, and error conditions. With output schema existing in metadata, the description still adds context about the HTTP 204 response. Complete for a logging 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?
Despite 0% schema coverage, the description adds detailed meaning for each parameter: list_id format and example, email_address derivation, name format constraints, and properties as optional dict. This fully compensates for the schema's lack of description.
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 records a custom event for an audience member, with examples like 'purchased'. It distinguishes from siblings get_member_events and get_member_goals by noting they are for reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'log member activity that can trigger automations or power segmentation'. Also specifies when not to use by referencing alternative tools for reading events and goals.
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?
The description adds context beyond annotations (readOnlyHint=true). It details the returned data per recipient, pagination behavior, and that it's for auditing. No contradiction.
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 with a summary line, usage guidance, Args section, and Returns section. Every sentence adds value; no fluff.
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 presence of output schema (the tool's return is described), the description covers all necessary context: purpose, parameter details, pagination, and return format. Complete for a read-only list operation.
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?
Despite 0% schema description coverage, the description thoroughly explains all parameters: campaign_id (how to obtain), count (range and default), offset (pagination use). Provides meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists members a sent campaign was delivered to, with per-recipient status. It uses specific verbs ('List', 'audit') and distinguishes from sibling get_campaign_report for aggregate stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (audit delivery status) and when not to use (use get_campaign_report for aggregate stats). Also provides pagination guidance with count and offset.
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?
Annotations indicate read-only and non-destructive behavior. The description adds crucial behavioral context: 'Returns 404 error if the member does not exist in the audience.' This is beyond annotations and helps the agent handle errors. No contradiction with annotations.
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?
Description is concise (8 sentences), front-loaded with purpose, then usage guidance, error behavior, and parameter details. Every sentence adds value without redundancy. Structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description still provides a succinct summary of the return JSON structure. It covers all necessary aspects: purpose, alternative tools, error handling, and parameter details. An agent can reliably invoke this tool based on the description alone.
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?
Despite 0% schema description coverage, the description thoroughly explains all three main parameters: list_id (format, example, how to obtain), email_address (must exist in audience), and count (range, default). This adds significant meaning beyond the schema. The fourth parameter 'account' is missing but defaults to null and is less critical.
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 starts with a clear verb ('Retrieve') and resource ('member's email interaction history'), specifying scope ('opens, clicks, bounces across all campaigns'). It distinguishes itself from sibling tools get_member_events and get_member_tags, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Shows email actions only') and when not to, providing alternative tools (get_member_events, get_member_tags). Also recommends using search_members first to find the audience, giving a clear workflow.
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?
Discloses idempotency (matching annotation), side effect of re-confirmation email on status change to 'pending', and error conditions (404, 400). Adds context beyond annotations.
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, no unnecessary words, and every sentence adds value. Front-loaded with purpose and usage.
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?
Covers purpose, usage guidelines, parameter details, side effects, error responses, and return values. Complete given tool complexity and presence of output schema.
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 coverage, description fully explains all parameters: list_id format and source, email_address requirement, status options, and merge fields (first_name, last_name). Also describes return fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates member profile fields or subscription status, and distinguishes from sibling tools like tag_member and add_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool versus alternatives (tag_member, unsubscribe_member, add_member, batch_subscribe), and states it does not manage tags.
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?
Discloses idempotent nature, that status_if_new only applies on creation, automatic hash derivation, and return value structure. No contradictions with annotations.
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-organized with purpose, usage, parameter list, and return info. Every sentence adds value, no redundancy.
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?
Covers functionality, parameter details, idempotency, and return value. Sufficient for an AI agent to select and invoke correctly given sibling tools and output schema.
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?
Provides detailed descriptions for all 6 parameters including format, defaults, valid values, and examples, compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds or updates a member (idempotent upsert), and distinguishes from siblings add_member and update_member by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells to use for add-or-update in one call without checking existence, and directs to siblings for strict create or update.
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:

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

Score Badge

Copy to your README.md:

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

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