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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Add', which implies a mutation, but does not explain whether adding is idempotent, whether it replaces an existing forwarding address, whether it triggers any verification, or what the result of the operation is.

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 states the core purpose without unnecessary detail or repetition. It is well 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?

For a simple three-parameter creation tool with a fully documented schema, the description is minimally viable. However, because there are no annotations and no output schema, it would be stronger to mention likely duplicate behavior, whether the mailbox must already exist, or the operational effect of the forwarding rule.

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 parameters are already well documented in the schema. The description itself adds no parameter-level meaning beyond what the schema provides, 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 states a clear verb ('Add') and resource ('a forwarding address to a mailbox'), and the sibling tools list_forwards and remove_forward make the operation distinct. An agent can immediately understand this creates a forwarding relationship rather than listing or removing one.

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. It does not mention that list_forwards is for viewing existing forwards or that remove_forward is for deleting them, nor does it state any prerequisites such as the mailbox needing to exist.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It reveals the critical behavior that the full key is returned exactly once and cannot be retrieved again, and instructs the agent to surface it immediately. This is essential operational context, though it doesn't detail other side effects like rate limits or whether existing keys remain valid.

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 filler. The core action is front-loaded, followed by the critical one-time-display warning and the separation best practice. Every sentence earns its place and the description is easy 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?

For a tool with zero parameters and no output schema, the description covers all essential context: what it does, the one-time key disclosure, and how the user should handle the key. There is no missing information an agent would need to invoke this tool correctly and guide the user.

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, so there are no parameter semantics to describe. The description adds context about per-environment key usage, which is more guidance than parameter explanation. Baseline of 4 is appropriate for a schema with no parameters.

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?

Description states the exact action and resource: 'Create a new API key.' This clearly distinguishes it from siblings like list_api_keys and revoke_api_key, which have different verbs and resources. No ambiguity about what the tool does.

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 actionable guidance: surface the key immediately because it's shown only once, and mint separate keys per environment/service rather than sharing one. It doesn't explicitly name alternatives or when not to use this tool, but the context is clear and no competing sibling creates API keys.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. 'Add a contact' only implies a mutation; it does not disclose whether duplicate emails are handled, whether existing contacts are affected, what response is returned, or any side effects such as creating additional resources.

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 and front-loaded, with no unnecessary words. However, it is so minimal that it borders on under-specification, though that issue is more relevant to other dimensions.

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 mutation tool with no annotations, no output schema, and one undocumented parameter, the description is not complete enough. An agent gets no information about response behavior, uniqueness constraints, or required versus optional fields beyond what the schema already states.

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 description adds no parameter-level meaning beyond the schema. Schema coverage is only 50%: email is described, but the name parameter is undocumented in both the schema and the description, so the description fails to compensate for the missing parameter semantics.

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 ('Add') and resource ('a contact'), making the operation clear. It is not a tautology and is distinguishable from sibling tools like list_contacts, update_contact, and delete_contact, though it lacks any detail about what a contact consists of.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention that this is for creating a new contact, that update_contact should be used for modifications, or any criteria for choosing between 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?

With no annotations, the description carries the full disclosure burden. It usefully reveals that the tool never modifies DNS itself, a significant behavioral trait beyond the simple 'create' verb, and it discloses the return contents: DNS records and a setup recommendation. This is strong transparency for a single-parameter 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?

Two sentences are economical and front-loaded: the core purpose appears immediately, and the crucial caveat (no DNS modification) is placed clearly. No word is wasted.

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 one simple parameter and no output schema, the description adequately explains what happens and what the agent receives. It also covers the key behavioral boundary and the necessary follow-up action, making it fully 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 input schema documents the only parameter, domain, with a clear format example. With 100% schema coverage, the description does not need to add much; it simply references the domain but does not go beyond the schema's meaning.

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—register a domain—and specifies the resource ('a domain') and the outcome (returns exact DNS records and setup recommendation). It clearly distinguishes itself from sibling tools like verify_domain or delete_domain by naming its unique role and boundary.

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 tool to register a domain and obtain DNS records, then add those records yourself. It also tells the agent what it must do afterward, though it does not explicitly name alternatives or say when not to use the tool.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose a key behavioral trait: drafts are not sent through mail transport until explicitly sent. However, it does not mention persistence, idempotency, required mailbox existence, or any side effects beyond creating the draft.

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 filler. The primary action is front-loaded, and the clarifying sentence about mail transport is concise and valuable.

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

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

For a tool with six parameters, no output schema, and no annotations, the description is too thin. It explains the draft concept but omits guidance on how to populate the optional fields, what the draft creation returns, or any constraints such as mailbox existence and recipient formatting.

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 only 33%, with domain and localPart explained but the other four parameters (to, html, text, subject) left undocumented. The description adds no parameter-level meaning beyond the schema, so it fails to compensate for the low 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: 'Create a draft on a mailbox.' It also distinguishes this tool from sending mail by explaining that a draft 'never goes through mail transport until sent,' which separates it from sibling tools like send_email and update_draft.

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 useful conceptual context, especially the contrast between a draft and a real message, but it does not explicitly name alternatives or state when to prefer create_draft over send_email or update_draft. The usage guidance is implied rather than explicit.

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

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

With no annotations, the description must carry the full behavioral disclosure burden. It conveys that the tool creates a folder, which is a mutation, but gives no details on permissions, idempotency, duplicate-name handling, or effects on existing folders – significant gaps for a mutation tool.

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

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

A single concise sentence with no filler words; information is front-loaded. However, it is so terse that it sacrifices potentially useful operational detail, though that is more a completeness issue than a structure issue.

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 three required parameters, no annotations, and no output schema, the description is too sparse. It does not state what response to expect, error conditions, or whether the mailbox must already exist, so an agent lacks key context for a successful 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?

The schema already documents domain and localPart, while name is left undescribed. The description's 'custom folder on a mailbox' implicitly ties name to the folder label but does not explicitly define it or explain how the parameters relate, so it adds limited 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 a creation action ('Create') with a specific resource ('custom folder') and scope ('on a mailbox'), distinguishing it from sibling folder operations like list_folders and delete_folder. It lacks an explicit definition of what a custom folder is, but the intent is 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?

No when-to-use or alternative guidance is provided. The description does not mention prerequisites such as the mailbox already existing, nor does it contrast with create_mailbox, list_folders, or delete_folder, leaving the agent to infer usage solely from the verb.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool returns real IMAP/SMTP AUTH credentials, that a strong password is auto-generated if omitted, and that this generated password is only shown once and cannot be recovered later, only reset. This is precisely the kind of behavior an agent needs to know before invoking the 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?

Three sentences, each with a distinct job: scope and prerequisite, output and use case, and critical password behavior. No filler, no repetition, and the most important operational details are 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?

Given the absence of an output schema and annotations, the description covers everything needed to call the tool correctly: what it does, the prerequisite domain registration, the required and optional parameters, the return value, and the crucial one-time-password behavior. There are no obvious operational gaps for this level of 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 already describes all three parameters with useful examples, so the baseline is 3. The description adds meaningful context beyond the schema by emphasizing that the domain must already be registered and by explaining the password auto-generation and one-time return behavior. That lifts it above the baseline.

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

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

The description opens with a specific verb-resource pair ('Create a mailbox') and gives a concrete example (hello@example.com). It explicitly ties the operation to create_domain, which distinguishes it from sibling tools like list_mailboxes, delete_mailbox, and reset_mailbox_password.

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 clearly states the prerequisite: the domain must already be registered via create_domain. It also gives a practical use case (adding to mail clients) and notes that a lost password is only resettable, implicitly pointing to reset_mailbox_password. However, it does not explicitly name alternative tools or state when not to use it, so it falls just 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?

No annotations are provided, so the description carries the full burden of explaining consequences. 'Delete a contact' states the basic action but does not disclose whether the deletion is permanent, whether related data is affected, or what the tool returns after success.

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, uncluttered sentence with no filler or redundant content. It is front-loaded and 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?

The tool is simple with one clearly documented parameter, so the core callable information is present. However, missing caveats about irreversibility and the absence of any usage or behavioral context keep it at the minimum viable level rather than fully 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%, and the schema already documents the parameter as 'Contact id, from list_contacts.' The description adds no parameter-level meaning beyond the schema, which is acceptable given full 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 names a precise action ('Delete') and a precise resource ('a contact'), which unambiguously distinguishes this tool from sibling delete_* tools such as delete_domain, delete_mailbox, and delete_message. It is direct and leaves no doubt about what operation the tool performs.

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?

There is no guidance about when to use this tool versus alternatives, and no mention of prerequisites or adjacent operations like updating or creating a contact. The agent must infer usage solely from the tool name and description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the operation is destructive, cascades to every mailbox and message, is hard to reverse, and requires upfront user confirmation. This is exactly the critical behavioral information an agent needs before invoking a high-impact deletion 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 concise sentences with no filler. The first sentence states the action and consequence, and the second adds an essential safety guardrail, making the most important information 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 tool has a single required parameter, no output schema, and no annotations, but the description provides sufficient guidance for correct invocation: what is deleted, what else is affected, and the need for confirmation. Nothing essential is missing for an agent to call it safely.

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 the schema already explains the domain parameter with an example ('example.com'). The description adds no additional parameter semantics beyond what the schema provides, which is acceptable given the high 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 names a specific verb ('Delete') and resource ('a domain') and clearly distinguishes this from delete_mailbox by stating that every mailbox and message under the domain is also removed via cascade. An agent can immediately understand the tool's scope and impact.

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 operational context by warning that the operation is destructive, hard to reverse, and requires user confirmation before calling. It does not explicitly name alternative tools such as delete_mailbox or state when not to use it, but the cascade wording makes the appropriate use case obvious.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Delete a draft.' It does not state that deletion is permanent, cannot be undone, whether ownership or permissions are required, or what happens to related resources. The destructive nature is implied by the verb but not elaborated.

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 filler or redundancy. Every word earns its place. It is appropriately sized for such a simple tool, though it is perhaps too terse to be considered excellent.

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 low-complexity tool with fully documentd parameters and no output schema, 'Delete a draft.' is minimally viable. However, because there are no annotations and the operation is destructive, the description would be more complete if it disclosed irreversibility or side effects. This is a clear but not severe 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?

All three parameters are documented in the schema with meaningful examples: id is described as coming from list_drafts, and domain/localPart are illustrated with example.com and hello@example.com. The description adds no parameter-level information, but because schema coverage is 100%, 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 states a specific verb and resource: 'Delete a draft.' It is immediately clear what this tool does and how it differs from the sibling draft-related tools like list_drafts, get_draft, create_draft, and update_draft. No ambiguity remains about the intended operation.

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 offers no guidance on when this tool should be used instead of alternatives, such as update_draft or send_email. There are no stated preconditions, no mention of irreversibility, and no explicit 'use this when...' context. Agents must infer entirely from the name.

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

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

With no annotations provided, the description carries the full behavioral burden. It clearly discloses that deleting the folder does not delete the messages inside and that they will appear in their normal Inbox/Sent view. This goes beyond a generic 'delete' statement and helps the agent predict consequences accurately.

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 filler. The main action is stated first, followed by the key exception about mail retention. 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 three-parameter delete operation with no output schema and 100% schema coverage, the description covers the essential context: what is deleted and what is not. It doesn't mention irreversibility, but that is generally implied for delete operations and the schema already tells the agent where to get the id.

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 provides 100% coverage, including an explanation of id ('from list_folders') and clear examples for domain and localPart. The description adds no new parameter-specific information, 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 opens with the specific verb 'Delete' and the resource 'a custom folder', immediately distinguishing this tool from message or mailbox deletion. It also adds a clarifying contrast ('Does not delete the mail in it'), which eliminates ambiguity about what is actually removed.

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 tool's scope clear: it deletes custom folders only, and tells the agent what will happen to contained messages. While it doesn't explicitly name alternatives like delete_message or create_folder, the context of custom folders and the folder-specific behavior makes the appropriate usage obvious.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals two key side effects: Postfix immediately stops accepting mail, and already-delivered mail is not deleted. The explicit confirmation requirement also signals the destructive nature, providing strong transparency beyond the schema.

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

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

The description is concise and front-loaded, with the core action stated first followed by three impactful behavioral notes. Every sentence earns its place—no filler or redundant restating of the schema fields.

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 two-parameter destructive tool with no output schema and no annotations, the description covers the essential behavioral aspects: action, immediate effect, limitation, and confirmation requirement. Minor gaps like reversibility or error conditions are not addressed, but the description is sufficiently complete for correct 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 description coverage is 100%, with domain and localPart both clearly documented in the input schema. The description adds no additional parameter-level detail, but the schema already fully covers semantics, warranting the baseline 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 opens with 'Delete a mailbox,' a precise verb+resource statement that clearly identifies the operation. It further distinguishes itself from sibling tools by detailing the immediate effect on Postfix and the scope limitation about already-delivered mail, leaving no ambiguity about what this tool does.

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 contextual guidance by instructing 'Confirm with the user before calling this,' which is critical for a destructive operation. While it does not explicitly name alternative tools or when-not-to-use conditions, the behavioral notes about stopping mail delivery and preserving delivered mail implicitly define when this tool 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does add a useful consequence ('new mail stops firing it immediately'), showing an immediate effect, but it does not mention irreversibility, idempotency, error behavior, or what happens if no webhook exists. This is a meaningful but incomplete disclosure for a destructive operation.

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

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

A single sentence with no filler. It states the action, the resource, and the immediate behavioral consequence in a compact and readable way.

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 delete tool with fully documented schema, the description is adequate. It captures the essential effect. It could be stronger by noting whether removal is permanent or by describing the result when no webhook is configured, but these are minor gaps for this tool's 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 covers 100% of parameters with clear descriptions and examples for both domain and localPart. The description adds no extra parameter-level detail, which is acceptable given the 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 clear verb ('Remove') and a specific resource ('a mailbox's webhook'), which directly distinguishes it from sibling tools like set_mailbox_webhook and get_mailbox_webhook. There is no ambiguity about what the tool does.

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 clearly implies the use case: when you want to stop a webhook from firing on new mail. It does not explicitly name alternatives or exclusion conditions, but the context and sibling list make the intended purpose obvious.

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

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

With no annotations present, the description carries the full burden of disclosing behavior. It clearly states the two-stage delete flow, the irreversibility of the second call, and that the stored body is permanently removed. It also flags the need for user confirmation, which is essential safety information for a destructive operation.

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

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

Three sentences, each earning its place: the first states the action, the second explains the two-stage process, the third adds a safety requirement. It is front-loaded and compact without sacrificing critical nuance.

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 destructive tool with no annotations and no output schema, the description is remarkably complete. It explains the staged behavior, the permanent nature, the consequence for the stored body, and the user-confirmation requirement. Nothing essential is missing for an agent to select and invoke it 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 input schema already documents the single required parameter 'id' with its source (list_messages or get_thread) at 100% coverage. The description reinforces the delete lifecycle but doesn't add new parameter-level semantics beyond the schema. Baseline 3 is appropriate since the schema handles parameter documentation fully.

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

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

The description opens with a specific verb and resource, 'Delete a message', and immediately clarifies the two-stage nature (Trash then permanent delete). This clearly distinguishes it from sibling tools like delete_mailbox or delete_draft, since the target is explicitly a message.

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 procedural guidance: first call moves to Trash, second call on an already-trashed message permanently deletes it. It also instructs the agent to confirm with the user before a permanent delete, which is a critical usage rule. While it doesn't name alternatives, the message-scoped behavior is unambiguous and complete for 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 no annotations provided, the description carries the behavioral disclosure burden, and it does so well: it reveals the base64-encoded return format, instructs the agent to decode it, and warns that the content can be large. It does not cover failure modes or rate limits, but for a simple read operation the key behaviors are disclosed.

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

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

Two compact sentences deliver the core action, return format, decoding step, size caveat, and usage guidance. There is no redundant or filler content, and the most important 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?

For a two-parameter tool with fully described schema fields, the description covers everything an agent needs to select and invoke it correctly: the operation, the output encoding, the size risk, and the alternative to use for metadata-only checks.

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 fully documents both id and index. The description adds only marginal parameter context by referencing the attachments array, but it does not materially extend what the schema already 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 opens with a specific verb and resource: 'Download one attachment from a message.' It clearly distinguishes this tool from sibling get_message by noting that get_message's attachments array already provides metadata, making the tool's unique purpose obvious.

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 states when to prefer this tool—'only when the file content is actually needed'—and when not to use it (just checking existence), pointing to get_message as the lighter-weight alternative. This gives the agent clear decision criteria.

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

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

With no annotations, the description carries the burden, and it discloses the data source (Mektup's Postfix delivery log), what the counts represent (real SMTP responses), and the aggregation scope. It does not mention permissionns, rate limits, or exact return formatting, but for a read-only stats tool the core behavioral semantics are transparent.

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

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

One dense sentence that front-loads the core action and then adds the key provenance caveat; every clause earns its place and there is 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?

No output schema exists, but the description effectively summarizes what the response will contain (counts of sent/deferred/boounced/unknown) and scopes it to a mailbox and time window. It is lightly light on output shape and edge cases, but nothing essential is missing for calling 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?

Input schema coverage is 100%, so the schema already documents 'days' and 'mailbox' clearly; the description only restates the time-window and mailbox concepts without adding format, default, or constraint details. This meets the baseline but adds little 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 opens with a specific verb and resource ('Aggregate delivery outcomes for a mailbox's outbound mail') and enumerates the exact count categories (sent/deferred/bounced/unknown). It also distinguishes the data provenance from a third-party tracking pixel, so an agent can tell it apart from unrelated stats/usage tools.

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

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

It clearly states the context: use for outbound delivery outcomes over a time window, and clarifies that it reflects real SMTP responses from Postfix logs rather than pixel-based tracking. It does not explicitly name sibling tools or state when not to use it, but there is no close alternative among the listed siblings.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses that the tool re-fetches the same DNS record set originally returned at creation and that records remain available later. However, it does not mention output format, errors, or rate limits, which would add further 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 a single, efficient sentence that front-loads the core purpose and then adds the key usage nuance. Every clause earns its place with no filler 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?

For a one-parameter, no-output-schema retrieval tool, the description is largely complete: it explains what the tool does, when to use it, and how the result relates to creation-time data. Minor gaps like explicit response formatting are not critical for correct tool selection and 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 description coverage is 100%; the single 'domain' parameter is already documented with an example ('example.com'). The description adds no additional parameter-level meaning, but none is needed because the schema fully covers 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 states a specific verb and resource: re-fetch DNS records for an already-registered domain. It also distinguishes this from the one-time receipt of records at creation, making the tool's purpose unambiguous relative to create_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 gives explicit timing guidance: use it any time after creation, implying the records are not only available once. It does not explicitly name alternative tools for exclusion, but the context is clear enough for a simple retrieval operation.

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

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

With no annotations, the description carries the full burden. '''Get''' implies a read-only operation and '''including its body''' discloses a key response trait, but it does not explicitly mention authentication, error behavior, or other response characteristics. Still, the operation is simple and low-risk.

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 wasted words. Every part contributes either the action, the scope, or the key return detail.

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

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

For a simple fetch operation with fully described required parameters, the description adequately conveys what is returned. It lacks an explicit output structure, but '''including its body''' covers the most important payload detail, and the tool has no output schema to lean on.

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 documents all three parameters (id, domain, localPart) with meaningful descriptions, so schema coverage is 100%. The description itself adds no additional parameter semantics 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 states a clear verb-resource pair: '''Get a single draft'''. Adding '''including its body''' clarifies that this returns the full draft contents, distinguishing it from list_drafts and other sibling draft 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?

Usage context is implied: '''single draft''' and '''including its body''' suggest this is for fetching one complete draft rather than listing drafts. However, no explicit when-to-use or when-not-to-use guidance or alternatives are mentioned.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. It indicates a read operation and names returned fields, but it does not mention error cases, authentication requirements, or whether the data is live. No contradiction with annotations 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?

A single sentence with no filler. The key action, target, and returned fields are front-loaded, and every word contributes to the meaning.

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 read operation with 100% schema coverage, the description sufficiently explains what the tool returns even without an output schema. It lacks sibling-routing guidance, but that is not essential for invoking this 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?

The input schema already provides complete descriptions for both required parameters (domain and localPart), so the description adds no parameter-level meaning beyond the schema. The baseline of 3 applies because schema coverage is 100%.

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 clear verb ('Get') and resource ('a mailbox') and identifies the returned content: display name and signature. This distinguishes it from mutation siblings like set_identity, though it does not explicitly contrast with get_me.

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 no guidance on when to choose this tool over get_me or set_identity, and no exclusions or prerequisites are mentioned. Usage context is only implied by the verb 'Get'.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals a critical behavior: the signing secret is not returned and is only shown once during setup or rotation. This goes beyond the operation name and gives an agent a realistic expectation of the response.

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 sentence with the main purpose front-loaded and the important caveat placed parenthetically at the end. There is no redundant wording or filler, and every clause adds useful 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?

Given the tool's simplicity, two clearly documented parameters, and the absence of an output schema, the description is adequate for an agent to understand the operation and its key limitation. It doesn't describe error cases or return shape, but for a straightforward delegate lookup these are not critical enough to penalize heavily.

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 documents both parameters with clear examples ('domain' and 'localPart'), and description coverage is 100%. The description doesn't expand on parameter semantics, but it doesn't need to since the schema handles it. Baseline 3 is appropriate here.

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 ('Check') and a clear resource ('a mailbox's configured webhook URL'), and its read-only intent distinguishes it from sibling tools like set_mailbox_webhook and delete_mailbox_webhook. The parenthetical about the signing secret further clarifies exactly what this tool does and does not return.

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 operational context clear: use this to inspect the current webhook URL configuration. It also provides an explicit exclusion, that the signing secret will never be returned, which tells an agent not to attempt secret retrieval through this tool. It stops short of naming the alternative tools, but the intent is still 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It identifies a read-only get operation and adds the auth-health-check context, but it does not explicitly state that no state changes are made or describe what an unsuccessful response would look like. These gaps are minor for such a simple tool but still present.

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 front-loads the operation and resource, then adds a practical use case. Every word earns its place; there is no ambiguity, 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?

For a parameterless, read-only tool with no output schema, the description adequately covers what the tool does and when it should be used. It does not describe the return shape in detail, but the phrase 'account identity' provides enough expectation for an agent, and the auth-health-check framing makes the tool's purpose fully actionable.

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, so the baseline is 4 per the rubric. There is no parameter information to explain, and the description does not invent any. It correctly focuses on the return value and use case rather than parameters.

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

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

The description names a specific verb (Get), a clear resource (authenticated caller's account identity), and a concrete use case (auth health check). It is immediately distinguishable from siblings like get_usage or list_api_keys because it targets the caller's own identity rather than usage data or API keys.

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 notes the tool is useful as an auth health check, giving the agent a clear context for when to invoke it. It does not explicitly mention exclusions or alternatives, but none of the sibling tools serve this same purpose, so the implicit differentiation 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does this well. It explicitly warns about the side effect of marking the message as read, and alerts the agent that the html field is attacker-controlled and must not be rendered directly. This is critical behavioral and security context beyond the tool name and schema.

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 with no filler. The first sentence states the primary function, the second discloses the side effect, and the third provides a necessary security warning. Each sentence earns its place and the most important 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?

For a single-parameter tool with no output schema, the description covers the essential context: what the tool returns, the side effect of reading a message, and a safety caveat about untrusted HTML content. An agent has enough information to invoke it correctly and handle the response appropriately.

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 the single required id parameter, which already explains that it comes from list_messages or get_thread. The description adds no additional parameter semantics beyond referring to 'one message,' 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 uses a specific verb-resource pair ('Get one message's full content') and specifies exactly what is included: text/html body and attachment metadata. This clearly differentiates it from sibling tools like list_messages, which lists messages, or get_thread, which returns an entire thread.

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: use it when you need the full content of a single message. However, it does not explicitly state when to avoid it, mention alternatives, or contrast it with list_messages or get_thread. The context is clear but left to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool returns every message in a thread, enforces oldest-first ordering, and requires the filtering parameters to match the originating view. This is meaningful behavioral context beyond basic schema information.

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 tight sentences with no wasted words. The core behavior is front-loaded, and the important filter-matching guidance appears immediately after.

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 list tool with no output schema and no annotations, the description gives enough context to call it correctly: the resource scope, ordering, and the relationship between optional parameters and the originating view. Required parameters are well-covered in the schema. Minor gaps remain around the return shape, but they are not critical 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 description coverage is only 40%, so the description must compensate. threadKey and mailbox are already described in the schema, and the description adds that direction/trash/folder should mirror the view where the thread was found. However, the individual semantics of these optional parameters remain somewhat underspecified.

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: 'List every individual message in one thread, oldest first.' It clearly distinguishes from the sibling get_message by describing thread-level scope rather than a single message, and adds ordering behavior.

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 instruction to 'Pass the same direction/trash/folder as the view you found the thread in' provides clear contextual guidance for the optional parameters. It does not explicitly contrast alternatives, but the usage context is clear enough for an agent to know when to call this tool.

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

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

No annotations are present, so the description carries the full burden. It discloses the counting behavior, the account-wide aggregation, and the exclusion of Sent/Trash. It does not describe response shape, but the behavior is otherwise transparent.

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

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

A single, front-loaded sentence communicates the action, scope, and an important exclusions detail without wasted words.

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

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

For a zero-parameter read-only aggregate tool, the description tells the agent what it returns and what it deliberately excludes. The lack of an output schema is the only minor gap, but the description adequately covers the main selection and invocation needs.

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 coverage is 100%, so there is nothing for the description to add. The baseline of 4 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?

States a specific action ('Get'), specific resource ('unread Inbox count'), and scope ('every domain/mailbox on this account at once'). Clearly distinguishes this aggregate tool from message-level or mailbox-level siblings.

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

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

Provides clear context: this is an account-wide aggregate operation for unread Inbox counts, and explicitly excludes Sent and Trash. It does not name alternative tools, but the scope cues are strong enough to guide selection.

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

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

With no annotations, the description carries the full burden. It communicates that this is a read-only lookup of current usage and explicitly frames it as a preflight check before mutations. It does not mention authentication or response formatting, but the safe, non-destructive nature is well established.

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 tightly crafted sentences: the first defines the exact output scope, and the second provides a clear behavioral use case. No filler 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?

For a zero-parameter read-only tool with no output schema, the description fully explains what will be returned and why an agent should call it. Nothing essential is missing for correct 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?

The tool has zero parameters and schema coverage is 100%, so the description has no parameter details to add. The baseline of 4 applies; the description does not need to explain anything further about inputs.

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

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

The description clearly identifies the verb ('Get'), the resource (the account's current billing tier and limits), and the specific data returned (domain count, emails sent this month, storage per domain). It stands apart from sibling tools like get_delivery_stats or get_me by focusing on account-level usage against billing limits.

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, actionable guidance: check this before a bulk operation to avoid hitting a limit mid-batch. It does not explicitly state when not to use it or name an alternative, but the context is clear and useful.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not mention that it is read-only, whether any permissions are required, or what happens when no vacation settings exist. For a getter, this is a moderate 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 a single, focused sentence that conveys the tool's purpose without any filler. It is appropriately concise for a simple retrieval 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 is simple with two well-documented parameters, but there is no output schema and the description does not indicate what the response contains or whether an unset vacation returns null. Given the simplicity, this is adequate but not fully 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 input schema already describes both parameters fully (domain and localPart) with examples, giving 100% schema description coverage. The description adds no additional parameter semantics, so the baseline of 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 specific verb 'Get' with a clear resource: a mailbox's vacation/auto-reply settings. It is easily distinguished from the sibling set_vacation, which performs the opposite operation.

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 usage is implied by the verb 'Get' — the tool retrieves settings rather than modifies them. However, there is no explicit guidance about when to choose this tool over alternatives, nor any exclusions 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that only prefix and status are returned and that the full key is never shown again, which is important non-obvious behavior. It does not cover pagination or status values, but for a zero-parameter list tool this is acceptable.

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, front-loaded with the core action, and immediately followed by the most important caveat. Every part earns its place; no filler or redundant restating of the tool name.

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 there are no parameters and no output schema, the description tells an agent what the call returns (prefix and status) and warns that the full key is unavailable. It is sufficient for correct invocation and reasonable expectation-setting, though it could optionally mention whether revoked keys are included.

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, so there is nothing for the description to clarify about arguments. The baseline for zero-parameter tools is 4, and the description correctly focuses on the output rather than parameters.

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: 'List API keys on this account.' It clearly distinguishes this tool from create_api_key and revoke_api_key, and the account-scope phrasing separates it from other list tools like list_domains or list_mailboxes.

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 'on this account' gives clear context for when this tool applies. It does not explicitly name alternatives or exclusions, but the read-only listing semantics are obvious enough for an agent to know this is the right tool for viewing API keys.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does add meaningful context about the account-level scope and the domain definition of a contact, but it does not mention read-only guarantees, authentication requirements, or what data each listed contact contains.

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 tight, front-loaded sentence with a single parenthetical that adds value without bloat. Every word earns its place, and the key differentiator (account-level vs per-mailbox) is positioned immediately after the verb and resource.

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 zero-parameter list operation with no output schema, this description is largely sufficient. It defines the tool's scope and data model precisely. It could go further by mentioning pagination or the shape of returned contacts, but those are not critical for an agent deciding 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 tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to clarify. The description's scope note adds useful context that would otherwise be absent, and no parameter 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 uses a specific verb ('List') and a clear resource ('contacts'), then sharpens the scope with 'account-level, not per-mailbox'. This immediately distinguishes it from per-mailbox concepts and matches the sibling tool family without 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?

There is no competing list-contacts sibling, but the description clearly states the tool's coverage: account-level contacts across all owned mailboxes, not a single mailbox. This gives an agent enough context to decide when this list tool is appropriate, though it does not explicitly name alternatives or 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?

With no annotations, the description carries the responsibility for behavioral disclosure. It states that listing is scoped to the account and covers every registered domain, but it does not mention the return format, ordering, pagination, or whether unverified domains are included. For a listing operation 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?

The description is one concise sentence that wastes no words. It front-loads the action ('List') and immediately defines the scope ('every domain registered to this Mektup account').

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 zero-parameter listing tool, the description is sufficient to invoke the operation correctly. It lacks an output schema, so it could have described the expected response shape, but this is more a gap in the environment than in the description itself. The coverage is strong for a simple list-all 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?

The tool has zero parameters, and the schema has no properties, so the description does not need to explain parameter semantics. The baseline of 4 applies, and the description correctly implies no arguments are 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 uses a specific verb ('List') and a clear resource ('every domain registered to this Mektup account'), making the tool's function immediately obvious. It is clearly distinguished from sibling tools like create_domain, delete_domain, and get_domain_records, which operate on individual domains or domain settings.

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 enumerates all domains on the account. It does not explicitly mention alternatives or exclusion criteria, but the operation is so simple and distinct from siblings that the intended usage 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?

No annotations are present, so the description carries the full burden. It discloses that only metadata is returned and body content is excluded, which is a meaningful behavioral trait, but it does not mention pagination, ordering, or response shape. This is moderate disclosure, adequate but not comprehensive.

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?

One concise sentence with no fluff, front-loads the action and resource, and packs the important metadata-only limitation into a short clause. 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 list tool with no output schema and no annotations, the description captures the core operation and key output restriction, and even lists some returned fields. However, it omits pagination/limit behavior and whether draft IDs are included, which an agent would need to follow up with get_draft. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and already clearly defines domain and localPart. The description adds only the high-level context that these constitute 'a mailbox' and no extra parameter-level detail 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 states a specific verb ('List') and resource ('drafts for a mailbox'), and clarifies the return is metadata-only with specific fields (to/subject/updated_at) and no body, which distinguishes it from get_draft. This is unambiguous and precisely scoped.

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 clearly signals this is the listing tool for drafts of a mailbox, and the 'no body' caveat implies get_draft should be used when full content is needed, though it does not explicitly name that alternative or exclusion. Clear context without exhaustive when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full disclosure burden. 'List' implies a read-only operation, and 'custom folders' scopes the result, but side effects, authorization expectations, and operational limits are not mentioned. The Outlook-style note adds some data-model context but no deeper behavioral guarantees.

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 action and object. The parenthetical adds useful semantic context without redundancy. Every word contributes to understanding the tool's purpose and scope.

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 operation, the description and fully documented parameters are sufficient for an agent to invoke it correctly. It would benefit from a brief note on return value shape or pagination since no output schema is provided, but the current information is adequate for the tool's low 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 input schema fully documents both parameters, domain and localPart, with examples and 100% coverage. The description only says 'on a mailbox' and adds no additional parameter semantics beyond what the schema already provides, 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 states a specific verb, 'List', and a specific resource, 'custom folders on a mailbox', making the tool's purpose immediately clear. It is easily distinguished from sibling tools like list_mailboxes, list_messages, and create_folder.

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 by specifying that it operates on a mailbox identified by domain and localPart, but it does not provide explicit when-to-use or when-not-to-use guidance. No alternative tools are named, so an agent must infer the right context from the resource type 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?

With no annotations, the description carries the burden and does add useful context: forwarding means incoming mail is copied to these addresses while still staying in the mailbox. However, it does not explicitly state that the tool is read-only, has no side effects, or describe any output/pagination 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?

A single front-loaded sentence names the operation and then briefly clarifies the concept of forwarding. There is no redundancy or filler; every part 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 two-parameter list operation with no output schema, the description is largely sufficient: it explains what the resource is and how forwarding behaves. It could be more complete with explicit output expectations or read-only intent, but the tool's simplicity keeps the gap small.

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 both parameters well. The description adds no additional parameter-level detail, matching the baseline for fully covered parameters.

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 names the exact resource ('forwarding addresses for a mailbox'). It clearly differentiates this read operation from the sibling add_forward/remove_forward tools by describing the listing 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 implies use when the agent needs to view existing forwarding addresses, and sibling names suggest alternatives, but it does not explicitly state when to use this versus add_forward/remove_forward or mention any exclusion criteria.

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

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

With no annotations provided, the description carries the full burden. The verb 'List' inherently conveys a read-only operation, and 'on a given registered domain' states a key prerequisite. However, it does not disclose authentication needs, response shape, pagination, or behavior when the domain is not registered. For a simple list operation this is minimally adequate 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 one short, front-loaded sentence with no superfluous words. It communicates the core action and the key constraint efficiently, earning its place 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?

For a simple tool with one required parameter, no output schema, and no annotations, the description plus schema are largely sufficient to select and invoke the tool correctly. The return value (a list of mailboxes) is inferable from the name and verb. Lacking explicit output format and error-case behavior is acceptable for such a straightforward list operation.

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% for the single domain parameter, so the schema already documents the parameter well. The description adds value by qualifying the domain as 'registered', which is a meaningful constraint not present in the schema. This helps the agent understand the domain must already exist within the system.

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 ('mailboxes') with a scope ('on a given registered domain'). This clearly distinguishes it from siblings like list_domains, create_mailbox, and get_mailbox, making the tool's purpose immediately 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 usage context is implied: call this when you want mailboxes for a specific already-registered domain. However, there is no explicit guidance on when not to use it or which alternatives (e.g., list_domains, get_domain_records) might be more appropriate. The registered-domain qualifier hints at prerequisites but does not spell them out.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals important behavior beyond the schema: one row per thread, direction omission merging both directions, and the searchable fields (subject/from/to/body). This is strong for a read-only list operation, though it does not mention response shape or pagination 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?

Two tight sentences, front-loaded with the core purpose and followed by high-value usage nuances. No filler or repetition of schema details; every clause 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 list tool with six parameters and no output schema, the description covers the non-obvious semantic decisions (threading, direction handling, search scope) while the schema documents the rest. A brief note on the returned fields or pagination would make it fully complete, but the tool can be invoked correctly with the current 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%, so the baseline is 3, but the description adds real value beyond the schema. It clarifies that q searches subject/from/to/body and that direction controls whether Inbox and Sent are merged. These nuances are not recoverable from the parameter descriptions alone.

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

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

The description clearly identifies the operation: listing messages for a mailbox, with the useful clarification 'one row per thread.' It is clear enough to distinguish from list_drafts or get_message, but it does not explicitly name sibling alternatives, so it stops short of a 5.

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 practical guidance: pass direction to split Inbox/Sent and pass q for full-text search. It explains the consequence of omitting direction ('merges both'), which helps the agent decide on parameters. It does not explicitly discuss when to prefer a sibling tool, but the usage context is otherwise 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?

No annotations are provided, so the description bears the full responsibility for behavioral disclosure. It only says 'Remove', which implies deletion, but it does not state whether the action is irreversible, whether it affects any other settings, whether it is idempotent, or what happens to the mailbox itself. For a destructive operation this is a meaningful 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 a single, efficient sentence with no filler. It is concise and understandable on first read. However, the phrase 'from a mailbox' is slightly ambiguous in context because the identifying parameters are domain and localPart rather than a mailbox ID, so the structure could carry a bit more precision without becoming verbose.

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 is simple with only three fully documented parameters and no output schema, so the bar for completeness is moderate. Yet as a removal operation with no annotations, the description should at least note irreversibility or clarify the scope of removal. It currently reads as minimal and leaves the agent without enough behavioral context to safely invoke the 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 description coverage is 100%, so the schema already documents all three parameters, including the special note that 'id' is a forward id from list_forwards. The description adds no extra parameter-level detail, which is acceptable under the baseline of 3 for full 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 ('Remove') and a clear resource ('a forwarding address from a mailbox'), which directly conveys the operation. It naturally distinguishes this tool from siblings like add_forward and list_forwards, since 'remove' marks the inverse of 'add' and distinct from listing.

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 usage context is provided beyond the action itself. The description does not state when to prefer remove_forward over alternatives, nor does it mention prerequisites such as obtaining the forward id from list_forwards (though that appears in the schema). The intended when-to-use is only implicit from the tool name and sibling set.

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

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

With no annotations, the description fully carries the behavioral burden and does so well. It discloses that open IMAP sessions are unaffected, that new credentials apply at next login, and that the new password is shown only once and cannot be recovered later. These are exactly the non-obvious side effects an agent must know.

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

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

Three short sentences, each carrying distinct information: what is reset, when the new password takes effect, and its non-recoverability. 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?

For a simple three-parameter mutation with no annotations and no output schema, the description covers the key operational risks: existing session continuity, timing of new credential use, and one-time visibility. It doesn't explicitly describe the response shape beyond 'shown once', and it doesn't state prerequisites such as the mailbox existing, but the overall picture is strong.

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

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

Schema description coverage is 100%, so parameters are already well documented. The description adds that the password is shown once and not recoverable, which usefully contextualizes the optional password parameter, but it doesn't add new per-parameter meaning beyond the schema.

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

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

The description clearly identifies the operation: resetting a mailbox's IMAP/SMTP-AUTH password. This is specific enough to distinguish it from sibling tools like create_mailbox or get_identity, so an agent knows exactly what resource is affected.

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 existing mailboxes that need new credentials, but it doesn't explicitly say when to prefer this over create_mailbox or any other alternative. The 'new password is needed on next login' hint provides some operational context, but no explicit exclusionary guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses immediate effect ('loses access right away'), irreversibility ('Cannot be undone'), and the risk of self-disruption (current session key). This is substantial behavioral transparency beyond just saying 'revoke'.

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, each serving a distinct purpose: the action, the consequence, and the warning. It is front-loaded with the primary action and avoids any repetition 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?

The tool has one well-documented parameter and no output schema. The description covers the action, the immediate effect on existing users, irreversibility, and the need for user confirmation. Nothing essential is missing for an agent to invoke this tool safely and 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% for the single id parameter, and the property description 'API key id, from list_api_keys' already provides the necessary semantic meaning. The tool description does not add any additional parameter-specific context, so the baseline of 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 tool's function: 'Revoke an API key immediately.' It uses a specific verb (revoke) and resource (API key), and the following sentence clarifies the scope of the action. It is distinct from sibling tools like create_api_key and list_api_keys because it focuses on the revocation 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 provides clear context for use (revoking a key) and includes an important caution: 'Cannot be undone - confirm with the user before calling this, especially if it might be the key currently in use for this very session.' This gives a concrete condition for when to pause, though it does not explicitly name alternative tools or state when not to use it beyond needing user confirmation.

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

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

No annotations are provided, so the description carries the full burden. It discloses the side effect (sending a real email), the from-address validation rules (existing mailbox or verified domain), and the automatic signature appending with a warning not to duplicate it. This is substantial, though it does not mention rates, limits, 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 three dense sentences with no wasted words. The core purpose is front-loaded, followed by the most important operational constraint and then a critical behavioral warning. Every sentence contributes.

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 8 parameters and no annotations or output schema, the description covers the non-obvious traps that would otherwise cause incorrect calls. However, it does not describe success/failure return values or what happens immediately after sending, and it relies on the schema for most parameter details, so it falls just short of fully 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 75%, so the baseline is 3. The description adds meaning beyond the schema by explaining DNS-level domain verification and the signature duplication gotcha for the from parameter. Other parameters are left to the schema, which already documents most of them, so the added value earns a 4.

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

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

The description opens with 'Send a real email,' which clearly identifies the action and resource. The phrase 'real email' distinguishes it from draft-related sibling tools, and the rest of the description reinforces that it performs an actual send with side effects.

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?

Usage is implied by the tool name and the verb 'Send,' and the description gives essential constraints for the from address. However, it never explicitly contrasts this tool with create_draft or other siblings, and it does not state when not to use it, so an agent must infer the selection context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that changes apply automatically to every outgoing message, but it does not explain permission requirements, whether fields can be cleared with null, or how the two signature formats interact.

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, tightly worded sentence that front-loads the core action and its key effect. There is no filler or redundant information.

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

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

For a relatively simple tool, the description captures the main purpose and outcome, but it omits guidance on optional parameter semantics and usage boundaries. Since there is no output schema and no annotations, a bit more contextual detail would be needed for fully confident 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 description coverage is only 40%, and the description only loosely maps to the parameters by mentioning 'display name and signature'. It does not clarify signatureHtml versus signatureText, the meaning of null, or constraints on the optional fields, leaving significant semantic 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 ('Set') with a clear resource ('a mailbox's display name and signature') and states the resulting behavior ('applied automatically to every outgoing message'). This clearly distinguishes it from sibling tools like get_identity and set_vacation.

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 the tool—when you need to configure a mailbox's display name or signature—but it does not explicitly state when to prefer it over alternatives or mention any exclusions. The sibling get_identity makes the read/write distinction inferable, but not explicit.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the action is a one-time secret reveal, that regenerateSecret invalidates the old secret, that deliveries are HTTPS POSTs, and exactly how to verify the HMAC signature before trusting payloads.

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?

Every sentence earns its place: purpose, security constraint, one-time secret behavior, and signature verification details. The most important usage guidance is front-loaded before implementation specifics.

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 webhook-setup tool with no output schema, the description covers the essential return value (signing secret, shown once), the delivery mechanism, and verification steps. Nothing required to call the tool correctly or handle its response 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 coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: the URL must be https and is invoked on every inbound message, and regenerateSecret relates to first-time secret issuance and one-time visibility. This enriches the parameters without repeating the schema verbatim.

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?

States a specific verb-resource pair ('set or update the URL') and the exact mailbox scope. It clearly differentiates itself from polling list_messages and from sibling webhook tools by describing what this endpoint creates and what happens on delivery.

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

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

Explicitly positions the tool as the alternative to polling list_messages for discovering new mail, giving clear when-to-use context. It does not explicitly mention get_mailbox_webhook or delete_mailbox_webhook as exclusions, but the primary decision between polling and webhook is addressed directly.

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses the non-obvious rate-limiting/suppression behavior ('Fires at most once per sender within a rolling window (standard RFC 5230 semantics)') and the enabling precondition. It could also mention overwrite semantics or auth requirements, but the disclosed behaviors are valuable.

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 fluff: the first names the core operation, the second adds the essential constraint and behavioral nuance. Every clause earns its place and the most important 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?

For a tool with no annotations and no output schema, the description covers the main action and a critical behavioral limit, but it leaves gaps: subject is not explained, return/error behavior is absent, and the relationship to get_vacation is not explicitly addressed. Given the modest parameter count, the missing subject semantics keep it from being fully 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 about 60% and the schema already documents domain and message. The description reinforces that message is required when enabling, which adds slight value for the enabled-message interplay, but it does nothing for the subject or enabled parameters and does not clarify behavior 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?

States a specific verb and resource: 'Enable/disable and configure a mailbox's vacation auto-reply.' The action is unambiguous and pairs naturally with the sibling get_vacation for reading the current state, so an agent can distinguish it without opening the schema.

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 for when to set or modify vacation auto-reply, and includes a key condition ('A message is required when enabling'). However, it never explicitly contrasts this with get_vacation or says when not to use it; differentiation is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key behavior that unspecified fields remain unchanged (partial update). It does not mention side effects, validation rules, or whether null values clear fields, but the core mutation behavior is clear from 'update'.

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 with every word contributing meaning. It communicates the operation, the target resource, and the partial-update rule 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 low-complexity tool with three parameters and no output schema, the description is nearly sufficient. Combined with the schema's id description ('from list_contacts'), the agent has what it needs to call correctly. It stops short of describing error cases or null semantics, so it is not fully 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 only 33%, but the description adds important meaning to the optional name and email parameters: send only those you want to change. This tells the agent that omitting a parameter preserves its current value, which is not evident from the schema alone.

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

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

The description clearly states a specific verb ('update') and resource ('a contact'), plus a qualifier ('Partially') that distinguishes it from full-replace operations. The sibling context (create_contact, delete_contact, list_contacts) reinforces that this is the targeted modification tool.

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 'only send the fields you want to change' implies this is for modifying existing contacts and not for creation or deletion. However, it does not explicitly state when to use it over alternatives or when not to use it, so usage guidance is implied rather than fully specified.

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

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

No annotations are provided, so the description carries the burden. It discloses the important merge behavior ('only fields you pass are changed') and the autosave use case, but it does not mention return value, error behavior, or permission requirements for modifying a draft.

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 with the core behavior front-loaded and the partial-update caveat in a parenthetical. Every word earns its place, with no repetition of schema details.

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 7-param mutation with no annotations and no output schema, the description is minimally viable: it states the target resource, the update style, and the merge behavior. It lacks response/error details and any note on permissions or idempotency, leaving meaningful gaps 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?

Schema description coverage is only 43%, and the description does not clarify the format or meaning of the undocumented parameters (to, html, text, subject). It adds useful group-level semantics about unchanged fields being preserved, but that does not compensate for the low per-parameter 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 concrete verb ('update') and a clear resource ('draft'), and immediately qualifies it as a partial, autosave-friendly update. This distinguishes it from create_draft, get_draft, list_drafts, and delete_draft without needing to inspect the schema.

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 partial-update and autosave-friendly framing gives a clear context for when to call it: modifying an existing draft while preserving unspecified fields. It does not explicitly name create_draft or get_draft as alternatives or state when not to use it, so it falls just short of full routing guidance.

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

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

With no annotations, the description carries the full burden. It does disclose important behavioral traits: partial updates ('pass only the fields you want to change'), restore semantics, and the ability to move into or out of a folder. It omits auth permissions, return value, and failure behavior, so it is adequate but not rich 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?

Two sentences with no filler. The core action and the key behavioral nuance ('pass only the fields you want to change') are upfront, and the list of supported operations is compact yet complete.

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 five parameters, no output schema, and no annotations, the description covers the tool's core purpose, supported operations, and partial-update behavior well enough for an agent to call it correctly. Minor gaps remain around return values and prerequisites, but these are less critical for a state-update 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 only 60%, leaving 'read' and 'flagged' without schema descriptions. The description compensates by explaining the boolean meanings as mark/unread and flag/unflag, and it adds the partial-update semantics that apply to all parameters. It also aligns with the restore and folderId descriptions in 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 a specific verb and resource ('Update a message's state') and immediately enumerates the exact supported operations: read/unread, restore, flag/unflag, and folder moves. It clearly distinguishes this tool from siblings like delete_message, get_message, and send_email by scoping it to in-place state mutations.

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 for when to use the tool: any time you need to change message state, and it notes that multiple changes can be combined in one call. However, it does not explicitly mention when not to use it or point to alternatives for related operations like deletion or sending.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that this performs a live re-check, changes state to verified only on a match, and is not automatic. It does not describe what happens on mismatch or whether the call is idempotent, but the key side effect is clearly 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 filler. The primary purpose and outcome are front-loaded, and the second sentence provides actionable timing guidance. 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 one-parameter verification tool, the description covers the core behavior, precondition, and state-changing effect. The main gap is the absence of an explicit statement about the response or behavior when MX records do not match, but the conditional wording implies no verification flip.

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 fully documents the single parameter with an example. The description adds no additional parameter-specific detail, and with 100% schema description coverage, 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 states a specific action ('re-check a domain's live MX records'), a clear target resource ('domain'), and a defined outcome ('flip it to verified if they match'). This clearly differentiates verify_domain from siblings like get_domain_records or create_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 explicitly tells the agent when to call this tool: after DNS has been added and has had time to propagate. It also notes that verification is not automatic. It does not name an alternative tool or state a when-not-to-use case, but the timing guidance is clear enough.

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