email

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

Discloses non-read-only nature (claiming), conflict resolution, and return of dns_records. Adds context beyond annotations about the flow, though edge cases like domain already claimed are not covered.

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

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

Three sentences, front-loaded main action, no unnecessary words. Efficient and well-structured.

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?

Covers main claim action, conflict case with re-call, and next step (verifyDomain). With an output schema present, return values are hinted. Complete for agent use.

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?

Description explains both domain and confirmed parameters, but the input schema already contains similar descriptions. Adds minimal new meaning beyond what the schema provides.

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

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

Clearly states the tool claims a domain and returns DNS records. Distinguishes from sibling tools like verifyDomain, which completes setup, and listDomains, which lists existing 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?

Provides explicit guidance: use for initial claim, re-call with confirmed=true if mx_conflict occurs, and follow with verifyDomain. Offers a clear workflow with alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context beyond these: it explains the long-polling mechanism ('long-polls for up to 30 seconds by default'), the matching strategy ('uses reply threading, not a sender or subject guess'), and the expected return behavior ('returns with no reply'). No contradictions with annotations.

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

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

The description is six sentences, each earning its place. It front-loads the core purpose in the first sentence, then quickly covers usage advice, polling behavior, error handling instruction, and matching logic. There is no redundancy or unnecessary detail. The structure is logical and easy to scan.

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

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

Given the tool's complexity (4 parameters, output schema present), the description covers all essential aspects: when to call, the polling mechanism, timeout behavior, error handling (do not report no reply prematurely), and how matching works. The presence of an output schema reduces the need to describe return values. The description is complete for an AI agent to use this tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal semantic value beyond the schema: it reiterates that 'id' comes from a sendEmail/replyToEmail response (already in schema) and notes that with only the id it long-polls by default. The 'wait' and 'wait_timeout_ms' parameters are adequately documented in the schema. The description does not significantly enhance parameter understanding, so a 3 is appropriate.

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

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

The description clearly states the purpose: 'Wait for the threaded reply to a sent email.' It specifies the action (waiting), the resource (reply to a sent email), and even suggests when to call it (immediately after sendEmail or replyToEmail). This distinguishes it from all sibling tools, none of which are polling or waiting tools.

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

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

The description provides explicit usage guidance: 'Call this immediately after sendEmail or replyToEmail when you expect an answer.' It tells the agent when not to use alternatives ('Do not report that nobody replied or ask the user to check later until this call returns with no reply') and gives specific advice for the 'wait' parameter ('Set wait=false only for a deliberate immediate poll'). This is comprehensive and actionable.

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

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

Annotations already indicate destructiveHint=true. The description adds behavioral details beyond annotations: it explains the outcome (terminal status 'canceled'), the side effect (idempotency key becomes reusable), and an error condition (conflict if already dispatching). This provides useful context that annotations alone do not convey.

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

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

Two sentences, front-loaded with the core purpose. No redundant information. The description is concise and each sentence serves a purpose: first sentence states the action and outcome, second sentence provides parameter source and error condition. It is appropriately sized for the simple 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?

Given the tool's simplicity (one parameter, output schema present), the description covers key aspects: what it does, when to use it, how to get the input, and an error scenario. It does not explain return values, but the output schema handles that. It is complete enough for effective use.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by explaining how to obtain the 'id' parameter: from a sendEmail response that used scheduled_at, or from listSentEmails. This clarifies the source and context, making it more helpful than the schema description 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 verb 'cancel' and the resource 'scheduled send'. It distinguishes this tool from siblings by specifying it applies only to still-scheduled sends, and mentions the terminal status 'canceled' and idempotency key reuse, which uniquely identifies its purpose.

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

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

The description provides explicit context on when to use the tool: pass the sent email id from a sendEmail response that used scheduled_at, or from listSentEmails. It also warns about a conflict error if the send has already started dispatching. No explicit when-not or alternatives are given, but the usage context is clear.

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

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

Beyond annotations (readOnlyHint false), the description discloses key behaviors: creates on first use (mutation), returns api_key and sender_address, explains idempotency (existing_account flag), and warns that failing to pass the api_key later will cause failures. All critical for safe invocation.

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 fairly long but every sentence adds value. It is front-loaded with purpose, then usage, then result details, then important warnings. Slight redundancy in explaining the domain format could be tightened, but overall well-organized and concise.

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

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

Given the tool's complexity (1 parameter, nested, output schema present), the description fully covers the input context (terms_accepted must be true), the output structure (address, sender_address, api_key, existing_account, upgrade_link), idempotency, and critical api_key handling. Complete enough for an agent to use correctly.

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

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

The input schema already describes both parameters (device_name, terms_accepted) with adequate detail. The tool description adds no further information about these parameters. Baseline 3 is appropriate since schema coverage is good and the description focuses on output and usage instead.

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

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

The description clearly states the tool's purpose: 'Get this user's Primitive managed inbox domain, creating the account on first use.' It specifies the resource (managed inbox domain) and action (get/create), and distinguishes from siblings by calling it first when no API key exists. No other sibling tool has this role.

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 tells when to use: 'CALL THIS FIRST whenever you do not already have a Primitive API key and the user wants to send or receive email, instead of telling them to sign up or visit a website.' Also warns against re-calling: 'calling again will not produce a different one.' Provides clear alternatives (signup/website) and 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?

Beyond annotations, the description reveals key behaviors: reactivation of deactivated endpoints with the same URL and the need for post-creation testing. No contradictions with annotations.

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

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

Two sentences with clear, front-loaded information. Every sentence adds value (purpose, reactivation, follow-up step). No fluff.

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

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

The description covers main purpose and a key behavior, but omits any mention of permissions, error handling, or return values. With an output schema present, return values are less critical, but completeness is still moderate.

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%, and the description only mentions URL behavior briefly, leaving other parameters (rules, enabled, domain_id) unexplained. The schema provides descriptions, but the tool description should compensate more.

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

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

The description clearly states the tool creates a webhook endpoint for email.received events, and distinguishes itself from siblings like testEndpoint and deleteEndpoint by mentioning reactivation and post-creation testing.

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

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

The description provides a follow-up step (call testEndpoint) but lacks explicit guidance on when to use this tool versus alternatives like listEndpoints or deleteEndpoint.

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

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

The description adds behavioral details beyond annotations, such as patterns being stored lowercase and Pro plan requirement. But it lacks information on idempotency, error handling, or response behavior, which is partially covered by annotations.

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

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

The description is two sentences, concise and front-loaded with the core purpose. Every word adds value.

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

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

Given the tool has a nested parameter and output schema, the description provides minimal context beyond creation. It does not cover return values, error conditions, or uniqueness, making it adequate but not complete.

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

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

With 0% schema description coverage in the tool description, the description adds one behavioral detail ('patterns stored lowercase') but does not fully explain each parameter's meaning or constraints, which are already 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 clearly states 'Create a whitelist or blocklist filter rule.' This is a specific verb+resource combination that distinguishes it from siblings like deleteFilter and listFilters.

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 mentions 'Patterns are stored lowercase' and 'Per-domain filters require a Pro plan,' providing context for usage. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

Annotations already mark the tool as destructive (destructiveHint=true), so the description's 'soft-delete' adds a nuance beyond annotations, but it doesn't clarify if the deletion is reversible or detail other behaviors like permissions or side effects.

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

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

Two short, substantive sentences with no wasted words. The key information is front-loaded.

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

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

For a simple tool with one required parameter and an output schema, the description adequately covers purpose and effect. However, it could mention idempotency or reversibility, but overall it's fairly 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% (id parameter fully described), so baseline is 3. The description adds no further parameter semantics beyond 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 clearly states the action ('soft-delete') and the resource ('webhook endpoint'), and explains the effect (no longer receives deliveries). This distinguishes it from sibling tools like createEndpoint or listEndpoints.

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 vs alternatives, no prerequisites or when-not-to-use conditions. The schema parameter description hints that the ID comes from listEndpoints, but the main description lacks explicit usage guidance.

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

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

Annotations already set destructiveHint=true, so the agent knows it's destructive. The description adds no further behavioral context (e.g., irreversibility), but does not contradict annotations.

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

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

Extremely concise at one sentence, but could be slightly more informative. Still efficient and maintains 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?

Given the simple nature of a delete operation, the output schema existence, and annotations covering destructiveness, the description is largely complete. However, it lacks mention of idempotency (idempotentHint=false) or any post-deletion effects.

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

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

The schema has 100% coverage and the description adds 'Filter rule ID from listFilters or createFilter,' clarifying the source of valid IDs beyond what the schema provides (just uuid 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 'Delete a filter rule' uses a specific verb and resource, clearly distinguishing it from sibling tools like createFilter or listFilters.

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 vs alternatives, nor any prerequisites or conditions. The schema hints that the ID comes from listFilters or createFilter, but the description itself provides no usage context.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling a safe read operation. The description adds value by explaining the output format (plain text BIND zone file) and the use case involving bulk import. No contradictions with annotations.

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

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

The description is concise, consisting of just two sentences that are front-loaded with the core purpose. Every sentence adds useful information without redundancy or fluff.

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

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

The description is sufficient for an agent to understand the tool's function and output format. With an output schema present (implied), the description does not need to detail return values. The parameters are well-described in the schema. The description could briefly mention the outbound_only parameter's behavior, but it is already covered in the schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The tool description does not add extra meaning about the parameters beyond what the schema provides, earning a baseline score of 3.

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

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

The description clearly states the tool's purpose: downloading a BIND-format DNS zone file for a domain. The verb 'download' and resource 'DNS zone file' are specific, and the format is mentioned. This distinguishes it from sibling tools like addDomain or verifyDomain, which serve different functions.

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

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

The description provides a clear use case: 'Useful when users want to import all required DNS records at once rather than copying them individually.' This gives context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools are distinct enough that no confusion arises.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description is consistent and adds context: the return format (base64, count, digest) and the recommendation to use getEmail first. There is no contradiction. The description does not mention rate limits or authentication needs, but the safety profile is covered by annotations.

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

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

The description is two sentences: first states purpose and outcome, second gives usage guidance. It is front-loaded, concise, and every sentence adds value. 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 the moderate complexity and the presence of an output schema (mentioned in context), the description adequately covers the return values (base64 archive, count, SHA-256 digest) and the workflow hint. No missing critical details for a read-only download tool.

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

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

Schema coverage is 100% (both parameters documented), so baseline is 3. The description adds value by explaining that the token parameter is optional and that the bearer token is used when omitted. It also advises on workflow (check attachment manifest first), indirectly guiding parameter usage. No additional parameter constraints 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 clearly states the tool downloads all attachments from an inbound email and returns a gzip-compressed tar archive as a base64-encoded string with count and SHA-256 digest. It specifies the resource (inbound email attachments) and action (download), distinguishing it from siblings like getEmail by advising to check the attachment manifest first.

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 guidance: 'Prefer getEmail first to check the attachment manifest before downloading.' This recommends a workflow and implies when not to use this tool directly. The optional token parameter is also explained. However, it does not explicitly state when not to use it or list alternative tools for other scenarios.

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

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

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false, consistent with a read operation. The description adds useful detail about the managed_inbox_address field being a domain (not a mailbox) and clarifies that when non-null, the result includes sender_address. No contradictions.

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

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

The description is two sentences, efficiently conveying purpose and key details about return fields. It is front-loaded with the primary use case. Minor redundancy in explaining managed_inbox_address could be condensed, but overall concise.

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

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

Given the presence of an output schema (which handles return value details), the description adequately covers purpose, parameter usage nuance, and a specific field behavior. No obvious gaps for this simple read 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 baseline is 3. The description adds value by explaining how the api_key parameter is conditionally required ('Only needed when this connection has no signed-in account: pass the api_key returned by createEmailAddress...'), which aids correct invocation beyond 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 the tool retrieves the authenticated Primitive account summary, listing specific fields (plan, onboarding state, managed inbox domain). It distinguishes itself from siblings by focusing on account-level information rather than email operations or domain management.

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 specifies when to use the tool ('when you need the authenticated Primitive account summary'). However, it does not explicitly state when not to use it or mention alternative tools for similar data, though context suggests it is unique among 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?

The description adds significant detail beyond annotations: ordered turns, direction/role derivation, truncated boolean, message_count field, and behavior for brand-new messages. Annotations already indicate read-only, idempotent, non-destructive, and the description is consistent.

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

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

The description is three sentences, front-loaded with the core purpose, followed by important edge-case and output details. 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?

Given the simple single-parameter input and presence of an output schema, the description adequately covers the output structure and key behaviors. Minor omission: no mention of pagination or message cap value, but overall 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 has full coverage (100%) for a single parameter with a clear description. The tool description adds slight extra context (oldest-first ordering, role derivation) but does not significantly expand on the schema.

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

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

The description clearly states the tool retrieves the full conversation for an inbound email, ordered as chat-model-ready turns with direction and role. It is specific about the resource and verb, and distinguishes from siblings like getEmail and getThread by focusing on the full conversation.

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

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

The description implies usage context, such as returning a single turn for a new message, but does not explicitly state when to use this tool versus alternatives. It is clear but lacks explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, idempotent read. The description adds context about returned content but does not disclose additional behavioral traits such as rate limits, failure modes, or authentication prerequisites beyond what the api_key parameter description already explains.

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

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

The description is a single, front-loaded sentence that states the trigger condition and then lists the included data categories. It is concise with no wasted words, each part contributing to the tool's purpose.

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

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

An output schema exists, so return values are already documented. The description covers the core purpose and content, and parameters are fully described in the schema. It could mention alternatives like getConversation or getThread, but overall it is sufficient for a well-annotated read 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%, and both id and api_key have detailed descriptions explaining provenance and usage. The tool description itself does not add parameter-level meaning, 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 action ('get full details') and the resource ('one inbound email ID'), enumerating the included data categories (parsed bodies, threading metadata, SMTP envelope, webhook state, replies). This makes it distinct from sibling tools like getConversation or getSentEmail.

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 opens with 'Use this when you need full details for one inbound email ID,' providing explicit context for when to invoke the tool. It does not name alternative tools or exclusions, but the 'when' phrasing is clear enough to guide selection among 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by specifying the exact read outputs (domains, routes, deployed Functions, recent inbound activity), making the scope transparent. No contradictions; could optionally mention auth caveats, but the schema covers api_key semantics.

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

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

Two sentences, each earning its place: first states the trigger condition, second enumerates the return payload. No filler, front-loaded with the use case. Ideal conciseness.

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

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

Given a simple single-parameter tool with an output schema present, the description covers the functional context (inbound readiness check) and return categories. Since an output schema exists, it needn't detail exact fields. Complete and appropriately scoped.

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

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

Input schema has 100% description coverage, including detailed guidance on when to include api_key ('Only needed when this connection has no signed-in account...'). The description adds no parameter-level detail, but the schema fully compensates, so baseline 3 is appropriate.

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

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

Description clearly states the tool's purpose: 'Use this when the user asks whether inbound email is ready or needs setup.' It also lists what it returns (domains, routes, deployed Functions, recent inbound activity), distinguishing it from siblings like getOutboundStatus by focusing on inbound readiness.

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 gives a when-to-use trigger: 'when the user asks whether inbound email is ready or needs setup.' It does not list exclusions or alternative tools directly, but the specific use case provides clear context relative to siblings. Lacks an explicit 'instead of' alternative, hence not a 5.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral detail about pending DNS verification and next actions, which is not covered by annotations. No contradiction.

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

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

Two sentences, front-loaded with a question that captures the tool's purpose. Every sentence is meaningful and contributes to understanding. 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?

With no parameters, clear annotations, and an output schema, the description fully equips the agent to decide when to call the tool. It explains the timing relative to sendEmail and the error context, which is sufficient 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?

Tool has no parameters, and schema coverage is 100%. Description does not need to explain parameter semantics. The baseline for 0-param tools is 4, and the description provides no extraneous info.

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 starts with a clear question 'What can I send FROM?' and explicitly states it lists verified sendable domains and pending verification domains, with next actions. It distinguishes itself from sibling tools like 'listDomains' by focusing on outbound sendability.

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 tells the agent to call this BEFORE sendEmail to pick a valid from domain, and warns that the account email may not be sendable. Also mentions the error message that echoes this list, helping the agent understand when to use it to avoid errors.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about what is returned (body_text, body_html) and specific use cases (SMTP response, gate denial reason), which are behavioral details beyond the annotations. No contradictions.

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

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

Two sentences: first states purpose, second provides use-case examples. No wasted words, front-loaded with key information. Excellent conciseness for the complexity level.

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 (1 parameter, 100% schema coverage, good annotations, and an output schema), the description is complete. It explains what the tool does, what fields are included, and when to use it. No gaps remain.

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

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

Schema coverage is 100% with a single parameter 'id' described as 'Sent email ID from listSentEmails or a /send-mail response.' The tool description does not add additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the action: 'Get the full record for a single sent email by id, including body_text and body_html.' It uses a specific verb and resource, and the sibling list includes similar tools like getEmail and listSentEmails, but this description uniquely specifies that it retrieves the full record for a sent email, differentiating it from others.

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 use cases: 'Use to inspect delivery details for a specific send — e.g. the SMTP response on a bounced row, or the gate denial reason on a gate_denied row.' This tells the agent when to use the tool. However, it does not mention when not to use it or offer direct alternatives, though the sibling names imply alternatives like listSentEmails.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable behavioral details: message ordering (oldest-first), message structure (direction, id), truncation detection, and cross-reference to other tools for full bodies. No contradictions.

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

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

Three sentences with no redundant information. The first sentence immediately states the core purpose and output structure. Subsequent sentences provide essential usage details. Efficiently 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 presence of an output schema (presumably detailing metadata and message fields), the description appropriately explains the thread structure, how to interpret completeness, and how to retrieve full message bodies. It leaves no critical gaps for a get-by-id tool.

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

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

Schema coverage is 100% with a clear description for the single parameter 'id'. The description reinforces the source of the ID (from any email or sent-email) and explains its role. This adds a helpful usage context beyond 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 the tool retrieves a conversation thread by ID, including metadata and all messages interleaved oldest-first. It specifies each message has direction and ID, and distinguishes from sibling tools like getEmail and getSentEmail by referencing them for fetching message bodies.

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 guidance on how to obtain the thread_id (from any email or sent-email record) and how to use the result (compare message_count vs messages.length for truncation, use getEmail/getSentEmail for bodies). Does not explicitly state when not to use this tool, but the context is sufficiently directive.

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

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

Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false. The description adds that the tool returns verification status and DNS records, which is useful context without contradicting annotations.

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

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

The description is two concise sentences with no wasted words. It front-loads the action and scope, followed by a practical usage hint.

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 zero parameters and an output schema present, the description fully covers the tool's behavior: listing all inbound domains with verification status and DNS records, and provides a use-case (before addDomain).

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, and the description adds meaning beyond the schema by explaining the output content (verification status, DNS records) and the tool's purpose, which is fully adequate given the parameter count is zero.

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

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

The description clearly states the verb 'list', the resource 'inbound domains', and the scope 'both verified and unverified'. It also mentions the output includes verification status and DNS records, distinguishing it from related tools like addDomain.

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

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

The description explicitly advises 'Use before addDomain to check whether a domain is already claimed', providing a clear when-to-use scenario and indicating an alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds limited behavioral context by mentioning cursor pagination, status filters, date filters, and sender/recipient search, but these are already evident from the parameter schema. It does not disclose additional behaviors like long-polling behavior, which is documented in the schema but not the description. No contradiction with annotations.

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

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

The description is a single, focused sentence that immediately states the use case and lists capabilities. It contains no fluff, repetitive phrasing, or unnecessary details. Every word contributes to orienting the agent.

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

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

Given the tool's complexity (10 parameters, output schema present), the description is succinct yet sufficient. It captures the primary use case and key capabilities, while the rich schema and output schema cover operational details like cursor formats, date formats, and return structure. However, it could briefly mention pagination strategy or distinguish between `since` and `cursor`, though those are documented in the schema.

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

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

Schema description coverage is 100%, so every parameter has a detailed description. The tool description provides a high-level summary of filtering dimensions (status, date, sender/recipient) but does not add meaning beyond the schema. It correctly aggregates parameter groups but does not explain syntax, relationships, or edge cases beyond what the schema already covers.

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

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

The description clearly identifies the tool's function: browsing inbound emails received at verified domains. It specifies the resource ('inbound emails'), the scope ('received at verified domains'), and enumerates key capabilities (cursor pagination, status filters, date filters, sender/recipient search). This differentiates it from siblings like listSentEmails, getEmail, and searchEmails by clarifying it is for listing/browsing inbound mail with filter options.

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 begins with 'Use this when you need to browse inbound emails...', providing an explicit use case. It implies this is the tool for browsing/filtering inbound mail rather than searching or retrieving individual emails. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's job is light. It adds value by specifying that each endpoint shows its URL, enabled state, and optional domain restriction. No contradictions.

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

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

The description is a single sentence with no filler. It front-loads the key action and resource, stating exactly what is listed. 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 zero parameters, existing output schema, and annotations covering safety, the description is complete. It clearly explains the tool's purpose and output fields.

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 schema_description_coverage is 100%. Per guidelines, baseline is 4. The description does not need to add 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 clearly states the action (list), resource (webhook endpoints), and scope (active, for the organization). It is specific and distinguishes from sibling tools that perform different operations like createEndpoint or deleteEndpoint.

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 prerequisites, limitations, or when not to use it. For a simple listing tool, this is adequate but minimal.

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

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

The description adds context beyond annotations by specifying that it lists both whitelist and blocklist rules. Annotations already indicate readOnlyHint and destructiveHint, so the description complements them with specifics about the type of data returned.

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

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

The description is a single, clear sentence with no unnecessary words. It is front-loaded and effectively conveys the tool's purpose.

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

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

Given that the tool has no parameters and an output schema exists, the description is largely complete. However, it does not mention potential pagination or scope limitations (e.g., whether 'all' means all time or filtered), but this is minor for a 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?

There are no parameters, so the description does not need to add meaning beyond the schema. The baseline score of 4 is appropriate as no parameter information is required.

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 lists all whitelist and blocklist filter rules for the organization. This provides a specific verb ('list') and resource ('filter rules') and differentiates it from sibling tools like createFilter and deleteFilter.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It lacks context about prerequisites, when not to use it, or how it relates to other filter-related tools.

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

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

Annotations already declare readOnlyHint=true, so the tool is safe. The description adds that bodies are omitted to keep responses small, which is a key behavioral trait beyond annotations. No contradictions.

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

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

The description is only two sentences, each with clear value: first sentence states purpose and key features, second sentence gives use cases and tool alternatives. No filler 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?

Despite 7 optional parameters and an output schema, the description covers all essential context: what the tool does, pagination behavior, body omission, and common use cases. Output schema is present, so return values need not be explained.

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 all parameters are already documented. The tool description does not add additional meaning beyond summarizing the purpose of filters and pagination. Baseline 3 is appropriate.

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

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

The description clearly states the action (List), resource (outbound emails), and key features (cursor pagination and filters). It distinguishes itself from getSentEmail by noting that bodies are omitted. This provides a specific verb+resource scope.

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

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

The description explicitly tells when to use this tool (auditing delivery, finding bounced sends, checking gate-denied attempts) and directs users to getSentEmail for full email bodies. It does not list negative cases, but the positive guidance is strong.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context by mentioning pagination, filters, and the structure of each delivery (endpoint and nested email object), which goes beyond the annotations.

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

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

The description is two sentences long, front-loaded with the core functionality, and includes a practical use case. Every word serves a purpose with no redundancy.

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

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

Given that the tool has an output schema (so return structure is not needed in description), strong annotations, and 6 optional parameters, the description covers the key aspects: purpose, what each delivery contains, and a primary use case. It is slightly lacking in explaining pagination details like the cursor usage, but the schema parameters already cover that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'pagination and filters' which vaguely relates to parameters, but it does not add specific parameter-level meaning beyond 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 clearly states the action ('List webhook delivery attempts') and the resource ('webhook deliveries'). It specifies pagination and filters, and distinguishes from siblings like listEmails or listEndpoints by focusing on delivery attempts with nested email objects.

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

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

The description provides a clear use case ('diagnosing delivery failures or confirming a specific email was delivered'), giving context for when to use the tool. However, it does not explicitly mention when not to use it or name alternative tools like replayWebhookDelivery.

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

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

Annotations are minimal (no readOnlyHint, etc.), so the description carries the burden of behavioral disclosure. It adds the rate-limiting constraint, which is critical for an agent. However, it does not clarify potential side effects (e.g., idempotency is false but no mention of duplicates). Still, the added value is high.

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

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

The description is two sentences, front-loaded with purpose, followed by critical constraint. No unnecessary words. Every sentence adds value.

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

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

For a simple tool with one parameter and an output schema, the description covers the purpose and a key behavioral constraint (rate limits). It does not mention error cases or prerequisites like payload availability, but these are implied. Overall adequate.

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

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

The schema has 100% coverage for the single parameter 'id', with a clear description in the schema. The tool description does not add any additional parameter-level information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states this tool re-sends a stored webhook payload to its original endpoint, distinguishing it from sibling tools like listWebhookDeliveries or testEndpoint. It uses specific language ('re-send', 'stored webhook payload', 'original endpoint').

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 by mentioning rate limits per org with burst and sustained windows and shared budget. It implies when to consider using this tool (with rate awareness), but does not explicitly list when not to use or alternatives.

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

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

Annotations already convey a write/non-read-only, destructive, non-idempotent, open-world action. The description adds meaningful context by stating it sends a real outbound email (external side effect) and that threading is handled server-side. It also mentions a user-confirmation prerequisite, which is a useful behavioral guardrail. No contradiction with annotations.

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

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

The description is a single, tight sentence that is front-loaded with the trigger condition and states the key side effect/behavior. No filler or repetitive 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?

For a tool with a rich schema and annotations, the description covers the essential selection context (selected inbound email, confirmed reply, real sending, server-side threading) and works with the annotation flags. Since an output schema exists, return details are not required. It could mention auth prerequisites more explicitly, but the api_key parameter description covers that.

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 description contains no parameter-specific explanations; it does not mention id, requestBody, api_key, body fields, or attachments. The schema already describes most parameters (67% coverage, with requestBody itself lacking a description), and the description does not compensate for that gap or add any additional parameter 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 uses a specific verb ('reply') and identifies a precise resource/context: a specific inbound email the user has selected and confirmed. It distinguishes the action from siblings by stating this is for replies to inbound email, not new mail.

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 use: when the user has selected a specific inbound email and confirmed a reply. It does not, however, name alternative tools (e.g., sendEmail) or provide explicit 'do not use' conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by providing the polling pattern and indicating that the tool supports both structured filters and full-text matching. No contradictions.

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

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

Two sentences, each earning its place: the first explains the tool's purpose and capabilities, the second provides a specific usage pattern. No wasted words.

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

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

The tool has 18 parameters and an output schema, all documented. The description covers the main use case and polling pattern. It could mention pagination or default behavior, but overall it is sufficiently complete 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?

With 100% schema description coverage, the baseline is 3. The description adds extra guidance on combining sort and date_from for polling, which is a valuable usage hint. This justifies a score of 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 clearly states the tool finds inbound emails with structured filters or full-text matching, distinguishing it from siblings like listEmails and getEmail. The specific verb 'search' and resource 'inbound emails' make the purpose unambiguous.

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

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

The description provides a clear when-to-use scenario and a specific polling pattern (sort=received_at_asc plus date_from). However, it does not explicitly mention alternatives or when not to use this tool, though the context of sibling tools implies simpler alternatives.

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

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

Annotations already mark destructiveHint=true, and the description reinforces that by stating 'sends real email.' It adds behavioral details: can wait for SMTP delivery outcome, schedule send, and warns about `from` misuse. It mentions the post-send awaitReply step. Missing details like rate limits or cancellation behavior are partially covered by sibling tools, and annotations provide the base safety profile.

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

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

The description is compact: three sentences each serving a distinct purpose (usage trigger, core behavior, critical instruction and post-send action). It is front-loaded with the use case, and every sentence adds necessary information without redundancy. 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?

Given the tool's complexity (nested schema, many parameters, output schema present), the description covers the essential workflow: when to use, what it does, the critical `from` rule, and the post-send step with awaitReply. It references sibling tools for setup (createEmailAddress) and follow-up (awaitReply). The output schema exists, so the lack of return value details is acceptable. Minor gap: no mention of error states or the Idempotency-Key behavior, but these are covered in the schema.

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

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

The schema itself has a high level of detail (67% coverage) with descriptions for most parameters. The main description adds value for the `from` parameter ('YOUR OWN complete mailbox address, never the recipient's') and references sender_address from createEmailAddress/getAccount. However, it does not explain other key parameters like to, subject, attachments, or the interplay between wait and scheduled_at beyond a brief mention. The schema does the heavy lifting, so the description's additional semantic contribution is modest.

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

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

The description clearly states it sends real email through Primitive's relay, with options to wait or schedule. It specifies it is for new outbound emails only, distinguishing it from siblings like replyToEmail (replies) and sendEmailDemo (demo). The verb 'sends' plus resource 'email' with explicit scope is specific and unambiguous.

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

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

The description explicitly says 'Use this when the user has confirmed a new outbound email,' providing clear when-to-use context. It adds critical guidance: the `from` field must be your own address, and after sending, call awaitReply if expecting an answer. It does not explicitly exclude sibling tools for other scenarios (e.g., replying), but the narrowing to 'new outbound' 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?

Annotations declare readOnlyHint and idempotentHint and destructiveHint=false, but the description adds significant behavioral details: no message is sent, queued, or stored; recipient receives nothing; validates against the exact sendEmail schema; returns an envelope with demo:true; and enforces a 16KB total body cap. All this context is beyond what annotations provide and is consistent with them.

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

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

The description is moderately lengthy but every sentence adds value: simulation warning, when-not-to-use, alternative tool path, validation coverage, size limit. It is front-loaded with the critical simulation warning and well-structured. Could trim slightly but is effectively composed.

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

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

Given the tool's complexity (nested object parameter, many fields, output schema exists), the description covers purpose, usage constraints, behavioral details, and size limits. It refers to the output schema implicitly by describing the synthetic envelope. The presence of an output schema reduces the need to describe return values in detail, so the description is complete for an agent to correctly select and invoke this 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 0%, but the description provides meaningful context about the requestBody parameter: it validates against the sendEmail schema (including cc/bcc, reply_to, tags, attachments, scheduled_at) and has a 16KB total body limit that can reject large attachments. This adds practical constraints not captured in the schema alone, earning a score above the baseline of 3.

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

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

The description clearly states the tool is a simulation that previews a send by validating the request body against the same schema as sendEmail and returning a synthetic envelope with demo:true. It explicitly distinguishes from the actual sendEmail tool and provides the correct alternative using createEmailAddress and sendEmail. Scope and resource are unambiguous.

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

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

The description explicitly warns when NOT to use this tool (when the user wants an email delivered) and provides the correct alternative path (createEmailAddress then sendEmail). It also clarifies that the tool exists only to preview the response shape, giving clear context for appropriate invocation.

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

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

Discloses rate limits (4/min, 30/hr) and exemption conditions beyond annotations. No contradiction with annotations; non-destructive nature is implied.

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

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

Three concise sentences front-loading the primary purpose, then adding rate limits and exemptions. 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?

Simple tool with 1 param and output schema; description covers purpose, rate limiting, and parameter source. 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?

Only one parameter (id) fully described in schema. Description adds no extra semantics beyond the schema's 'Endpoint ID from listEndpoints or createEndpoint.' Schema coverage 100% justifies baseline 3.

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

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

Clearly states the tool sends a sample email.received event to test a webhook endpoint for verifying signature verifier. Differentiates from siblings like replayWebhookDelivery by specifying the 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?

Provides context on when to use (to verify signature verifier) and mentions rate limits and exemptions. Does not explicitly exclude other tools, but the purpose is clear enough.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds context about DNS checks and propagation wait, and clarifies state change on success. No contradiction with annotations.

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

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

Three sentences, front-loaded with purpose, no redundant information. Every sentence adds value: purpose, success/failure behavior, and retry guidance.

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 a single parameter, full schema coverage, and an output schema (not shown), the description covers what happens on success and failure, and provides retry advice. It is sufficient for an agent to use correctly.

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

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

Only one parameter 'id' with full schema description (100% coverage) linking it to addDomain/listDomains. Tool description doesn't add extra parameter detail beyond what's in the schema, so baseline of 3 is appropriate.

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

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

The description clearly states the verb 'check DNS records' and the resource 'domain claim', specifying the record types (MX, TXT, SPF, DKIM, DMARC). It distinguishes the tool from siblings like 'addDomain' by focusing on verification.

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

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

Explicitly says to use after adding a domain and on failure to wait and retry. Explains outcome: verified domains start receiving mail. Doesn't explicitly state when not to use or contrast with siblings, but the context is clear enough.

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