MisarMail MCP Server

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

Annotations indicate a write operation (readOnlyHint=false), and the description confirms by stating it adds a domain. It additionally reveals the return value (DNS records) and a critical temporal constraint (cannot send until verification), going well 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.

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

The description is two sentences, front-loading the core action and output in the first sentence, with an important qualification in the second. 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.

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

For a simple, single-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and the follow-up required. It is complete given the low complexity and rich structural information from the schema and annotations.

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 a clear description for the single parameter ('Domain to add, e.g. example.com') with 100% coverage. The description adds no extra meaning for the parameter, meeting the baseline expectation but not exceeding it.

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 uses a specific verb ('Add') and resource ('sending domain') and clearly states the additional output ('return the DNS records to publish'). It distinguishes from sibling tools like verify_domain and check_dmarc by focusing on the initial addition step.

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 explicit post-condition context ('The domain cannot send until those records are live and verify_domain succeeds'), guiding the agent to follow up with verify_domain. However, it does not explicitly contrast with alternatives or 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.

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

With annotations already covering read-only, idempotent, and destructive hints, the description adds a meaningful behavioral detail: reversibility and non-deletion. This goes beyond the structured annotations, though it does not describe potential errors or return behavior.

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 short sentences with no wasted words. It front-loads the primary action and immediately adds the key safety qualifier.

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 one-parameter, low-complexity mutation with good annotation coverage and no expected rich output, the description is complete enough. The reversible behavior is stated, and the required ID is documented 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?

Schema description coverage is 100% for the single 'id' parameter, so the schema already explains it fully. The tool description itself adds no additional parameter details, matching the baseline score of 3 for high schema coverage.

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 states a specific verb and resource: 'Move an email to the archive folder.' It clearly differentiates the action from sibling email tools like send_email or reply_to_email by specifying the archive destination and explicitly noting the message is not deleted.

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 context: use this to archive an email rather than delete it, emphasized by 'Reversible — the message is not deleted.' It does not explicitly name alternative tools or state when not to use it, so it stops 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?

Annotations already convey idempotentHint=true (safe to retry) and destructiveHint=false (no destruction). The description adds important behavioral context: it consumes AI credits (a cost/resource implication) and implies it processes a batch (max 50). 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.

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

Two concise, front-loaded sentences. The first sentence states the core function, the second provides critical usage guidance. Every word adds value; no redundancy.

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 low complexity (1 param, no output schema), the description is sufficient. The agent understands input, behavior (AI credit consumption), and constraints (max 50). A minor gap: the output format (returned labels/priority) is not described, but since there is no output schema, this is a soft miss rather than a hard requirement.

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% (only one parameter, 'email_ids', well-described with array type, string items, and max 50 limit). The description reinforces that these are emails 'to categorise' and adds the consumption cost context, which helps the agent decide which IDs to pass. No additional parameter documentation is needed beyond what's already provided.

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 uses a specific verb ('Run AI categorisation') and resource ('batch of inbox emails') and states the outcome ('label intent and priority'). This clearly distinguishes it from siblings like 'archive_email', 'reply_to_email', or 'get_email', which handle different operations on emails.

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 advises to only pass emails that need triaging due to AI credit consumption. This provides clear when-to-use guidance. However, it does not explicitly mention when NOT to use this tool (e.g., for already categorized emails) or name specific alternative tools, though the sibling list provides implicit 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?

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds context beyond annotations by noting the check is 'live,' and that it 'report[s] alignment problems with the exact record to publish.' This provides actionable insight into what the tool does with the data it fetches, which is 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.

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

The description is two sentences long, front-loads the core purpose, and contains no filler or redundancy. Every sentence contributes critical information: what records are checked, what is reported, and scope of applicability.

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 simple read-only tool with full annotations and a single parameter, the description is largely complete. It covers the DNS record types checked, the output (alignment problems and publishable record), and domain scope. The absence of an output schema is acceptable since the description adequately describes what the tool returns.

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 a single parameter described as 'Domain to check, e.g. example.com.' The description adds value by stating 'Works for any domain, not only your own,' which clarifies that the domain parameter is not restricted to the user's own domains—a meaningful addition beyond the schema 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 the tool checks live SPF, DKIM, and DMARC DNS records for a domain and reports alignment problems with the exact record to publish. It uses specific verbs ('Check', 'report') and identifies the resource (DNS records for a domain), distinguishing it from sibling tools like verify_domain or run_deliverability_audit.

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 states 'Works for any domain, not only your own,' clarifying domain scope and implying broad applicability. However, it does not explicitly mention when to use this tool versus alternatives (e.g., verify_domain), nor does it provide any 'when not to use' guidance or prerequisites.

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?

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context by clarifying that the deletion only affects sandbox data ('intercepted test messages') and explicitly states it never impacts real sent mail. This goes beyond the annotation flags to set user expectations about scope and safety.

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 short, clear sentences with no wasted words. The first sentence states the action and resource; the second clarifies the scope limitation. Information is front-loaded and every sentence 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?

Given the tool's simplicity (no parameters, no output schema, clear annotations), the description fully covers what the tool does and its boundaries. It explains the effect (deletion), the resource scope (sandbox emails only), and what is excluded (real sent mail), making the tool's behavior complete for an agent.

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?

There are zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter details, and the baseline for 0-parameter tools is 4. The description does not mislead or omit any necessary parameter information.

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 uses the specific verb 'Delete' and clearly identifies the resource as 'every captured sandbox email'. It distinguishes itself from siblings like list_sandbox_sends and send_email by explicitly stating it affects only intercepted test messages, never real sent mail, making its scope 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 implies usage for cleaning up sandbox emails after testing, and its safety disclaimer ('never real sent mail') provides indirect guidance. However, it lacks explicit statements about when to use or when not to use this tool versus alternatives (e.g., comparing to list_sandbox_sends for inspection before deletion).

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?

Annotations already provide idempotentHint=true and destructiveHint=false, so the description need not restate those. The description adds value by stating the return value (MX record) and the overall behavior (configuring routing). However, it does not disclose side effects like overwriting existing routing or DNS requirements, so transparency 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.

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

Two sentences, no wasted words. The first sentence immediately states the purpose and outcome, the second sentence declares the return value. Highly efficient.

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?

With 100% schema coverage, annotations, and no output schema, the description covers the core purpose and return value. It is nearly complete, though it could mention prerequisites like domain verification. Given the context signals, this is a strong 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?

Schema coverage is 100% with clear descriptions for all three parameters. The description's text ('Configure inbound email routing for a subdomain') aligns with the schema but does not add new meaning beyond what the parameter descriptions already provide. Baseline 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 states the verb 'Configure' and the resource 'inbound email routing for a subdomain', and specifies the outcome 'replies land in the MisarMail unified inbox' and the return value 'MX record'. This distinguishes it from siblings like add_domain, verify_domain, and send_email.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., domain must be added via add_domain or verified via verify_domain), nor does it indicate when not to use it. The agent has no explicit 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.

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

Annotations provide readOnlyHint=false and destructiveHint=false, which are consistent with a creation tool. The description adds value by disclosing the two-phase behavior (sample sent first, winner later) and implicitly that the tool does not automatically select the winner. 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.

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

Two sentences with no wasted words. The first sentence states the purpose, the second describes the process. Information is front-loaded and easy to parse.

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?

No output schema is provided, and the description does not mention the return value (e.g., test ID). Prerequisites like campaign existence are not mentioned. The description explains the process but omits key context about what the tool actually returns.

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% with clear parameter descriptions. The description adds minimal value beyond the schema, only hinting at the process. Baseline 3 is appropriate as the schema already documents the parameters well.

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 verb 'Create' and the resource 'A/B test on a campaign', and explains the two-phase process (sample then winner). It distinguishes from sibling tools like 'select_ab_test_winner' and 'list_ab_tests' by describing the creation action.

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 the tool is used to start an A/B test and mentions the process flow, but it does not explicitly state when to use this tool versus alternatives (e.g., using 'select_ab_test_winner' later). No exclusions or prerequisites are given.

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?

Annotations indicate a write operation (readOnlyHint=false) but provide no other behavioral clues. The description adds critical behavior: 'Created paused by default'. This is a key trait that influences when and how the tool should be used. It doesn't disclose return value or error cases, but the paused behavior is significant and well-stated.

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 with no wasted words. The first sentence states the purpose, the second adds the critical behavioral note. Front-loaded and efficient – every sentence 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 5 parameters, 2 required, nested objects, and no output schema, the description covers the primary purpose and the important paused-by-default behavior. However, it lacks mention of the return value (likely the created automation ID) and doesn't clarify that steps are optional despite being referenced as a core component. Still, the schema fills many gaps, making this description adequate.

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 does not add meaning beyond the schema; it simply restates 'trigger and an ordered list of steps' which is already present in the schema descriptions. It provides no examples, clarifies optional fields (steps is not required but is implied), or explains trigger_config. No extra semantic value is added.

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 action ('Create an automation workflow') and specifies the key components ('from a trigger and an ordered list of steps'). It distinguishes the tool from siblings like toggle_automation by noting that the automation is created paused by default, requiring a separate activation step.

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 tells the agent when to use this tool (to create an automation workflow) and what to do afterwards ('call toggle_automation to activate once the steps are reviewed'). It also implies a workflow: create, review, then activate. This provides clear context for usage compared to alternatives.

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?

The description discloses a critical behavior: 'Creating never sends' and that the campaign is created as a draft. This adds context beyond the annotations (which only indicate non-read-only, non-idempotent, non-destructive) and clarifies the lack of immediate sending 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?

The description is extremely concise—two sentences—and clearly conveys the core purpose and the key behavior (no sending). It avoids superfluous words and is well-structured for quick understanding.

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 create operation with no output schema, the description adequately explains that it creates a draft and does not send, but it omits details about the return value (e.g., campaign ID) and any expected side effects. Given the tool's simplicity, this is acceptable but not highly complete.

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 per-parameter descriptions covering all 11 parameters (100% coverage), and the overall description does not add granular details about parameters. It only generically refers to 'content and audience,' which is already implied by the schema. Thus, it adds minimal 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 states 'Create a new email marketing campaign as a draft' and explicitly distinguishes it from sending by noting 'Creating never sends — call send_campaign separately.' This makes the purpose unambiguous and differentiates it from the sibling tool send_campaign.

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 clear guidance to call send_campaign separately once content and audience are confirmed, implying the intended workflow. However, it does not explicitly mention when not to use other related tools (e.g., list_campaigns, update_campaign), but given the context, the guidance is sufficient.

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?

The description implies a write operation ('Add') and mentions a side effect ('records consent'), but does not describe the return value or error behavior. The annotations (readOnlyHint: false) confirm mutation, but idempotency and reversibility are not addressed.

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 concise sentences, front-loaded with the primary action, and includes essential context without unnecessary verbosity.

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 core action, relevant constraints (consent requirement), and legal implications. Combined with the complete parameter schema and annotations, the context is sufficient for correct usage.

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?

All 9 parameters have descriptions with types and constraints (e.g., max lengths for phone, source, company, job_title, last_name, first_name). The descriptions are clear enough for an agent to understand each parameter's purpose.

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 'Add a single contact' with a specific verb and resource, and distinguishes it from sibling tools like update_contact and list_contacts.

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 explicit usage guidance: 'only add addresses that opted in' and warns about sender reputation and legal compliance (CAN-SPAM/GDPR), which helps the agent decide when 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.

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

The description discloses that subscribers flow into your contact list, which is an important side effect beyond the immediate creation. Annotations confirm readOnlyHint=false and destructiveHint=false, so the description aligns and adds value by clarifying the side effect. However, it does not mention other potential behaviors like whether it's idempotent, if landing pages have usage limits, or what happens on failure (e.g., duplicate name). With annotations already signaling a write operation, the description does enough to satisfy the bar.

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, efficient and front-loaded: the first sentence states the core action and resource, the second provides the key outcome and side effect. Every sentence adds unique value with no 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?

There is no output schema, so the description compensates by noting the return of a public URL, which is adequate for a creation tool. However, it does not mention any required permissions, error scenarios (e.g., duplicate name), or behavior of related contacts. Given the moderate complexity (6 parameters) and good schema coverage, the description is sufficient but leaves some questions unanswered.

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 schema itself documents all parameters thoroughly. The description only adds value by explaining the output ('Returns the public URL') and the side effect ('subscribers flow straight into your contact list'), but does not elaborate on any parameter meaning beyond what is in the schema. Baseline of 3 is appropriate as the description does not need to repeat schema info but also does not add depth.

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 states a specific action ('Create a hosted landing page with an email capture form' ) and a unique resource type ('hosted landing page'). It mentions a key outcome ('subscribers flow into your contact list'), which adds specificity. However, among siblings there are 'create_form' and 'create_campaign', and the description doesn't explicitly distinguish this landing page tool from those form or campaign creation 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?

No guidance is given about when to use this tool versus siblings like 'create_form' (for standalone forms) or 'create_campaign'. It does not state prerequisites (e.g., a verified domain) or when not to use it. The context is implied by the name and description, but explicit exclusions or alternatives are absent.

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?

Annotations mark this as a non-read-only write operation; the description adds context beyond annotations by explaining variable substitution at send time and previewability via render_template. 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.

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

Two sentences with front-loaded action ('Create a reusable email template') and a follow-up sentence that explains variable behavior and links to a sibling tool. Every sentence earns its place with no redundancy.

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 create tool with 6 parameters and no output schema, the description covers the core purpose and a key behavioral nuance (variable substitution). It doesn't explain return values, but that's less critical without an output schema; the schema handles parameter details.

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 input schema has 100% coverage with descriptions for all six parameters, so the baseline is 3. The description reinforces the {{variable}} placeholder concept but does not add parameter-specific semantics beyond what the schema already documents.

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 'Create a reusable email template', using a specific verb and resource. It distinguishes itself from siblings like render_template by focusing on creation, and introduces the key personalization feature via {{variable}} placeholders.

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 when to use this tool (to create templates) and explicitly names render_template as the tool for previewing, providing a useful alternative. However, it does not explicitly state when not to use it or compare with other creation tools like create_campaign.

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?

The description adds minimal behavioral context beyond the existing annotations (readOnlyHint, idempotentHint). It does not disclose aspects like response format, data freshness, or limitations, which are important for a report generation tool.

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 wastes no words. Each sentence 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?

Given no output schema, the description should hint at return format (e.g., JSON) or example usage. It covers input well but leaves agents uncertain about output structure, making it minimally complete.

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 description adds value by explaining the enum options (especially 'send_time_heatmap' with a parenthetical hint) and reinforces the date range concept. This goes beyond the raw 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 states the tool generates structured analytics reports over a date range and lists four specific report types. However, it does not differentiate from the sibling 'get_analytics', which may have overlapping functionality, slightly diminishing 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?

No guidance is provided on when to use this tool versus alternatives like get_analytics. The description only explains what it does without contextual usage advice.

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?

Annotations indicate readOnlyHint is false and destructiveHint is false, suggesting this is a non-destructive but potentially state-changing operation (generation). The description does not add behavioral details beyond what annotations imply, such as rate limits, token consumption, or whether output is persisted. Without richer annotation context, a moderate score is appropriate.

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-loading the core action ('Generate AI subject-line variants') and immediately providing context for downstream use. Every word is functional, and there is 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 the tool has four parameters, one required, no output schema, and annotations that are present but minimal, the description adequately covers the key use case and suggests integration with 'create_ab_test'. It could be more complete by noting the default tone is 'professional' (implied by schema default), but overall it provides sufficient 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.

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by clarifying that 'topic' is the core input ('what the email is about') and that 'tone' and 'audience' are optional tunings, which aligns with the schema. It reinforces the purpose of 'count' as variant generation quantity but doesn't add novel semantics beyond the schema's own 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 generates AI subject-line variants for a campaign topic, with optional tone and audience tuning. It distinguishes itself from siblings like 'create_ab_test' by positioning its output as input for that tool, though it could more explicitly differentiate from other generation or suggestion 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?

The description provides clear when-to-use context by stating the output is good input for 'create_ab_test', which suggests a specific workflow. However, it does not mention when not to use this tool or indicate alternatives for other subject line generation methods.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the specific metrics returned and the grouping behavior, which is consistent with the annotations. It does not contradict them and provides additional context about the nature of the response, though it could mention that the operation is non-modifying (already 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.

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

The description is a single sentence of 25 words that front-loads the core purpose ('Get delivery and engagement analytics'), then enumerates metrics and constraints without redundancy. Every clause adds essential information, making it highly efficient for an agent to parse quickly.

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 that there is no output schema, the description adequately covers what the tool returns (list of metrics), how data can be scoped (account/campaign), and the grouping options. It does not describe the response structure (e.g., JSON format, nesting) or behavior when no data exists, but for a read-only analytics tool with well-defined parameters, this is sufficient for an agent to decide whether to invoke it.

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 input schema has 100% description coverage for its 5 parameters, so the baseline is 3. The description adds semantic value by listing the exact metrics (sent, delivered, opened, etc.) that the tool returns—information not present in the schema—and by clarifying that campaign_id is optional and defaults to account-wide. This helps the agent understand what kind of data to expect beyond parameter definitions.

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 verb 'Get', the resource 'delivery and engagement analytics', and specifies exact metrics (sent, delivered, opened, clicked, bounced, complained). It also defines scope ('account or one campaign') and grouping ('day/week/month'), which distinguishes it from sibling tools like get_deliverability_score or get_monetization_stats that cover different or narrower aspects.

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 data the tool returns and the two scopes (account-wide vs. per campaign), but it does not explicitly contrast with similar tools (e.g., get_deliverability_score, get_monetization_stats) or state when not to use it. The agent must infer usage from the listed metrics and parameters; no exclusion criteria or alternatives are provided.

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?

The description indicates a read-only operation ('Get') and the annotations confirm readOnly, idempotent, and non-destructive behavior. It does not disclose response format details or error handling, but for a get operation this is reasonable.

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, well-structured sentence that directly conveys the essential information without redundancy. It is concise and easy to parse.

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 provides a good summary of the returned content, but it does not include an output schema or explicitly differentiate from similar get/list operations. It is largely complete for a read operation, but lacks a bit of context.

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 single parameter automation_id is described as 'Automation ID (UUID)', which is precise and unambiguous. The schema coverage is 100% and no additional explanation is needed.

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 retrieves one automation workflow in full, including trigger, steps, delays, and per-step stats. This unambiguously communicates its purpose.

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 does not explicitly state when to use this tool versus alternatives like list_automations, nor does it mention prerequisites or edge cases. The purpose is clear, but usage guidance is implicit 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?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds return-content context but no additional behavioral traits such as error handling, authentication needs, or rate limits. No contradiction exists.

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, focused sentence that front-loads the action and object, then lists the included detail categories efficiently. Every phrase adds value without redundancy.

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 one-parameter read-only tool with no output schema, the description adequately conveys what the caller receives. It could mention error behavior or exact output structure, but the listed categories are sufficient for a tool of this simplicity.

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 fully documents the single parameter campaign_id with type and description. The tool description adds no further parameter-level detail, so the baseline score of 3 applies given 100% schema coverage.

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 uses a specific verb and resource ('Get full details for one campaign') and enumerates the returned content categories: content, audience segment, schedule, and delivery statistics. This clearly distinguishes it from list_campaigns and other getter 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?

The description implies use when needing full details of a single campaign, but it does not explicitly state when not to use it or mention alternatives such as list_campaigns. Usage context is clear but exclusionary guidance is absent.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by explaining the two modes of operation (single contact vs. list-wide) and the output fields (engagement score, tier, churn risk), which goes 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.

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

The description is two sentences, front-loaded with the core purpose, and includes a usage hint. Every word earns its place; no fluff or redundancy.

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 simplicity (one optional parameter, no output schema), the description is complete enough. It explains the two modes, the output fields, and the recommended usage context. The only minor gap is that it doesn't specify the format of the output (e.g., JSON structure), but that's acceptable without an output 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 for the single parameter (contact_id) with a clear description. The tool description adds value by explaining the behavior when contact_id is omitted, which is not fully captured in the schema. This is a good complement to 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 states the tool's purpose: it retrieves engagement score, tier, and churn risk for a contact, or the lowest-engagement contacts when contact_id is omitted. This is specific and distinguishes it from sibling tools like get_deliverability_score or get_analytics.

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 the tool ('Use before a re-engagement campaign') and explains the dual behavior based on contact_id presence. It doesn't explicitly mention alternatives, but the context is sufficient for an agent to decide when to invoke it.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds the return content (score, grade, factors) but no additional behavioral traits beyond what is obvious from the name and schema. The description 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.

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

Two sentences, zero wasted words. The first sentence defines the tool's output, and the second gives a clear use case. Every sentence 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 simple read-only tool with no parameters and no output schema, the description is nearly complete. It specifies the output and a typical use case. It could be slightly more complete by explicitly stating it returns account-level data, but the current text 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?

There are no parameters, so schema coverage is 100% by default. The description adds value by explaining the tool's output (score range, grade, factors) beyond the empty schema. Baseline for 0 parameters is 4, and the description meets that by providing purpose and return details.

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 retrieves the account deliverability score (0–100) and letter grade (A–F) along with contributing factors. It explicitly names the output format and scope, and the 'Start here' hint differentiates it from more detailed sibling tools like run_deliverability_audit.

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 includes explicit usage guidance: 'Start here when asked why emails are landing in spam.' This clearly indicates the primary use case. However, it does not explicitly mention when not to use this tool or name alternatives, leaving room for slight ambiguity.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds the key side effect 'marks the email as read', which is crucial. It also enumerates what content is returned. It doesn't mention authentication or rate limits, but those are not critical for a simple read-like operation. 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.

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

The description is two short sentences. The first states the purpose and content coverage, the second reveals the side effect. It is front-loaded and contains no filler. Every word adds value.

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?

With only one parameter, no output schema, and low complexity, the description fully captures what the tool does, what it returns, and its side effect. Annotations cover safety profile. Nothing essential is missing.

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 covers 100% of parameters (only 'id' with description 'Email ID (UUID)'). The description merely repeats the parameter name and doesn't add extra meaning, such as where the ID comes from or format nuances. Baseline 3 is appropriate since the schema already documents it.

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 action (read full content), the resource (single email), and the scope (by ID, including headers, body, attachments metadata). It distinguishes from sibling tools like list_emails which likely provide summary metadata without full content.

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 when to use this tool (when full content of a specific email is needed). It doesn't explicitly mention alternatives or exclusions, but the context with siblings like 'list_emails' and 'archive_email' makes the usage obvious. A brief 'use this instead of list_emails when you need full content' would be 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, making the non-destructive read behavior clear. The description adds context on the returned data (fields, embed code, redirect behavior) but doesn't disclose potential edge cases like what happens if the form ID is invalid or if the form is deleted. Given good annotation coverage, the description meets expectations but doesn't excel.

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, front-loaded sentence that conveys the core purpose and scope efficiently. Every word contributes meaning, with no redundancy or fluff.

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 simplicity (1 param, no output schema, no nested objects), the description covers the basics: it explains what data is returned. However, it lacks completeness for an agent that might need to know the exact structure of the returned form object or how to handle missing forms. The description is adequate for the tool's complexity but not thorough.

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 the 'form_id' parameter already described as 'Form ID (UUID)'. The description does not add additional meaning beyond the schema, but the schema itself is sufficient. Per guidelines, baseline 3 is appropriate since the schema carries the full burden.

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 action ('Get one signup form') and the resources returned ('fields, embed code, and redirect behaviour'). It distinguishes itself from siblings like 'list_forms' (which lists multiple forms) and 'get_form_submissions' (which gets submissions). The description could be more specific about what 'redirect behaviour' means, but it's still clear.

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 suggests use when you need a single form's details, contrasting with 'list_forms' for listing all forms. However, there is no explicit guidance on when not to use it, alternatives for related tasks (like updating a form), or prerequisites (like requiring the form to exist). It provides a baseline adequate hint but lacks explicit usage rules.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about returned data (field values and timestamps), which is useful but doesn't disclose additional behavioral traits like pagination ordering or rate limits. This modest extra context warrants a 3.

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?

Single sentence that is front-loaded with the core action and resource, followed by a brief clause on included data. No wasted words; every element contributes to understanding.

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 simple list operation with three well-documented params and strong annotations, the description is adequately complete. It mentions what the output contains (field values, timestamps) and the pagination parameters are already in the schema. Slightly more detail about default ordering or response shape could push it higher, but overall it's 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 description coverage is 100%, so the schema already documents form_id, page, and limit. The description does not add further parameter-level insight beyond what the schema provides, so baseline 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 states the verb 'List' and the resource 'submissions for a signup form', making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like get_form (form metadata) and list_forms (list of forms) by focusing on submissions. The added detail about including field values and timestamps removes any ambiguity.

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: this tool is for retrieving submissions of a signup form. It doesn't explicitly mention alternatives or exclusions, but the name and scope strongly imply when to use it (when you need submission data rather than form configuration or analytics). No misleading cues are present.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the ordering ('oldest first') and included fields ('sender and timestamps'), which are behavioral details beyond what annotations provide. 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.

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

A single, front-loaded sentence that efficiently communicates the tool's purpose, ordering, and included data. Every word serves a purpose 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 the simple tool (1 parameter, no output schema, no nested objects) and rich annotations, the description is nearly complete. It covers what the tool returns, in what order, and with what fields. The only minor gap is not noting that the response may also include thread structure or metadata, but for a simple retrieval tool this is adequate.

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% with a single required parameter 'conversation_id' well-described as a UUID. The description adds value by making it clear this ID identifies an 'inbox conversation', connecting the parameter to the broader resource context described.

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 uses specific verbs ('Get every message') and clearly identifies the resource ('inbox conversation') with ordering ('oldest first') and included fields ('sender and timestamps'). It distinguishes itself from sibling tools like 'list_inbox_conversations' and 'get_email' by specifying it operates on messages within a single conversation.

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 it's used when you need all messages from a specific conversation in chronological order. It doesn't explicitly state when not to use it or mention alternatives among siblings, but the context of being a read-only tool for a single conversation 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying the exact data returned (configuration, scopes, last sync result), which is valuable since no output schema is provided. This goes beyond the 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.

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

The description is a single, front-loaded sentence with no redundancy. Every word serves a purpose, making it highly efficient and easy to parse.

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 simplicity (one required parameter, no nested objects, no output schema) and the presence of annotations, the description is fully adequate. It tells the agent what the tool does, what it returns, and the single parameter is well documented 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?

Schema coverage is 100% with a single parameter 'integration_id' described as 'Integration ID'. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline expectation 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 clearly states the action ('Get') and the resource ('one integration's configuration, scopes, and last sync result'). It differentiates from sibling tools like 'list_integrations' (which gets all) and 'toggle_integration' (which modifies), leaving no ambiguity about what specific details are retrieved.

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 when you need details of a single integration, contrasting with 'list_integrations' for all integrations. However, it does not explicitly state when not to use or mention alternative tools like 'toggle_integration' for modifications. The context is clear but lacks explicit exclusions.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by enumerating the returned fields (preview, author, install count) beyond the structured fields. No contradictions found.

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 sentence of 14 words with no fluff. It is front-loaded and efficiently conveys the tool's purpose.

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 simple get operation with one parameter and no output schema, the description adequately states the resource and returned fields. It could be more complete by mentioning potential error states or data freshness, but it is sufficiently functional.

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% for the single parameter item_id. The description does not add any additional meaning or context beyond what the schema already provides, so baseline 3 applies.

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 uses the verb 'Get' with the resource 'marketplace listing' and specifies what is returned (full preview, author, install count). It clearly distinguishes from the sibling tool 'list_marketplace_items' which lists multiple items.

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 for retrieving a single item, contrasting with the sibling list tool. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor prerequisites or alternatives.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly safe and idempotent. The description adds specific return data (paid subscribers, MRR, churn, sponsorship revenue) but does not disclose any additional behavioral traits such as response format, pagination, or historical data scope. With annotations covering the safety profile, a 3 is appropriate for the moderate extra context provided.

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 sentence of 14 words, front-loading the purpose and listing key metrics. Every word contributes meaning, and there is no redundancy or fluff. It is a model of conciseness.

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 simplicity (one optional parameter, no output schema) and the presence of annotations, the description adequately covers the purpose and return values. It does not explain the default period or the exact format of the stats, but these are either in the schema or can be inferred. For a straightforward read-only stats tool, this is mostly complete, though a bit more detail on the output structure would help.

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% (the 'period' parameter has a description: 'Time window (default 30d)'). The description reinforces that the stats are 'for the period' but does not add any new meaning beyond the schema. Since the schema already documents the parameter, the baseline is 3, and the description does not improve it.

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 verb 'Get' and the resource 'newsletter monetization stats', listing specific metrics like paid subscribers, MRR, churn, and sponsorship revenue. However, it does not explicitly distinguish this tool from siblings like get_analytics or get_revenue_attribution, which might also provide similar metrics. The purpose is clear but not differentiated, so a 4 is appropriate.

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 does not provide any guidance on when to use this tool versus alternatives. It only states what the tool returns, without indicating prerequisites, exclusions, or when to prefer other tools like get_analytics. Given the large number of sibling tools, this lack of usage guidance is a significant gap.

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?

Annotations already declare readOnlyHint and idempotentHint true, and destructiveHint false, so the description doesn't need to reiterate those. It adds context by naming specific outputs (revenue per campaign, per contact, average order value), which helps the agent understand what to expect. However, no mention of any side effects or limitations (e.g., data freshness, permissions) 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.

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

The description is a single sentence that concisely conveys the tool's purpose and key metrics. It is well-structured and front-loaded with the core action. Every word contributes value, making it efficient and easy to parse.

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 no output schema, the description partially compensates by listing output fields (revenue per campaign, per contact, average order value). Annotations cover safety and idempotency. For a simple read tool with only two parameters, this is minimally complete, but could include more context on data scope or granularity.

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%, with both period (enum, default 30d) and campaign_id (optional filter) well-documented. The description doesn't add new parameter semantics beyond what the schema provides, so 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 states the tool attributes revenue to email and lists specific metrics (revenue per campaign, per contact, average order value). It distinguishes itself from sibling tools like 'get_analytics' and 'get_campaign' by focusing on attribution, but could be more precise about what it doesn't do (e.g., raw analytics).

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 this is for tracking email-driven revenue, providing implicit context for when to use it vs. siblings like 'get_campaign' or 'get_analytics'. However, it lacks explicit guidance on when not to use it or mention of alternatives, which would help an AI agent decide.

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?

The description adds value beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by warning about the consequences of exceeding warm-up capacity. It does not contradict the annotations, and the added context helps agents understand the importance of the tool's output.

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 consists of two concise sentences: the first states the function, and the second adds a crucial warning. No unnecessary words or repetition, and the key information is front-loaded.

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 explains the tool's purpose and importance but lacks details about the return format (e.g., whether it returns a percentage, number, or structured object). Without an output schema, the agent may not know how to interpret the result for downstream decisions, which is a notable 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?

The tool has zero parameters, and schema description coverage is 100% (trivially). Per the guidelines, the baseline score is 4. The description does not need to add parameter meaning, as there are none.

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 'Get IP/domain warm-up progress and today's remaining send capacity,' specifying the exact verb and resource. It distinguishes this tool from siblings like get_deliverability_score and send_campaign by focusing on warm-up status, which is unique among the sibling list.

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 phrase 'Exceeding warm-up capacity on a new domain is the fastest way to get throttled or blocklisted' implies the tool should be used before sending to new domains to avoid issues. However, it does not explicitly state when not to use it or compare it to alternative tools for similar purposes.

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?

Annotations indicate readOnly=false and destructive=false, but the description adds context: it states that existing addresses are updated rather than duplicated and that per-row results are returned, revealing behavior beyond the annotations. This is valuable but does not cover all aspects (e.g., rate limits, transactionality).

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, directly states the key points (bulk limit, update semantics, per-row results) with no filler or redundancy. It is front-loaded and efficient.

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, the description adds essential context about return format (per-row results, rejection reasons). It does not mention prerequisites (e.g., required field email) but the schema covers that. For a bulk import tool, this is reasonably complete.

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 both parameters are already documented. The description restates the max count and update behavior but does not add further detail beyond the schema. Baseline 3 is appropriate since schema carries the parameter burden.

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 function: bulk-import contacts with a defined limit (5,000) and update behavior. It also explicitly distinguishes from create_contact (single) and update_contact (single) by mentioning bulk import and update semantics.

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 for bulk import ('up to 5,000 contacts') but does not explicitly contrast with single-contact tools like create_contact or update_contact. It lacks an explicit 'when to use this instead of alternatives' statement, though the bulk aspect provides implicit 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?

The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, read-only profile. The description adds behavioral detail beyond these annotations by specifying that results include per-variant data and winner selection status. This informs the agent about the return format, which is not covered by 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.

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

The description is a single sentence that immediately states the action and the key output details. It is concise and fits within a reasonable length, with no extraneous 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 a simple interface with three optional parameters, all documented in the schema. The description provides the essential context about what the output contains (per-variant results and winner status), which is important since there is no output schema. However, it does not mention that results are paginated or that the type parameter provides filtering. Given the low complexity and the schema coverage, the description is largely complete but could briefly note pagination and filtering options for extra clarity.

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 input schema has full description coverage (100%), so the schema already documents all parameters (page, type, limit). The description does not add any additional meaning about how to use these parameters. Consequently, it meets the baseline expectation but provides no extra 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 uses the verb 'List' with the resource 'A/B tests' and specifies the returned data: per-variant results and winner selection status. This clearly communicates the tool's purpose and differentiates it from sibling tools like create_ab_test and select_ab_test_winner.

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 indicates usage for retrieving a list of A/B tests with results, but it does not provide explicit guidance on when to use this tool versus alternatives like create_ab_test or select_ab_test_winner. No exclusions or context for filtering are mentioned, so the guidance is minimal.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds key behavioral context beyond annotations: it explicitly states that 'Key secrets are never returned — only metadata,' preventing expectations of sensitive data exposure. This is valuable transparency that annotations alone do not provide.

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 sentence that is front-loaded with the primary purpose and follows with a critical behavioral guarantee. Every word earns its place with no redundancy.

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 no parameters, no nested objects, and no output schema, the description adequately covers the purpose and key behavioral detail (secrets not returned). It is slightly incomplete by not specifying pagination or ordering of results, but for a simple listing tool, this is a minor 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?

The input schema has zero parameters with 100% schema description coverage, meaning the schema fully documents that no parameters are needed. The description does not need to add parameter semantics because there are none. A baseline of 3 applies, and the description's note about returned fields (scopes, last-used time) provides additional helpful context beyond the schema, warranting a higher score.

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 uses a specific verb (List) and resource (API keys), and clearly states what is returned (scopes and last-used time) and what is not (key secrets). It also distinguishes itself from sibling tools like list_contacts or list_domains by specifying 'API keys' and 'on the account'.

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 this is for listing API key metadata, but it does not provide explicit guidance on when to use this vs. alternatives, nor does it mention any prerequisites or when not to use it. There is no exclusion of other methods like creating or deleting keys, which are likely handled by other tools not listed.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly a safe read operation. The description adds minor context by naming workflow types and response fields, but it does not disclose pagination behavior, sorting, or what happens when status filtering is omitted. It does not contradict 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.

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

The description is one concise sentence that front-loads the action and resource, then adds useful examples and output field details. Every phrase earns its place 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?

Given the tool's low complexity, full schema coverage, and strong annotations, the description is sufficiently complete for selecting and invoking the tool. The lack of an output schema is partially mitigated by the mention of 'trigger type and active state', though explicit mention of pagination behavior would make it stronger.

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 input schema already provides 100% coverage for all three parameters: page, limit, and status. The description adds no substantial parameter-level meaning beyond the schema, so the 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 states the verb 'List' and the resource 'automation workflows', with concrete examples like welcome series, re-engagement, and drip sequences. It also specifies the included fields (trigger type and active state), which separates it from sibling tools like list_campaigns and get_automation.

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 makes the primary use case obvious: listing automation workflows along with their status. However, it does not explicitly mention alternatives such as get_automation for detailed single-item lookup or create_automation for creating new workflows. The usage context is clear but lacks explicit exclusions or comparison to related tools.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read operation. The description adds return field context but does not disclose pagination behavior, rate limits, or ordering. This is consistent with the annotation baseline.

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, front-loaded with the primary action and scope, and no filler. The second sentence adds a useful use case without restating schema details. 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 simple read-only list tool with complete schema and safety annotations, the description is nearly complete. It lacks explicit mention of pagination defaults or sorting, but these are inferable from the schema parameters. The description adequately covers the tool's purpose and typical usage.

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?

All three parameters are fully described in the schema (100% coverage), but the description adds meaning by explaining why to use the status filter (find drafts ready to send or campaigns still sending). This goes beyond the enum values and gives practical semantic value.

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 lists email marketing campaigns with specific returned fields (status, audience size, headline metrics). This distinguishes it from sibling tools like get_campaign (single item), create_campaign, or send_campaign, leaving no ambiguity about its purpose.

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 concrete usage context by suggesting filtering by status to find drafts or in-flight campaigns. It does not explicitly name alternatives (e.g., 'use get_campaign for a single campaign'), but given sibling names and this description, the intended use case 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it returns subscription status and engagement metrics, which is useful context beyond annotations, but does not disclose pagination behavior or potential rate limits. This is acceptable 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.

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

The description is two sentences, front-loaded with the core purpose, and 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.

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

For a simple list tool with good schema coverage and idempotent/readOnly annotations, the description covers the key aspects: what it returns, how to filter, and a practical use case. No output schema exists, but the description mentions the fields (subscription status, engagement metrics) which partially covers return info. It is slightly lacking in discussing pagination or total counts but that is addressed by schema parameters.

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?

All four parameters are fully documented in the schema (100% coverage), so the description adds little beyond the schema. The description does not elaborate on parameter usage, but the schema already includes descriptions for each. The baseline of 3 is appropriate because the description does not contradict or add much value.

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 lists contacts and includes specific details about subscription status and engagement metrics, which distinguishes it from generic list tools. It doesn't explicitly compare to siblings, but the context of filtering by status for unsubscribed/bounced addresses is specific enough.

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 a clear when-to-use context: 'Filter by status to find unsubscribed or bounced addresses that should be excluded from sends.' It does not mention alternatives but the sibling list is large and this tool is uniquely about contacts, so the guidance is adequate.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying that results include verification status and DNS records, and by framing the typical invocation scenario. 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 two sentences: the first states purpose and output, the second gives a concrete use case. No redundant words, every sentence serves a purpose.

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 what the tool returns (domains with verification status and DNS records) and when to use it. It lacks explicit mention of the response format (e.g., array), but for a simple list tool this is acceptable, especially given no output schema. Sibling context is clear.

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% (both page and limit are described in the input schema with defaults). The description does not add any additional parameter meaning beyond what the schema already provides. Baseline 3 applies.

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 verb 'List' and the resource 'sending domains', specifying the included fields (verification status, DKIM/SPF/DMARC records). It also provides a specific use case (check when a send fails with unverified-sender error), which distinguishes it from siblings like check_dmarc or verify_domain.

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 includes explicit guidance: 'Check here first when a send fails with an unverified-sender error.' This gives a clear context for use. While it doesn't list alternatives or exclusions, the context is strong 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safe read-only nature. The description adds some functional context (mailbox folder, optional search) but does not describe return shape, pagination behavior, or sorting. This is adequate but not enriched 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.

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

Two concise sentences with no filler. The first sentence states the core function, and the second provides a direct pointer to an alternative tool. 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 simple read-only listing tool with three optional parameters and strong annotations, the description covers the key context: what is listed, where it is listed from, optional search, and when to use a different tool. No output schema exists, but the tool's behavior is straightforward enough that this is acceptable.

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%, and each parameter already has a meaningful description. The tool description adds minimal semantic value beyond the schema, mentioning full-text search and mailbox folder but not providing new parameter-level detail. Baseline 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 states the tool 'List emails from a mailbox folder with optional full-text search across subject and body', using a specific verb and resource. It distinguishes itself from the sibling tool list_campaigns by explicitly directing marketing sends elsewhere.

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 explicit usage context: 'Use this for reading the unified inbox; use list_campaigns for marketing sends.' This names an alternative and clarifies when not to use this tool, giving clear guidance beyond what the schema alone provides.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying the return fields (embed status, conversion counts) and implies a paginated list, which is beyond what annotations provide. 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.

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

The description is a single sentence that efficiently conveys the tool's purpose and key return data. It is front-loaded with the verb and resource. While concise, it could benefit from slight structural separation (e.g., 'List signup forms. Returns embed status and conversion counts.') but is still effective.

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 simple list tool with good annotations and full parameter documentation, the description is mostly complete. It states what the tool returns. Minor gaps: no mention of default sort order or that it returns a paginated array. Given no output schema, a bit more detail would enhance completeness.

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%: all three parameters (page, limit, status) are explained in the input schema. The description does not add additional parameter context, so baseline 3 is appropriate. It neither enhances nor detracts from schema clarity.

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 uses a specific verb ('List') and resource ('signup forms') and states the exact data returned ('embed status and conversion counts'). This clearly distinguishes it from the sibling 'get_form' (which retrieves a single form) 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.

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

The description implies usage for listing forms with summary stats, but does not explicitly state when to use this tool versus alternatives like 'get_form' or 'get_form_submissions'. No 'when-not' guidance is provided, leaving some ambiguity for the agent.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about unified-inbox and detected intent, indicating the tool provides an overview. It does not contradict annotations. However, it does not detail pagination behavior or access scope, but with strong annotation coverage, this is a minor gap.

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-loading the core purpose and then providing usage differentiation. Every sentence adds value; no filler or redundancy.

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?

With 6 parameters and no output schema, the description sufficiently explains the tool's purpose and filtering options. It mentions return fields (status and intent) but lacks explicit return format or pagination details. Given the complexity, it is mostly complete for an AI agent to use effectively.

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?

All 6 parameters are fully described in the input schema (100% coverage). The tool description does not add new meaning beyond what the schema already provides, so baseline 3 is appropriate. No additional semantic benefit is gained from the 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 the tool lists unified-inbox conversations (threads) with status and detected intent, and distinguishes from sibling tool 'list_emails' by specifying it is for individual messages in a folder. The verb 'List' plus the resource 'conversations' is 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.

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

The description gives explicit usage guidance: 'Use this for triage; use list_emails for individual messages in a folder.' This directly tells when to use this tool and when to use an alternative, making the selection clear for an AI agent.

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?

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds value by mentioning 'sync status', which hints at the tool's output beyond what annotations provide. However, it does not disclose pagination behavior or rate limits, but overall it is sufficient given the 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 a single, concise sentence with no wasted words. It is front-loaded with the key action and resource, and the sync status detail adds value without bloat.

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 no output schema, so the description should compensate by explaining the response structure. It mentions 'sync status' but does not describe what fields are returned (e.g., integration name, status, last sync). For a simple list tool, this is a moderate 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?

Input schema has 100% description coverage for both parameters (page and limit). The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate as the schema does the heavy lifting.

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 lists connected third-party integrations and their sync status. It uses a specific verb ('List') and resource ('connected third-party integrations'), effectively distinguishing it from sibling tools like 'get_integration' (single integration) or 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.

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

The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_integration' for a single integration). It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add context. It does so by specifying that the operation pertains to a 'marketplace' of templates. However, it does not elaborate on pagination behavior, request rate limits, or whether the result reflects live external data, which would be valuable 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.

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

The description is a single, clear sentence with no fluff. It is front-loaded and quickly conveys the tool's purpose. It could be slightly more informative (e.g., mention that results are paginated), but it is appropriately sized for a simple list operation.

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 optional parameters but no output schema. The description does not clarify the default behavior of pagination, ordering, or exactly what fields are returned for each item. Given the simplicity of listing marketplace items, the description is minimally adequate but leaves the agent guessing about pagination and filtering behavior beyond 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?

Schema coverage is 100%, so each parameter already has a description (page, limit, search, category). The tool description adds no additional parameter-level meaning beyond restating 'marketplace' context. With full schema coverage, a score of 3 is appropriate as the description does not compensate for any gaps.

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 uses a specific verb 'Browse' and identifies the exact resource: 'MisarMail template marketplace' with the content type 'ready-made email and automation templates'. This clearly distinguishes it from sibling tools like list_templates (user's own templates) and get_marketplace_item (single item).

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?

No explicit guidance on when to use this tool versus alternatives. While the name and sibling list suggest differentiation, the description does not mention that this is for exploring community templates rather than user-created ones, nor does it provide any exclusion criteria or prerequisites.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's role is reduced. It adds context about the sandbox intercept mechanism, but does not disclose new behavioral traits beyond what annotations provide. 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?

Two sentences, front-loaded with the action. Every word adds value: 'List emails captured by sandbox mode' and then the explanatory context. No wasted words or redundancy.

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 parameters, no output schema, and a simple list operation, the description is fully complete. It explains what the tool returns (emails captured by sandbox) and why it matters (for verifying templates/automations without delivery).

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 input schema has zero parameters, and schema description coverage is 100%. Baseline for 0 params is 4. The description does not need to add param info; it explains the tool's purpose sufficiently without parameter details.

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 verb 'List' and resource 'emails captured by sandbox mode', distinguishing it from sibling tools like 'list_emails' and 'clear_sandbox'. It explains the sandbox mechanism, making the purpose immediately understandable.

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: 'use it to verify templates and automations without emailing anyone.' It implies this is for testing, not for production sends, but does not explicitly name alternative tools. The usage guidance is strong but lacks direct sibling differentiation.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that templates have variable placeholders, which informs the agent about the data content. This extra context goes beyond annotations and enhances transparency 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.

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

The description is a single, efficient sentence that front-loads the core purpose and includes a practical use case. 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?

Given the tool's simplicity, read-only nature, and comprehensive schema, the description is adequate. It mentions the output concept (variable placeholders) and provides use-case context. No explicit output schema exists, but the description covers what the agent needs to know for selection.

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 all parameters (page, type, limit) are already documented with descriptions. The tool description does not add any additional parameter semantics, but the baseline of 3 is appropriate since the schema does the heavy lifting.

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 verb 'list' and the resource 'saved email templates', adding the specific detail of including variable placeholders. It distinguishes itself from sibling tools like list_emails or list_campaigns by emphasizing the template-specific content.

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 clear usage context: 'so you can pick one for a campaign or transactional send' tells the agent when to use this tool. It doesn't explicitly mention alternatives or when not to use it, but the purpose is unambiguous.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful context about returning HTML and subject and previewing personalisation, but does not go beyond that to discuss authentication, rate limits, or edge-case behavior. This is 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.

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

Two concise sentences, front-loaded with the action and output, with no redundant filler. Every phrase 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 simple two-parameter preview tool with strong annotations, the description is nearly complete. It explains the purpose, output, and non-sending nature. The only minor gap is that 'sample variables' could be slightly ambiguous, but the schema clarifies the variable structure.

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 both parameters are already documented. The description mentions 'sample variables' and the output, but adds little semantic meaning beyond what the schema provides.

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 uses a specific verb ('Render') and resource ('a template'), and clearly states the output ('resulting HTML and subject'). It also distinguishes itself from sending tools by framing the action as a preview before sending.

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 use this tool 'to preview personalisation before sending anything,' providing clear usage context. It does not name alternative tools or explicit exclusions, but the guidance is sufficient for typical 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?

Annotations already indicate a non-read-only, non-destructive operation with potential side effects (openWorldHint). The description adds context that sender/threading are auto-derived, but does not detail what happens with body content, authentication, or response behavior. This adds some value beyond annotations 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.

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

The description is a single, concise sentence that front-loads the purpose and adds meaningful context. Every word earns its place, 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 the simple tool (3 params, no output schema, no nested objects) and full schema coverage, the description is adequate. It explains the crucial threading derivation but omits details like whether only one body type is needed, what happens without a body, or any constraints. For the complexity, this is reasonably complete.

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 clarifies that threading headers are derived and 'only the body is required,' but this slightly conflicts with the schema requiring email_id. It adds some meaning but introduces ambiguity about required fields, so it does not fully elevate above 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 states the action ('Reply to an existing email thread') with a specific verb and resource, distinguishing it from sending new emails (e.g., send_email, send_campaign) and other email operations. The mention of derived sender/threading info further clarifies its scope.

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 when to use this tool (when replying to an existing thread) and provides context about automatic threading, but it does not explicitly name alternatives or specify when not to use it. This is a clear context without exclusions, fitting a score of 4.

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?

Annotations already declare the tool as readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only 'Returns prioritized findings,' which modestly informs outcome but does not disclose any additional behavioral traits such as execution time, rate limits, or prerequisite conditions. Given the rich annotations, the description provides acceptable but minimal added transparency.

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 totaling 23 words, with no redundancy. The first sentence immediately conveys the broad scope, and the second sentence succinctly describes the output format. Every word is purposeful.

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 no input parameters, the description covers the areas inspected (authentication, reputation, hygiene, content, blocklist) and states it returns prioritized findings. It is nearly complete but lacks mention of any prerequisites (e.g., domain verification) or error conditions, leaving minor gaps. Still highly functional for an agent.

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?

There are zero parameters, and the schema coverage is 100%. According to the guidelines, with 0 parameters the baseline is 4. The description does not need to add parameter meaning since none exist, and it correctly omits any parameter-related text.

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 a specific verb ("run") and resource ("deliverability audit"), and enumerates the components (SPF/DKIM/DMARC authentication, domain reputation, list hygiene, content signals, blocklist) that distinguish it from sibling tools like check_dmarc, validate_email, or get_deliverability_score, which are narrower in scope.

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 does not provide any guidance on when to use this comprehensive audit versus the many sibling tools. For example, it does not say 'use this for a full assessment' or contrast it with simpler checks like get_deliverability_score. The context signals include sibling names, but the description itself offers no comparative 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?

Annotations already mark destructiveHint=true. The description adds context by stating 'triggers a real send' and 'cannot be undone', reinforcing the irreversible nature. It does not contradict annotations and provides meaningful 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.

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

Two sentences, front-loaded with the core action, no extraneous words. Every sentence earns its place by stating the action and its irreversible consequence.

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 action and consequence, but does not mention expected return values, prerequisites (e.g., test state), or error conditions. Given no output schema, slightly more detail on outcome would improve completeness.

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 schema already documents all parameters (test_id, winner_variant, metric). The description adds no additional meaning or guidance for any parameter, achieving only 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 states the tool selects a winning variant and sends it to the remaining audience, using a specific verb and resource. It distinguishes from siblings like create_ab_test and list_ab_tests by focusing on the selection and execution step.

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 this is the final action in an A/B test (triggering a real send) and warns it cannot be undone, but it does not explicitly state when not to use it or suggest alternative tools for previewing or cancelling.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds crucial context: it delivers real email, cannot be undone once sending starts, and recommends pre-confirmation. This goes beyond the annotations, though it could also mention rate limits or permission requirements.

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, each value-dense. The first states the action and the second provides risk warning and a safety tip. No fluff or redundancy; perfectly concise.

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 simplicity (2 params, no output schema) and the strong annotations, the description is largely complete. It covers the key behavioral risk and a usage guideline. Slight gaps: no mention of what happens after sending (e.g., confirmation response) or potential errors, but these are minor given the context.

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 schema documents both parameters well. The description reinforces the function of 'scheduled_at' (scheduling future time) but does not add details like timezone handling or validation rules. Baseline 3 is appropriate since the schema is sufficient.

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 uses a clear verb ('Send') and resource ('campaign'), explicitly states the action (send now or schedule), and distinguishes itself from siblings like 'send_email' and 'create_campaign' by focusing on the execution of a campaign. It also highlights the irreversible nature of the action.

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 when to use this tool (when ready to send a campaign) and explicitly advises confirming the audience with 'get_campaign' first. It does not explicitly state when NOT to use it or list alternative tools, but the guidance to confirm audience 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.

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

No annotations, so description must carry the load. It discloses the verification requirement Link and mentions return of message ID/queue status. Missing rate limits and explicit side effects, but the essential behavior (send, verify sender, queue) is covered.

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, front-loaded with the essential purpose mud plus the key prerequisite and outcome. No fluff.

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?

Rich schema covers parameter details; description adds the verified-sender requirement and return value (message ID/queue). Could mention rate limits or failure formats, but given the schema's depth, coverage is sufficient for invocation.

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 already documents all 12 parameters with meaningful descriptions (format, max sizes, constraints). The description adds only the 'from' verification linkage, which is also in the schema. At 100% coverage, description adds minimal extra value, so baseline 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?

Clear verb+resource: 'Send a transactional email'. The qualifier 'transactional' distinguishes from campaign-send siblings like send_campaign. Mentions the source (verified MisarMail account), tying directly to the 'from' constraint.

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 actionable prerequisite guidance: 'use list_domains to check which sender domains are available'. No explicit when-not-to-use, but the verification check addresses the main failure mode. Could mention alternatives (e.g., template-based sends) but not necessary.

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?

Annotations provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds behavioral context by explaining that activation 'starts enrolling contacts and sending on the configured schedule,' which goes beyond the annotations. However, it does not describe pausing effects or potential side effects, keeping it from a 5.

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, highly concise and front-loaded with the core action. Every word adds value with no redundancy or fluff.

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 simple parameter set (2 required) and no output schema, the description is mostly complete. It explains the effect of activation and implies pausing. Could note return behavior or success/error signals but is adequate for a straightforward toggle 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% with both parameters (active, automation_id) described. The description adds no additional parameter information beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Activate or pause an automation.' It specifies the verb (toggle) and resource (automation), and distinguishes from siblings like get_automation (read) and create_automation (create) by indicating state change.

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 using this tool to start or stop an automation but does not explicitly state when to use it versus alternatives like get_automation for status checks or create_automation for new automations. No exclusion or comparative guidance is provided.

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?

The annotations already indicate idempotentHint: true and destructiveHint: false, and the description explains that disabling stops syncing but preserves credentials. This adds context beyond annotations, but does not disclose if enabling triggers immediate sync or if there are 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 two sentences, front-loaded with the primary action, and the second sentence adds a key behavioral detail. 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?

Given the tool has no output schema and annotations provide some safety cues, the description adequately covers the core behavior. However, it lacks mention of what happens on enable (e.g., does it start syncing immediately?) and whether this action is reversible.

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 schema fully documents both parameters. The description does not add additional semantics beyond what the schema provides for 'enabled' and 'integration_id'. 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 states the tool toggles an integration on or off, specifying the action and what 'disable' does (stops syncing). This distinguishes it from siblings like toggle_automation and configure_inbound_domain.

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 does not provide guidance on when to use this tool versus alternatives like toggle_automation, nor does it mention prerequisites (e.g., integration must already exist). It only describes the effect of disabling.

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?

The description discloses a key behavioral trait: setting status to unsubscribed immediately excludes the contact from future campaigns. This adds value beyond the annotations, which only indicate idempotentHint and non-destructive. 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.

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

The description is two sentences, front-loaded with the main purpose, and includes a critical behavioral note. 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?

Given the tool has 9 parameters, 100% schema coverage, and no output schema, the description is sufficient. It explains the main action and a key side effect. It could mention that it replaces tags (as per schema) but that is already in the schema. Overall, 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 has 100% description coverage for all parameters, so the description does not need to add much. It mentions 'including changing subscription status' which highlights the status parameter, but the schema already describes each parameter. Baseline 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 states the tool updates an existing contact by email address and can change subscription status. It distinguishes from create_contact and list_contacts by specifying 'existing contact' and the update action.

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 for updating contact details and subscription status, but does not explicitly mention when not to use it or alternatives. However, the context of updating an existing contact is clear, and the sibling tools like create_contact provide contrast.

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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds the key behavior of opening the checkout page in the browser when open=true, and clarifies that this is a general status/upgrade info tool. It does not contradict annotations and adds useful context about the optional side effect.

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 three sentences, front-loaded with the main purpose. Every sentence provides distinct value: what it shows, when to call it, and the key parameter behavior. No fluff or redundancy.

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 2 optional parameters, full schema coverage, strong annotations, and no output schema, the description is complete. It explains the primary purpose, usage timing, and the optional browser-opening behavior. Nothing essential is missing.

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 does not add any parameter semantics beyond what the schema already provides. It mentions 'open=true' but that is exactly what the schema says. There is no bonus for repeating schema content.

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 uses a specific verb 'Show' and clearly states the resource (current MisarMail plan, quota usage, and what upgrading unlocks). It distinguishes the tool from siblings by focusing on plan and upgrade context, which is unique among the listed 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?

The description gives explicit when-to-use guidance: 'Call it any time — not only after hitting a limit.' It does not mention alternatives or exclusions, but for this tool it is clear enough. A 5 would require explicit alternatives or when-not-to-use, so 4 is appropriate.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe read-only nature is known. The description adds value by detailing what the validation covers (syntax, MX, disposable, role-account), which is not in the 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.

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

The description is two sentences: the first defines purpose and scope, the second provides usage context. Every sentence is informative with no filler words or repetition.

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 simplicity (one param), the schema covers the parameter, annotations cover safety, and the description explains validation logic. The only missing piece is the return format (e.g., boolean vs. structured result), but that is a minor gap given the tool's nature. Overall, 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.

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

The schema has 100% coverage for the single parameter 'email' with description 'Email address to validate'. The tool description does not add any extra parameter-specific meaning beyond the schema, so the 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 states the verb 'Validate' and the resource 'email address', and enumerates specific checks (syntax, MX records, disposable-domain, role-account detection). This makes it distinct from sibling tools like check_dmarc or verify_domain, which focus on different aspects.

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 clear scenarios: 'before sending' and 'Use this to protect sender reputation on imported lists.' It does not explicitly mention when not to use or alternatives, but the context is clear enough for an agent to decide. The usage guidance is practical and specific.

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?

The description adds useful behavioral context beyond annotations: it mentions the 'mark it verified' side effect (consistent with readOnlyHint=false) and explains that retries are safe due to DNS propagation. This complements the idempotentHint=true annotation without contradicting any annotation.

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, front-loaded with the core purpose, and every sentence adds value. It efficiently conveys the action, condition, and retry guidance without any waste.

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 simple nature of the tool (one parameter, clear annotations, no output schema), the description is nearly complete. It explains what happens on success ('mark it verified') and the retry rationale, though it does not detail the behavior when DNS does not resolve. This is a minor gap 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.

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

The schema fully documents the only parameter (domain_id) with a clear description ('Domain ID returned by add_domain'). The tool description does not add additional meaning beyond the schema, so the baseline 3 applies.

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 action ('Re-check a domain's DNS records'), the resource (domain's DNS records), and the outcome ('mark it verified if they resolve'). It differentiates from siblings like add_domain (domain creation) and check_dmarc (DMARC-specific check) by focusing on domain verification.

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 the tool: re-checking DNS records after a domain has been added, with a note on DNS propagation time. It implies this is a follow-up to add_domain but does not explicitly name alternatives or exclusions, so it stops 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.