Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains each action's purpose, including the 'ping' health-check behavior and the required IDs for sub-resource actions. It stops short of discussing rate limits or read-only guarantees, but the action-by-action breakdown is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief overview sentence followed by a scannable, enumerated list of actions. Each action's explanation is concise and information-dense, with no redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, 11 distinct actions), the description is thorough, covering every action and its required parameters. It also describes return content for key actions. Pagination behavior is absent, but the schema covers the count/offset parameters, so the description is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes each parameter with 100% coverage, so the baseline is 3. The description adds further meaning by linking each ID parameter to its specific action and summarizing the expected output (e.g., 'plan, contact, total subscribers, industry benchmarks' for overview). This adds real interpretive value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as handling account-level administration, listing the specific resources it covers (plan, API health, domains, etc.). This distinguishes it from sibling tools like mailchimp_audiences or mailchimp_campaigns, which address different domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence establishes a clear context for when to use this tool (any account-level administrative task). It does not explicitly name alternatives or exclusion criteria, but the resource scope is unambiguous and the action enumeration provides concrete deployment guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It fully specifies each sub-operation and its dependencies (e.g., which IDs are needed), and indicates the type of data returned (member counts, matching conditions, group titles). It does not mention pagination/rate limits, but for a read-centric tool this is adequate. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence using semicolons to delineate actions. Every phrase contributes meaning, and the structure is logical. It is longer due to the seven actions, but remains efficient. A slightly more structured list (e.g., bullet-style) could improve scannability but is not necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 actions and no output schema or annotations, the description covers all actions, their inputs, and outputs at a high level. It omits potential error cases and exact return shapes, but given the tool's complexity and presence of a rich schema, this is comprehensive enough for an agent to select the correct action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter described. However, the tool description adds critical value by mapping each action to the exact parameters required, which is not evident from the schema alone (e.g., 'segment_members needs segment_id'). This goes beyond the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's focus: 'Segments, tags, and interest groups within one audience' and enumerates exact actions (segments, segment_members, interest_categories, etc.). This clearly differentiates it from sibling tools like mailchimp_audiences (lists) and mailchimp_members (members). The verb 'retrieve' is implied through 'Set action to one of'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context by listing all actions and the required parameters for each (e.g., 'segment needs segment_id', 'interest needs category_id and interest_id'). However, it does not explicitly state when to use this tool over alternatives or provide exclusions, though the action list implicitly covers the decision space.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It describes data returned for each action, which is helpful, but does not explicitly state the tool is read-only, discuss rate limits, pagination caveats, or error conditions. The disclosed behaviors are limited to output summaries, not the full operational profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but each clause earns its place by defining one of the 12 actions. The structure is logical: first the umbrella scope, then a list of actions with inline descriptions, ending with parameter dependencies. It is not unnecessarily verbose, though it could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 actions, 6 parameters, no output schema), the description is remarkably complete. It summarizes what each action returns and flags which IDs are required. It lacks explicit error/edge-case behaviors, but for a data retrieval dispatch tool, the coverage is strong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The action parameter's enum is explained in detail within the description, going well beyond the schema's terse 'See the tool description.' The description also clarifies the role of list_id and webhook_id/merge_field_id in context. Other parameters are already well-described in the schema, so the added value is above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (audiences/lists) and clearly enumerates all sub-resources and actions, distinguishing it from sibling Mailchimp tools. It uses a specific verb pattern ('Get', 'retrieve' implied) and explains the purpose of each action, making its scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to start with the 'list' action to get a list_id, guiding the agent on the correct first step. It also clarifies which action needs webhook_id and merge_field_id. It does not explicitly mention when to use an alternative sibling tool, but given distinct resources, this is acceptable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosure. It details what each action returns, such as 'full automation record including its report_summary' and 'emails in the automation, in send order'. It also mentions the limitation that 'Customer journeys are not exposed'. It does not explicitly state that the tool is read-only, but the action names imply it. The behavioral expectations are adequately communicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph, but every sentence contributes useful information. It front-loads the core purpose and then enumerates actions with their purpose and parameter needs. It could be slightly more structured (e.g., bullet-style), but it is not verbose or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 actions, 6 parameters) and absence of output schema/annotations, the description covers the essential mapping of actions to their results and input dependencies. It explains the starting action (list) and what each subsequent action returns. It does not detail exact return structures or edge cases, but for a list/data-retrieval tool this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by tying action values to required parameters, e.g. 'queue_subscriber (one queued subscriber, needs email_id and subscriber_hash)' and 'list (all automations — start here for a workflow_id)'. This clarifies the workflow and dependency between parameters beyond the schema's individual descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's resource as 'Classic automations, their emails, and subscriber queues' and enumerates seven specific actions (list, details, emails, etc.) that define its operations. It also distinguishes itself by stating 'Customer journeys are not exposed by the Mailchimp API', which clarifies boundaries relative to other potential automation-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides action-level guidance, e.g. 'list (all automations — start here for a workflow_id)', and notes dependencies between actions (e.g. email_id from emails, workflow_id from list). It also offers a negative guideline by excluding customer journeys. However, it does not explicitly compare against sibling tools like mailchimp_campaigns, but the domain separation is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It clearly enumerates what each action returns, including 'list' being newest-first and 'send_checklist' indicating blockers. However, it does not explicitly state that all actions are read-only or mention any side effects, though the nature of actions implies safe retrieval.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized for a multi-action tool. It front-loads the resource and quickly moves to the key differentiator (reports) before listing actions with concise parenthetical explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has five distinct actions and no output schema, the description covers all actions and their outputs, plus provides starting guidance and a sibling pointer. It is complete enough for an agent to invoke actions correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds substantial meaning to the 'action' enum by explaining each option in context, and clarifies that campaign_id comes from the list action. This goes beyond bare schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (campaigns) and provides specific actions (list, details, content, feedback, send_checklist) with their purposes. It distinguishes from sibling tool mailchimp_reports by explicitly steering performance data queries away.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names an alternative tool for performance data ('For performance data use mailchimp_reports instead'), and instructs to start with 'list' to obtain campaign_id. This gives clear when-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what each action returns (carts, full cart record, line items) and that details/lines need cart_id. It does not explicitly state that the tool is read-only or describe error handling, but the action semantics are transparent enough for safe use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the purpose, the second lists the actions with their requirements. Zero wasted words, information is front-loaded and directly actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (three actions, five parameters, no output schema), the description adequately covers the core usage and dependencies. It omits details about response formats and pagination behavior, but those are partially covered by schema descriptions, and the tool is a read-style data accessor where the listed actions are sufficient for an agent to get started.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all parameters at 100% coverage, but the description adds critical semantics by mapping actions to required params ('needs cart_id'). This goes beyond the schema's terse parameter descriptions and clarifies the relationship between action and other fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages 'abandoned and active shopping carts for one store' with a specific analytical purpose. It enumerates three distinct actions (list, details, lines), making it easy to distinguish from sibling tools like mailchimp_orders or mailchimp_products.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear use case ('for abandoned-cart analysis') and explains when to use each action, including the prerequisite cart_id for details and lines. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like orders or products, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains the three action modes but does not disclose any potential side effects, authentication requirements, rate limits, or result handling. For a read-only tool this is a moderate gap; it lacks warnings about pagination behavior beyond what the schema already states, and says nothing about response format 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the resource type, and immediately lists the actionable modes. Every sentence is informative, and there is no filler or redundancy. It efficiently conveys the tool's core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four parameters, no output schema, and no annotations. The description covers the three actions and their intent, but it does not explain the structure of a 'full conversation record' or what constitutes a 'message' in the response. Given the absence of an output schema, a bit more detail about return values would make the tool more complete. Still, for a relatively simple data-retrieval tool, this is an adequate but not rich description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with descriptive text for each parameter, including defaults and relationships (e.g., conversation_id 'from action=list'). The description augments the 'action' parameter by naming the three allowed values and their meanings, but this duplicates schema enum descriptions. It does not add significant semantic detail beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource ('Inbound replies from subscribers, tracked as conversations') and enumerates the three distinct operations (list, details, messages) with brief explanations of each. This is a specific verb+resource combination that distinguishes it from sibling tools like mailchimp_members or mailchimp_reports.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly conveys when to use this tool: when needing to retrieve inbound subscriber conversations or their details/messages. However, it does not explicitly mention when not to use it or provide alternatives among the sibling tools. There is no direct comparison or exclusion guidance, so usage context is implied but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses action-specific behaviors: 'list' returns customers with orders_count and total_spent, while 'details' returns a full customer record and requires customer_id. Since no annotations are provided, the description carries the transparency burden, and it adequately conveys a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, then breaks down the action variants. No redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with five parameters and no output schema, the description provides enough context to select and invoke it correctly, including action-specific outputs and prerequisites. Minor omissions like response structure or pagination are offset by thorough schema descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all parameters (100% coverage), but the tool description enriches the 'action' parameter by detailing what each enum value returns and clarifies the dependency of 'customer_id' for the 'details' action, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving e-commerce customers for a specific store, with specific fields (order counts, lifetime spend). It distinguishes from sibling tools like mailchimp_members (audience) and mailchimp_products by focusing on store customers, making it unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when to use: when you need customers for a store. Does not explicitly exclude alternatives or state when not to use, but the purpose is specific enough that a user can infer applicability. Lacks explicit sibling comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains what each action returns (e.g., 'files stored in the File Manager') but does not disclose whether this is read-only, any permissions needed, side effects, or response structure. This is a significant gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main resource concept, followed by a clear, organized list of actions and their meanings. It is slightly verbose but every sentence contributes necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters, no output schema, and no annotations. The description covers the action mappings and required IDs but omits behavioral details such as read-only nature, pagination behavior, and response format. It is adequate for a simple retrieval tool but leaves some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The tool description adds context by explaining the action enum values and specifying which IDs are required for which actions, but the schema's parameter descriptions already include this information. The added value is modest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource domain: File Manager assets and folders, plus campaign folders. It distinguishes this from sibling tools by specifying the exact resource types. However, it lacks an explicit verb like 'retrieve' or 'list', making the overall purpose slightly implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by defining the scope (File Manager and campaign folders) and listing specific action options. It does not explicitly state when to prefer this tool over siblings or provide exclusions, but the resource-specific mapping offers adequate guidance for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It specifies what each action returns (status/URL, full record, rendered HTML), making the read-only nature evident. It does not discuss rate limits, authentication, or error conditions, but for a retrieval tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, front-loads the resource, and every clause provides necessary information. The action list is formatted clearly without redundancy. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main actions and their outputs, but does not explicitly state that details/content require a page_id or that list is needed first. The schema hints at this via 'from action=list,' yet the description could be more self-contained. Overall, it is mostly complete for a read-only resource tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics to the 'action' parameter by explaining what each enum value returns, which is not fully detailed in the schema. This elevates the score above baseline since the schema's action description points back to the tool description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (landing pages) and enumerates three specific actions (list, details, content) with their return types. It clearly distinguishes from sibling tools by focusing on landing pages. However, it lacks a direct verb phrase like 'Retrieve landing pages,' making the primary purpose slightly indirect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to choose among actions ('Set action to one of: list...'), which is clear within the tool. However, it does not mention when to use this tool versus alternatives like mailchimp_search or mailchimp_campaigns, nor does it exclude any use cases. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It discloses ordering (newest-first), pagination via count/offset, activity limits (last 50), and note_id dependency. These are meaningful behavioral traits beyond the schema, though it doesn't explicitly state read-only or cover auth/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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficiently structured with semicolons to separate actions. There is no redundant filler, but the single long sentence could be slightly easier to scan if broken into bullets. Overall, it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description comprehensively covers all action variants, parameter dependencies, and behavioral details like pagination and activity limits. Without an output schema, it provides enough context to select and invoke the tool correctly, leaving little ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema covers 100% of the parameters, the description adds value by explaining what each action returns (e.g., 'details' includes merge fields, interests, stats), clarifying that 'note' requires note_id, and describing pagination behavior for 'list'. This raises it above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's domain—Mailchimp members and their associated data—and lists nine distinct retrieval actions, distinguishing it from sibling tools. However, the opening is a noun phrase ('Subscribers in one audience') rather than an explicit verb phrase, which slightly weakens the clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 and breaks down each action into its specific use case (list, details, tags, activity, etc.). It does not explicitly mention alternatives or exclusions, but the detailed action list effectively guides selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It details what each action returns (list: orders with totals and attribution; details: full record with line items; lines: line items only) and notes dependencies like order_id. It does not explicitly state read-only behavior, but the action verbs imply it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and then provides a compact breakdown of actions. Every sentence is informative with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description does a good job of conveying the tool's variants and dependencies. Pagination is not mentioned, but the schema covers count/offset. It is complete enough for an agent to select and invoke the correct action, though it could elaborate on the return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the action parameter by elaborating what each enum value returns, and it clarifies the role of order_id as required for details/lines. This goes beyond the schema's terse descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this tool handles orders and line items for a single store, with a specific verb implied by the action options (list, details, lines). It distinguishes from sibling tools like mailchimp_stores or mailchimp_reports by focusing on order data and campaign attribution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the three action modes and their prerequisites (details and lines require order_id), giving clear context on how to use the tool. It scopes usage to 'one store,' implying it is not for cross-store queries, but no explicit alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It implies read-only behavior through the action verbs (list, details, variants), but does not explicitly state that no modifications occur, nor does it disclose any authentication requirements, rate limits, or side effects. It clarifies parameter dependencies which is useful, but leaves safety profile ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences—and front-loaded with the primary purpose. The action breakdown is structured clearly and efficiently, with zero filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers the tool's functionality by listing all four actions and their required parameters. It does not describe return formats in detail, but no output schema exists, and for a data-retrieval tool with clear actions, this is sufficient. Minor gaps remain (e.g., pagination details), but those are covered in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with clear descriptions for all parameters, but the tool description adds meaningful semantics by explaining the action enum and how product_id/variant_id relate to each action. This goes beyond the schema's individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Product catalog and variants for one e-commerce store.' It distinguishes from sibling tools by focusing specifically on product-related data, and the action list provides specific verbs for different retrieval scenarios.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context about the e-commerce store scope and breaks down when each action is appropriate (e.g., 'needs product_id'), but it does not explicitly compare to sibling tools or state when not to use this tool. The guidance is implied rather than clearly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It does not state that the tool is read-only, nor does it describe error behavior, rate limits, or what happens when required IDs are missing. The only behavioral hint is the action names implying retrieval, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long: a clear summary followed by a compact enumeration of the four actions and their parameter needs. No filler or redundant content; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with six parameters and no output schema, the description covers the action-to-parameter mapping but omits return value shapes, pagination behavior (though count/offset are in schema), and examples. It is adequate for a moderately complex read-only tool but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% parameter descriptions, so the baseline is 3. The description adds value by mapping actions to required parameters and showing dependencies (e.g., action='code' needs both promo_rule_id and promo_code_id), which is not present in the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (promotion rules and promo codes) and the scope (one store), and the action enum explicitly defines what can be retrieved. This distinguishes it from all sibling tools like mailchimp_products or mailchimp_orders, which cover different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage instructions for each action, telling the agent which parameters are needed (e.g., 'rule (one rule, needs promo_rule_id)'). It does not explicitly mention alternatives or when not to use the tool, but since no other sibling handles promotions, the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely succeeds. It details what each action returns (e.g., 'opens (which members opened, and how often)', 'domain_performance (deliverability by recipient domain)') and flags parameter dependencies ('needs link_id', 'needs subscriber_hash'). It doesn't mention rate limits or read-only behavior, but the read-only nature is implied by its analytics purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that front-loads the purpose and then enumerates all actions in a list-like structure. There is no fluff; every clause adds value. However, it is quite long and could be more readable with bullet points, so it doesn't earn a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters, no output schema, and no annotations, the description thoroughly covers the behavior of every action and their return contents. It also notes dependencies like 'needs link_id' and 'needs subscriber_hash'. While it could mention that campaign_id is needed for most actions, the overall coverage is strong and effectively compensates for missing structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining each action enum value in detail and noting which extra parameters each action requires (e.g., 'link_id from action=clicks'), which the schema alone doesn't convey. This significantly aids correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Campaign performance analytics' followed by a specific list of metrics (opens, clicks, unsubscribes, etc.), clearly identifying the tool as a reporting tool for campaign data. This distinguishes it from siblings like mailchimp_campaigns, which focus on campaign management, and makes the tool's main function unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage instructions by listing the 'action' options and what each does, guiding the user on which action to set for different reporting needs. It doesn't explicitly compare with alternatives, but since no sibling covers reporting, the niche is clear. The implied usage is strong due to the exhaustive action list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses search scope and result outcomes (subscriber_hash, campaign_id), but does not explicitly confirm it is a read-only operation or mention limitations like pagination or rate limits. It adds useful context but leaves some behavioral aspects implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with 'Search the account' and immediately gives examples. It uses a clear 'Set action to one of:' structure with inline definitions, making it concise and scannable with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with three parameters and no output schema, the description adequately covers the search scope and action semantics. It lacks explicit response format details, but it provides enough context for an agent to select and invoke the tool correctly, and the action enum details fill in key gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning to the 'action' parameter by elaborating on each enum value (members finds subscribers, campaigns finds campaigns), and reinforces that query can be an email, name, or phrase. This goes beyond the schema's brief reference to the tool description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search the account' and provides concrete examples (email to subscriber_hash, phrase to campaign_id) and enumerates two action types with detailed explanations. This distinguishes it from sibling tools like mailchimp_members and mailchimp_campaigns by positioning it as an account-wide search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly positions the tool as 'the fastest way' for specific lookups and explains each action's scope (find subscribers across all audiences, find campaigns by title/subject/content). It does not name alternative tools or state when not to use it, but the context implies it is the go-to for cross-account searches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It transparently describes each action's output scope and the store_id requirement, which is critical for correct invocation. While it doesn't mention pagination behavior, the schema covers count/offset, and all actions are clearly reads with no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise, front-loaded sentences capture the overall purpose, the entry-point advice, and the action-specific details with zero filler. The structure effectively guides the user from high-level context to specific invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action tool with 4 parameters and no output schema, the description fully specifies every action and its requirements. It covers the essential context (store aggregation, store_id as entry point) and leaves pagination details to the schema, which is well-documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the baseline is 3, but the description adds meaning by explaining the action enum options and the dependency of store_id on the 'details' action. This goes beyond the schema's individual parameter descriptions, clarifying how parameters combine.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's domain (connected e-commerce stores) and enumerates three specific actions (list, details, all_orders), making its purpose unambiguous. It also distinguishes itself from siblings by emphasizing cross-store aggregation ('orders across every store') and positioning itself as the entry point for store IDs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides the guidance 'Start here for a store_id', indicating this tool is the recommended first step for store-related operations. It also clarifies when to use each action, including the prerequisite of store_id for details. However, it does not explicitly compare against alternative sibling tools like mailchimp_orders, relying on the cross-store scope to implicitly differentiate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It lists actions but doesn't explain that 'details' and 'default_content' require template_id, whether results are paginated, or any other behavioral traits. The description adds little beyond the schema's parameter docs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, naming the resource and then the actions in a clear list. It wastes no words, though the parenthetical for 'default_content' is slightly redundant with the action name. Still, it's efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters and 3 distinct actions, but the description doesn't specify which parameters are required for each action (e.g., template_id is needed for details/default_content), what the return shape looks like, or how count/offset apply across actions. Given no output schema and no annotations, this is a significant completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds semantic grouping by associating each action with its output, but it does not add new parameter-level details beyond what schema already provides. It earns the baseline, not more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (email templates) and enumerates three distinct actions (list, details, default_content), which distinguishes it from sibling tools focused on other Mailchimp resources. However, it lacks a strong action verb like 'retrieve' or 'manage', so it's slightly less direct than ideal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what actions are available but gives no guidance on when to use this tool versus alternatives (e.g., mailchimp_campaigns or mailchimp_landing_pages). It does not mention prerequisites or typical use cases, leaving the agent to infer usage from the sibling names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.