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

Without annotations, the description carries full burden but does not disclose whether assignment overwrites existing, required permissions, side effects, or idempotency. It only states the basic action.

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, front-loaded, and structured into a main description and Args list. Every sentence serves a purpose.

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

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

Given an output schema exists (not shown), but no annotations or deeper behavioral context, the description is adequate for a simple mutation but lacks info on success/failure or prerequisites.

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

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

With 0% schema coverage, the description adds meaning by explaining thread_id and the null/empty behavior for assigned_to, clarifying that omission or empty unassigns.

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 'Assign a thread to an agent or user' with a specific verb and resource, and also covers unassignment. This distinguishes it from sibling tools like tag_thread or set_thread_status.

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 tells how to assign and unassign (pass null/empty) but does not provide guidance on when to use this tool versus alternatives, nor any prerequisites or limitations.

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 must convey behavioral traits. It only mentions creation and follow-up steps but omits details like idempotency, side effects, permissions, or what happens on duplicate names. The output schema exists but is not explained.

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

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

The description is concise with front-loaded purpose and no extraneous information. Every sentence serves a function, and the Args section is cleanly separated.

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 output schema exists and sibling tools cover domain management, the description provides sufficient context for creation. It could mention uniqueness constraints or error scenarios, but the follow-up steps enhance completeness.

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

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

The input schema has 0% description coverage, but the description compensates with clear examples for both parameters ('example.com' for name, specific region values for region), clarifying optionality and format.

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

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

The description clearly states the action ('Create') and resource ('new custom email domain'), and the use case is distinct from sibling tools like get_domain_records and verify_domain.

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

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

The description explicitly outlines the post-creation steps (get_domain_records, add DNS, verify_domain), guiding the agent on when to use this tool and what subsequent actions are needed.

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

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

With no annotations, the description carries full burden. It explains the auto-assignment of domain if domain_id omitted, optional parameters, and webhook endpoint behavior. It does not disclose rate limits or auth needs, but the creation behavior is well described.

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

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

The description is well-structured with a summary paragraph and Args list. It is clear and informative, though slightly verbose for the display_name explanation; still efficient.

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

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

Given 5 parameters (1 required) and an output schema (not shown), the description covers all parameters and provides context. It does not describe return values, but output schema likely handles that. Minor gap: no mention of default values beyond domain auto-assignment.

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 has 0% description coverage, but the description thoroughly explains each parameter: local_part (part before @), domain_id (optional, auto-resolved), name (agent name, display_name fallback), display_name (with example), and webhook_endpoint (notification URL). This fully compensates for missing schema descriptions.

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

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

The description clearly states 'Create a new inbox for receiving emails' and explains the email address format. It distinguishes from sibling tools like delete_inbox, list_inboxes, etc., by focusing on creation.

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 an inbox needs to be created for email receiving, but does not explicitly state when not to use or mention alternatives among siblings (e.g., send_email for sending, not receiving).

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 full burden. It discloses the process: creates a session, returns a checkout URL, and that payment is completed in the browser. It lists valid bundles. It does not mention idempotency or error cases, but the core behavior is transparent.

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

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

The description is extremely concise: two sentences for the main purpose and return value, then a clear argument list. No unnecessary words.

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

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

Given that an output schema exists, the description adequately covers the return value (checkout_url) and parameters. It is complete for the tool's purpose, though additional details on error handling could be 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?

Schema coverage is 0%, so description must compensate. It explains bundle with valid values and return_url as optional. This adds essential meaning beyond the raw schema.

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

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

The description clearly states it creates a Stripe checkout session to purchase a credit bundle, specifying valid bundles and the return value. It distinguishes from sibling tools like list_credit_bundles and get_credit_balance.

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

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

The description implicitly indicates when to use (to purchase credits) but does not explicitly state when not to use or provide alternatives. However, the context of sibling tools and the clear action verb provide sufficient 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?

No annotations are provided, so the description carries full burden. It does not disclose that deletion is irreversible, potential side effects (e.g., cascade delete), or required permissions. This is a significant gap 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?

The description is extremely concise with no unnecessary words. It follows a docstring format. However, it is under-specified, which slightly reduces efficiency as the agent must infer missing 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?

Despite having an output schema (which exempts return value explanation), the description lacks behavioral context such as irreversibility, required permissions, or error conditions. For a delete operation, this is incomplete.

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 0%. The description restates parameter names without adding meaning beyond the schema field names (e.g., 'domain_id: The domain ID'). No additional semantics like format, constraints, or examples are provided.

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

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

The description 'Delete an inbox' clearly states the verb and resource, matching the tool name. However, it does not add any distinguishing scope or nuance from sibling tools, but its purpose is immediately clear.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., when to delete vs. set_thread_status). No context or prerequisites 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?

With no annotations, the description carries full responsibility. It discloses that the tool returns a temporary download URL with a configurable lifetime, but does not elaborate on error handling, side effects, or authentication requirements.

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

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

The description is very concise with no wasted words. The purpose is stated first, followed clear parameter explanations. Every sentence serves a purpose without redundancy.

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

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

Given the tool's simplicity and the existence of an output schema, the description covers the essential aspects. However, it could mention potential error conditions or clarify the nature of the URL (e.g., direct download vs. streaming).

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 0%, so the description must compensate. It describes attachment_id as 'The attachment ID' and expires_in with a clear explanation of its unit and default. This adds meaningful value beyond the schema's technical types.

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

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

The description clearly states 'Get a temporary download URL for an attachment,' using a specific verb and resource. It distinguishes itself from sibling tools like upload_attachment or send_email, which deal with different actions.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. Usage is implied by the tool's purpose, but explicit guidance is missing.

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 bears full burden. It correctly states that the tool returns specific credit information (included credits, purchased credits, total available, credits used). It does not explicitly mark it as read-only or mention auth/rate limits, but for a simple retrieval tool, the described behavior is sufficient and non-misleading.

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. The first sentence delivers the core purpose immediately. The second sentence provides added detail on the return values. There is no wasted text; 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?

Given the tool has no parameters, an output schema exists, and it is a simple read operation, the description is complete. It covers what the tool does and what it returns, providing sufficient context for an AI agent to use 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?

There are zero parameters, so baseline is 4. The description does not need to add parameter information. Schema coverage is 100% because no parameters exist. The description appropriately omits parameter details.

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

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

The description clearly states the verb 'Get' and resource 'credit balance for your Commune account'. It distinguishes from sibling tools like 'credits_checkout' and 'list_credit_bundles' by focusing on balance retrieval. The second sentence lists the specific returned fields, leaving 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 implies usage when needing credit balance information, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. Given the clear separation of concerns among siblings, the implied guidance is adequate 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?

No annotations are provided, so the description carries full burden. It implies a read operation and discloses the metrics returned but does not mention idempotency, caching, or any potential side effects. It is adequate but not detailed.

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 with no wasted words, front-loaded with the metrics list, followed by a clear args section. Every sentence adds value.

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

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

Output schema exists, so return values are covered. The description provides sufficient context for filtering and usage. Could mention if it aggregates across all inboxes or requires authentication, but it's essentially complete for its purpose.

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 0%, but the description includes an explicit Args section explaining inbox_id, domain_id, and period with defaults and meaning, fully compensating for the missing schema descriptions.

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

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

The description clearly states 'Get email deliverability metrics: sent, delivered, bounced, complained, failed.' and includes percentage rates, explicitly differentiating it from sibling tools like get_delivery_events.

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 says 'Use this to monitor sender reputation and identify deliverability issues,' providing a clear use case but does not explicitly list when not to use or mention alternatives.

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

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

No annotations are provided, so the description must disclose behavioral traits. It fails to mention pagination, rate limits, authentication requirements, or whether it returns all events or only filtered ones. The description only lists filter parameters.

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 with a brief headline, a contextual sentence, and a bulleted parameter list. It is well-structured and front-loaded, though the parameter section could be slightly more compact.

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 presence of an output schema, the description adequately covers the tool's purpose and filter capabilities. However, it omits details like result ordering, pagination behavior (beyond limit), and event type format. Still, it is mostly complete for a straightforward get-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 description coverage is 0%, but the description adds meaningful explanations for all 5 parameters (e.g., 'message_id: Filter events for a specific message'). This compensates for the blank schema and helps the agent understand each parameter's purpose.

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

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

The description clearly states the tool retrieves delivery event logs (sent, delivered, bounced, complained, failed) and tracks email lifecycle or audits delivery. This distinguishes it from siblings like get_deliverability_stats (broader stats) and thread-related tools.

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

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

The description implies usage for tracking email lifecycle and auditing, but lacks explicit guidance on when to use this tool vs. siblings (e.g., get_deliverability_stats for aggregated stats). No 'when not to use' or alternative suggestions.

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 provided, so description must cover behavior. It explains the tool returns records and is a read-only fetch. However, it does not discuss potential errors or rate limits. Adequate but minimal.

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?

Concise with a clear first sentence and structured Args section. Could be slightly more streamlined, but effectively communicates purpose.

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

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

Given an output schema exists, the description appropriately focuses on input and purpose. Mentions record types (MX, TXT, CNAME) but lacks error handling details. Fairly complete for a simple get 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 schema has 0% description coverage for the single parameter. The description adds meaning by stating domain_id is from list_domains, helping the agent source the value.

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

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

The description clearly states the tool gets DNS records required for domain verification, specifying MX, TXT, and CNAME records. It distinguishes from siblings like verify_domain and list_domains.

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

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

Describes that it must be used before calling verify_domain, providing clear context. Does not explicitly state when not to use it, but the prerequisite is clear.

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

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

No annotations exist, so the description carries the disclosure burden. It explains that 'Suppressed addresses are automatically skipped when sending', which is a useful behavioral trait. However, it does not mention any rate limits, authentication needs, or whether the operation is read-only, which is implied but not explicit.

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

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

The description is concise, with only three sentences and an Args section. It front-loads the main purpose and provides parameter details in a structured format without unnecessary words.

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

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

Given an output schema exists, return values need not be explained. The description covers the tool's purpose, the effect of suppressions, and parameter usage. It is sufficiently complete for an agent to invoke correctly, though it lacks mention of pagination or sort order, which are minor.

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 0%, but the description adds meaningful explanations for all three parameters: 'Filter by inbox (optional)', 'Filter by domain (optional)', and 'Max results (default: 50)'. This significantly compensates for the lack of schema descriptions.

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

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

The description clearly states 'List suppressed email addresses (bounces, complaints, unsubscribes)', specifying the verb 'list' and the resource 'suppressed email addresses'. It effectively distinguishes from sibling tools by focusing on suppression data, which no other sibling tool addresses.

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 usage context with 'Use this to audit why certain recipients aren't receiving emails', giving a clear reason to use the tool. While it does not explicitly mention when not to use it or alternatives, the sibling list shows no direct competitor, so this guidance is sufficient.

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

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

With no annotations, the description must cover behavioral traits. It mentions limit range and order options but does not disclose whether it's read-only, auth requirements, or pagination behavior. However, the defaults and range information provide some 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 relatively concise with a clear purpose statement followed by parameter details. It could be slightly tighter (e.g., 'Get all messages' vs 'Get messages' with limit explained) but overall well-structured and 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 output schema exists (not shown), return values are covered. However, the phrase 'Get all messages' conflicts with the limit parameter suggesting partial retrieval. No comparison to sibling tools or error scenarios mentioned, leaving some context 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?

The input schema has 0% description coverage, but the description fully explains each parameter: thread_id (source), limit (range 1-1000, default 50), order (asc/desc, default asc). This adds significant 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 states that the tool retrieves all messages in an email thread and specifies the returned data (sender, content, timestamps). This is specific and distinguishable from siblings like get_thread_metadata.

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 indicates where to get the thread_id (from list_threads) but does not explicitly clarify when to use this tool versus alternatives like search_threads or get_thread_metadata. It lacks when-not or exclusion 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. The verb 'Get' implies read-only, but the description does not explicitly state that the operation is safe, idempotent, or requires any specific permissions. It lacks details on what happens if the thread_id is invalid or if the user lacks access.

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 purpose. The Args section is slightly redundant but not overly verbose. Every sentence is brief, though the Args block could be omitted since the schema already defines the parameter.

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 getter with one parameter and an output schema, the description covers the basic purpose and parameter. It does not mention error handling or edge cases, but given the tool's simplicity and the presence of an output schema, it is reasonably complete. Slightly more context (e.g., 'Returns metadata for an existing thread') would improve clarity.

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

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

The description's 'Args' section restates the parameter name and a generic description ('The thread ID') which adds no value beyond the input schema. With schema description coverage at 0%, the description fails to provide any additional semantic or format constraints (e.g., expected format, length, or example values).

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

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

The description clearly states the action ('Get') and the resource ('triage metadata for a thread') and specifies the components: tags, status, and assignment. It effectively distinguishes from sibling tools like get_thread_messages (which retrieves messages) or tag_thread (which modifies tags).

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives like assign_thread or set_thread_status. The name implies a read operation, but no usage context or exclusions are mentioned, leaving the agent to infer from sibling names.

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

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

The description honestly states the tool lists bundles and returns specific fields. No annotations were provided, so the description carries the full burden. It is truthful about being read-only but lacks extra context like authentication or rate limits.

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

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

The description is two sentences: first states purpose, second describes return values. It is concise, front-loaded, and contains no unnecessary words.

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

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

Given no parameters and an implied output schema, the description covers the essentials. It mentions the return fields (ID, credit amount, price, description). Could be improved by noting ordering or pagination, but fine 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?

There are no parameters, so schema coverage is 100% trivially. Baseline 4 is appropriate as the description adds no parameter semantics, which is acceptable for a parameter-less tool.

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

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

The description clearly states the tool lists available credit bundles for purchase, specifying the verb 'List' and the resource 'credit bundles'. It distinguishes itself from siblings like 'credits_checkout' (purchase) and 'get_credit_balance' (check balance).

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when-not-to-use or comparison with other credit-related tools.

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

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

With no annotations provided, the description carries the full burden. It correctly indicates a read-only list operation with no side effects. For a simple list tool, this is sufficient; additional details about rate limits or permissions are not critical but would slightly enhance transparency.

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

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

The description is extremely concise with two sentences, front-loading the core purpose. Every sentence adds value, and there is no redundant or extraneous information.

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

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

Given that the tool has zero parameters and an output schema exists, the description fully covers the necessary context: what the tool does, what it returns, and how the output can be used with other tools. No gaps are apparent.

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

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

There are no parameters, so the baseline score is 4. The description adds no parameter-specific meaning beyond what the schema already indicates (an empty object), which is acceptable for a zero-parameter tool.

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

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

The description clearly states the tool lists all email domains in the account and specifies the returned fields (ID, name, verification status). It distinguishes itself from sibling tools like create_domain and verify_domain by being a read-only list 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 advises using the domain ID with other tools like list_inboxes or create_inbox, providing context for subsequent actions. However, it does not explicitly state when to choose this tool over siblings or when not to use it, leaving some guidance implied.

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

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

No annotations are provided, so the description carries the full burden. It discloses the filtering behavior and email address format. However, it does not mention potential traits like pagination, ordering, or limits, which could be relevant for an agent.

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

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

The description is concise and well-structured, starting with the main purpose, then detailing behavior variations, and finishing with parameter explanation. Every sentence adds value without redundancy.

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

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

The description covers the core functionality and parameter usage. Given that an output schema exists, it does not need to explain return values. Missing details like pagination or result limits are minor gaps for a list 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?

With 0% schema description coverage, the description adds meaning by explaining the domain_id parameter's effect (filter vs. list all) and the email address structure derived from local_part and domain. This compensates well for the lack of schema documentation.

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 'List inboxes' as a specific verb and resource, and differentiates from sibling tools like create_inbox, delete_inbox, list_domains, etc., which operate on different resources or actions.

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

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

The description explains when to use with or without domain_id, providing clear context for filtering. It does not explicitly state when not to use or mention alternatives, but for a simple list operation, this is adequate.

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

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

No annotations provided, but the description discloses return fields (subject, message count, etc.) and pagination behavior. It does not mention auth requirements or rate limits, which is acceptable for a read-only list 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 front-loaded with purpose and returns, then usage and parameters. It is efficient but could be slightly more concise without losing clarity.

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

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

The description covers pagination, filtering, and return value summary. With an output schema present, it does not need to detail return values further, but it lacks error handling or edge case notes.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter (inbox_id, domain_id, limit, cursor, order) with defaults and usage context.

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 it lists email threads with pagination, returns summaries, and distinguishes itself from sibling tools like search_threads by focusing on filtering by inbox or 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?

It provides a clear constraint (provide inbox_id or domain_id) and explains pagination with cursor. However, it does not explicitly contrast with alternative tools like search_threads for when to use each.

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 disclose behavioral traits. It only states 'Remove', implying deletion, but provides no details on reversibility, impact on inbox functionality, permissions needed, or error states.

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 superfluous words, front-loading the core action and target.

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?

Despite the presence of an output schema and clear purpose, the description lacks context about when removal is appropriate, the relationship with set_extraction_schema, and what constitutes a valid request (e.g., schema must exist).

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 0%, yet the description does not explain the role of 'domain_id' or 'inbox_id', leaving the agent to infer their meaning from names 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 the action ('Remove'), the resource ('structured extraction schema'), and the target ('inbox'). It directly distinguishes from the sibling tool 'set_extraction_schema', which adds or updates a 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?

No guidance on when to use this tool versus alternatives, such as when a schema should be removed, prerequisites like having an existing schema, or consequences of removal.

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 provided, and description does not disclose behavioral traits like side effects, rate limits, or authentication needs. Only states what the tool does, without safety or performance context.

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?

Front-loaded with main purpose in first sentence, followed by clear argument list. No redundant words; every sentence adds value.

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

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

Describes return value (thread summaries with subject, snippet, message count). Could mention pagination or ordering, but output schema exists. Adequate for a search 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?

Adds significant meaning beyond schema: explains query searches subject and message content, inbox_id and domain_id as filters, and limit range (1-100). Compensates for 0% schema description 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?

Clearly states verb 'Search' and resource 'email threads'. Distinguishes from sibling 'list_threads' by specifying search by subject or content, and from 'get_thread_metadata' and 'get_thread_messages' by indicating it returns summaries.

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: 'Provide at least one of inbox_id or domain_id' and notes inbox_id is 'recommended'. However, no explicit when-not-to-use or alternative tool 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?

No annotations are provided, so the description must fully convey behavioral traits. It mentions that domain is inferred automatically from inbox_id and that both html and text can be supplied. However, it does not disclose potential rate limits, authentication prerequisites, or what happens on failure. Given the output schema exists, the description adequately covers basic behavior but lacks deeper insights.

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

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

The description is front-loaded with the core purpose, followed by brief usage notes, then an Args list. It is concise and structured, with each sentence serving a purpose. The Args list could be more compressed, but it is well-organized. No 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?

Given the tool has 10 parameters and an output schema, the description covers key workflows: basic send, reply to thread, and attachments. It explains domain inference. It does not cover error handling or prerequisites like domain verification, but the output schema likely provides return structure. Overall, it is sufficiently complete for typical use cases.

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 0% description coverage, so the description must compensate. The description includes an Args list that explains each parameter's role, e.g., 'to: Recipient email address (for multiple, comma-separate)', 'attachments: Comma-separated attachment IDs from upload_attachment'. This adds significant meaning beyond the raw schema. Some param details (e.g., format of thread_id) are not specified, but overall it is helpful.

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 'Send an email message.' as the primary action, which is a specific verb plus resource. It distinguishes itself from sibling tools (e.g., create_inbox, assign_thread) by focusing on sending email. The tool's unique function is immediately 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 provides practical guidance on how to use the tool: it explains how to reply in a thread (pass thread_id), how to attach files (call upload_attachment first, then pass IDs), and that inbox_id is sufficient for domain inference. It does not explicitly state when not to use this tool, but given no sibling sends email, this is acceptable.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It does not mention side effects such as overwriting existing schema, triggering re-extraction, or permissions required. The only behavioral hint is that 'enabled' controls immediate extraction, but overall transparency is poor.

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: a one-line summary followed by a list of arguments. Every sentence is essential, with no redundancy. It is front-loaded with the purpose and structured efficiently.

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

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

Given the tool has 6 parameters and an output schema, the description is somewhat minimal. It explains parameters well but omits behavioral context (overwrite behavior, validation, error conditions) and prerequisites (domain/inbox existence). It is adequate but not comprehensive.

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

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

Schema description coverage is 0%, so the description provides all semantics for the 6 parameters. Each parameter has a brief but clear explanation, e.g., 'schema: JSON string of a valid JSON Schema object.' This adds significant value beyond the schema titles.

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 that the tool sets a structured extraction schema for an inbox. The verb 'set' is specific, and the resource 'structured extraction schema' is unambiguous. It distinguishes from the sibling 'remove_extraction_schema', but does not clarify whether it creates or updates, leaving some 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 guidance on when to use this tool versus alternatives like 'remove_extraction_schema' or other configuration tools. No prerequisites, context, or exclusions are mentioned. The description lacks explicit when-to-use or when-not-to-use information.

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, and the description only lists valid statuses. It does not disclose side effects, idempotency, permissions, or error conditions.

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

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

The description is short and front-loaded with the purpose. The parameter list repeats schema info but is clear. It lacks extraneous content.

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

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

Given no annotations and low schema coverage, the description adds valid statuses but lacks broader context about effects, prerequisites, or error handling. An output schema exists but is not described.

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 0%, so the description compensates by listing both parameters and providing valid values for 'status' (open, needs_reply, waiting, closed). This is valuable beyond the raw schema.

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

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

The description clearly states the verb 'Set' and resource 'status of a thread for triage'. It explicitly lists valid statuses, distinguishing it from siblings like assign_thread or tag_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?

No guidance is provided on when to use this tool vs alternatives such as assign_thread or tag_thread. The description does not mention context 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?

No annotations are provided, but the description discloses message length limit (4000 chars) and optional context usage. It does not mention side effects or rate limits, but for a feedback tool, the behavioral information is adequate.

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

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

The description is well-structured and front-loaded with purpose, but moderately long. Every sentence adds value, though it could be slightly more concise without losing substance.

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

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

The description covers purpose, usage guidelines, parameter semantics, and includes examples. It lacks explanation of the return value (output schema exists but not described), but for a feedback submission tool, the completeness is sufficient.

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

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

Schema description coverage is 0%, but the description adds significant meaning: explains enum values ('error', 'feature', 'signal'), provides context example, and states max chars for message, adding value beyond the bare 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 'Submit feedback about Commune to the product team' and elaborates on three specific feedback types, distinguishing this tool from sibling tools that focus on threads, inboxes, and domains.

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

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

Explicitly says 'Use this tool whenever you encounter something worth reporting' and provides detailed guidance for each feedback type (error, feature, signal) with examples, making it easy for an agent to decide when to invoke 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 provided, so description bears full burden. It discloses that tags are additive and existing tags preserved, but omits details on authentication, rate limits, output format, or error conditions. Adequate but could be more 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?

Very concise: two sentences for purpose and behavior, then a structured Args section. Every sentence adds value, no fluff. Clear and well-organized.

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 and presence of output schema (even if not shown), the description covers key aspects: purpose, additive behavior, parameter format. Missing return value description could be a minor gap, but overall sufficient for an additive tagging 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?

With 0% schema description coverage, the description adds value by explaining the 'tags' parameter as comma-separated and providing an example. The 'thread_id' explanation is minimal but sufficient. This compensates for the schema's lack of description.

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

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

Clearly states 'Add tags/labels to a thread' with a specific verb and resource. The phrase 'Tags are additive — existing tags are preserved' further clarifies behavior, distinguishing it from untag_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?

Provides explicit examples of tags to use (e.g., 'vip', 'bug-report') and mentions that tags are for categorization. While it doesn't directly say when not to use, the examples and additive nature implicitly guide usage. Sibling untag_thread suggests removal alternative.

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, and the description only states the basic action. It does not disclose any side effects, prerequisites, or behavior beyond removal (e.g., whether the operation is idempotent, what happens if tags don't exist).

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: one sentence for the action and a clear parameter list. Every word is necessary and 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 tool with 2 required parameters and an output schema, the description covers the basics. However, it lacks context about error handling, prerequisites (e.g., thread existence), and relationship to sibling tools like 'tag_thread'.

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

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

With 0% schema description coverage, the description adds meaningful value by specifying the format of 'tags' as comma-separated and providing an example, and clarifying 'thread_id' as 'The thread ID'.

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

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

The description clearly states the action ('Remove tags/labels') and the resource ('from a thread'), using specific verbs and nouns that distinguish it from sibling tools like 'tag_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?

No guidance on when to use this tool versus alternatives like 'tag_thread'. The description only states what the tool does without providing context for selection.

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

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

With no annotations, the description bears full responsibility. It explains the upload action and return value, but omits details like file size limits, supported MIME types beyond examples, or storage duration. 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?

The description is concise (6 lines), transparently structured with an Args section, and every sentence provides value. No wasted words.

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

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

Given 3 parameters and the presence of an output schema (as per context signals), the description covers key aspects: purpose, usage, parameter details, and return value. It could mention potential limitations like size limits, but overall it's well-rounded.

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 0%, so the description must compensate. It clearly describes each parameter: content (Base64-encoded), filename (with example), and mime_type (with examples), adding essential 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 explicitly states 'Upload a file for use when sending emails' and mentions returning an attachment_id, clearly differentiating from sibling tools like send_email and get_attachment_url.

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 indicates when to use the tool (before sending emails) and how to pass the result to send_email, providing clear context. It does not explicitly mention when not to use it, but the use case is well-defined.

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 must disclose behavior. It states 'Trigger DNS verification' but does not explain if it is synchronous, idempotent, or error handling for missing records. Adequate but lacks depth.

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?

Very concise, three short sentences plus parameter listing. The 'Args:' header is slightly redundant but not harmful. Effectively front-loaded with key instructions.

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

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

With an output schema present, the description covers the essential usage: prerequisite steps and parameter source. It lacks details on errors or async nature, but for a simple trigger, it is reasonably complete.

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

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

Schema coverage is 0%, so description adds meaning. It explains that 'domain_id' comes from 'list_domains', providing source context. However, it could specify format or constraints (e.g., required format).

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 triggers DNS verification for a domain, using a specific verb and resource. It distinguishes itself from siblings like 'get_domain_records' and 'create_domain' by focusing on the verification step.

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

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

Explicitly instructs to call after adding DNS records and to use 'get_domain_records' first for prerequisite records. This provides clear when-to-use and what-to-do-before guidance, differentiating it from other tools.

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