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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning prerequisites, side effects, duplicate handling, or idempotency. For a mutation tool, this is a significant gap.

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

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

The description is a single, front-loaded sentence that efficiently states the purpose. It is concise and easy to parse, though it omits important context. It is not overly verbose, so it earns a high score for structure.

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 annotations, no output schema, and a very short description, the tool is under-specified. It does not explain return values, error conditions, or whether the contact and segment must already exist. For a simple mutation tool, more context is needed to use it confidently.

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

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

The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds the 'by contact ID or email' hint, which clarifies alternative identifiers but does not explain their relationship to the required-only segmentId, adding only marginal value over 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 'Add a contact to a segment' with a specific verb and resource, and adds 'by contact ID or email' to clarify the two identification methods. It distinguishes from the sibling tool 'remove-contact-from-segment'.

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

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

The description implies usage context by indicating the contact can be specified by ID or email, but it does not explicitly compare this tool to alternatives or state when not to use it. Sibling tools are not referenced, so the agent gets only implicit guidance.

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

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

Annotations only declare readOnly/destructive/openWorld hints; the description adds real behavioral facts beyond them: the operation is additive and idempotent ("Adding a label the thread already carries changes nothing") and atomic ("If any label ID is not found, nothing changes"). It also states the post-change return content.

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?

Four labeled sections, each one sentence, front-loaded with Purpose and constrained to what an agent needs (scope, exclusions, return, usage). No filler or restated boilerplate.

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 output schema, the description correctly compensates by specifying the return value (all labels on the thread after the change), and it covers failure and idempotency behavior. The only completeness gap is the absence of any contrast with set-inbox-thread-labels, a sibling that also applies labels and could plausibly be selected for the same request.

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 inboxId (including the email-address form), threadId, and labelIds (with the 10-item cap). The description only adds ID-provenance hints (list-inbox-threads, list-inbox-labels), which is useful routing rather than parameter meaning. 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 first line states a specific verb, resource, and scope: tag one thread in a Resend inbox with one or more labels, and it immediately clarifies the additive semantics ("Labels already on the thread stay on it"). It also names the operation it is not (remove-inbox-thread-label). The only missed differentiation is against the very similar set-inbox-thread-labels sibling, but the verb choice and additive qualifier still make the purpose unmistakable.

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

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

Explicit when-to-use ("User asks to tag, label, or categorize a thread"), explicit when-not (removing labels, creating labels), and named alternatives (remove-inbox-thread-label, create-inbox-label) with prerequisites (create-inbox-label first). It even tells the agent where IDs come from (list-inbox-threads, list-inbox-labels). Only gap is that it never contrasts with set-inbox-thread-labels, the closest sibling.

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

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

The description discloses key behavioral traits: suppressed addresses 'never receive emails from the account, even when included as recipients,' and it clarifies the manual vs. automatic nature of suppression. It does not cover edge cases like duplicate suppression or reversibility, but the core behavior is well 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 three sentences, front-loaded with the core purpose. Every sentence earns its place: the action, the behavioral implication, and the alternative for bulk operations. There is no redundancy or wasted words.

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

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

Given the simple single-parameter schema and lack of annotations or output schema, the description is complete enough for an agent to select and invoke the tool. It covers purpose, usage guidance, and the key behavioral consequence, leaving no critical 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 already fully describes the only parameter ('email') with a format and description. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: 'Add an email address to the suppression list in Resend.' It uses a specific verb and resource, and explicitly distinguishes itself from batch-add-suppressions by mentioning that alternative.

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 when-to-use guidance, noting that hard bounces and spam complaints are added automatically and this tool is for manual suppression 'e.g., to honor a do-not-contact request.' It also directs users to batch-add-suppressions for multiple addresses, giving a clear 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?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It conveys the key effect (suppressed addresses never receive emails) and the automatic nature of hard bounces/spam complaints. However, it does not mention eventual consistency, idempotency, partial failures, or permissions required, leaving some transparency gaps for a mutation tool.

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

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

The description is three sentences, front-loaded with the core purpose, and each subsequent sentence adds meaningful context about behavior, usage, and an alternative. There is no redundancy or filler.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, when to use it, and how it relates to alternatives. It lacks explicit information about return values or error behavior, but these are less critical for a straightforward batch add 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?

The schema already has 100% coverage: the only parameter 'emails' is described as 'Email addresses to suppress' with format/pattern. The description adds minimal extra semantic value beyond restating 'multiple email addresses,' so a baseline score of 3 is appropriate.

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

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

The description opens with 'Add multiple email addresses to the suppression list in Resend in a single call,' clearly specifying the verb, resource, and scope. It distinguishes itself from the sibling 'add-suppression' by explicitly noting the single-address alternative and from batch-remove operations by focusing on adding.

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

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

The description states when to use this tool: to manually suppress addresses when needed (e.g., do-not-contact requests), and contrasts this with automatic suppression from hard bounces and spam complaints. It also explicitly directs users to 'add-suppression' for a single address, providing a clear 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the effect ('addresses will start receiving emails again'), warns about deliverability risks, and mandates user confirmation. It does not cover all aspects like permissions or error handling, but it provides substantial context beyond the schema.

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

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

The description is moderately concise, with three sentences covering purpose, effect, and safety. The final sentence is somewhat long but contains essential warnings. It is organized and each sentence contributes, though it could be tightened without losing meaning.

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

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

For a tool with two parameters and no output schema or annotations, the description is fairly complete. It covers the key behavioral and safety aspects, parameter constraints, and the user-confirmation requirement. Missing details like return format or partial failure behavior are minor given the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds crucial meaning by stating 'provide exactly one of the two' and clarifying the purpose of each parameter (emails vs IDs), which goes beyond the schema's 'Cannot be used with' notes by emphasizing the exclusivity and necessity.

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

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

The description clearly states the tool's function: 'Remove multiple entries from the suppression list in Resend in a single call' and specifies the two modes (by email or by ID). This distinguishes it from siblings like remove-suppression (single removal) and batch-add-suppressions (adding).

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

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

The description provides clear usage context, including the requirement to double-check with the user and obtain explicit confirmation before using. However, it does not explicitly name alternative tools for single removals, so it stops short of fully clarifying when-not-to-use compared to specific siblings.

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

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

With no annotations, the description bears the entire behavioral burden. It fully discloses the nuanced effects: queued broadcasts stop mid-send, already-sent emails are unaffected, scheduled broadcasts revert to draft, and sent broadcasts are immutable. This goes well beyond minimal 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 structured with purpose, exclusions, and when-to-use sections, and every sentence earns its place. It is front-loaded with the core purpose and avoids filler while still covering edge cases.

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

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

For a single-parameter mutation tool with no output schema, the description provides strong contextual completeness: purpose, target states, exclusions, and a sibling pointer. The only minor gap is not describing the cancellation response or confirming idempotency, but this is not critical for correct invocation.

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

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

Schema description coverage is 100% and already includes the broadcast ID/URL meaning and example. The tool description adds no extra detail about the parameter beyond what the input schema provides, so the baseline applicable score is correct.

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

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

The description states a clear verb+resource: cancel a queued or scheduled broadcast by ID or dashboard URL, with the explicit scope that it removes no broadcast. It distinguishes itself from remove-broadcast by name, so an agent can tell this tool apart from its closest sibling.

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 gives explicit 'NOT for' guidance, excludes drafts and sent broadcasts, and tells the agent to use remove-broadcast instead when removal is intended. It also defines a concise 'When to use' trigger matching common user phrasing like 'stop', 'cancel', or 'pause'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key limitation (only works for scheduledAt emails) but does not mention what happens if the email has already been sent, whether cancellation is reversible, or error handling. This is a moderate gap for a mutation tool.

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

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

The description is exactly two sentences, front-loaded with the core action and immediately followed by a critical condition. Every word is essential, with no repetition 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?

For a single-parameter tool with full schema coverage and no output schema, the description covers the purpose, the main precondition, and the parameter's role. It does not specify failure behavior (e.g., already-sent emails), but this is a minor omission given the tool's simplicity.

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

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

The input schema fully describes 'id' as 'The ID of the scheduled email to cancel', and the description adds a meaningful semantic constraint: the email must have been scheduled using scheduledAt. This helps the agent understand which IDs are valid, going slightly beyond the schema's description.

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

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

The description clearly states the specific action 'Cancel a scheduled email' and the resource (scheduled email) with a scope condition ('that has not yet been sent'). This distinguishes it from sibling tools like update-email or send-email, making 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?

It explains when to use the tool (for canceling scheduled emails) and provides an explicit exclusion: 'Only works for emails that were scheduled using the scheduledAt parameter.' It does not name alternative tools like update-email, but the condition clearly implies when this tool is not appropriate.

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

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

With no annotations, the description carries full burden and excels: discloses automatic connect/disconnect from editor, warns that skipping get-tiptap-json-content will overwrite existing content, and notes that switching between compose and update modes is lossy. These are meaningful behavioral traits beyond annotations.

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

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

Well-structured with bold headers, bullet lists, and a clear flow. Each sentence earns its place—purpose, recommendation, workflow, when-to-use, important warning, and note. Front-loaded with the core 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?

Despite no annotations or output schema, the description covers purpose, usage workflow, prerequisites, warnings, and limitations. It is sufficiently complete for a tool with 5 parameters (1 required) and no return value expectations.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that content is TipTap JSON and that metadata (subject, preview text, name) can be updated in the same call, reinforcing the schema's parameter descriptions and the combined-use capability.

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

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

The description opens with a specific verb+resource: 'Set the TipTap JSON content of a broadcast, enabling it to be edited visually in the Resend dashboard editor.' It clearly distinguishes from siblings by labeling it 'the recommended way to set email content' and contrasting with 'update (raw HTML)' mode in the note.

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 'When to use' bullets (after create-broadcast, for writing/editing/styling content, for dashboard collaboration) and a workflow: get-tiptap-json-content → compose-broadcast. It also gives an exclusion: if broadcast already has HTML content, ask the user before switching to compose mode due to lossy conversion.

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

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

With no annotations, the description carries the full burden. It discloses that the tool 'Automatically connects and disconnects from the editor,' warns that skipping get-tiptap-json-content will 'overwrite all existing content,' and explicitly notes that switching between compose and update modes is 'lossy' and that HTML content may be lost. These side effects are critical for safe usage.

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 somewhat long but well-structured with bold section headers (Purpose, Workflow, When to use, Important, Note). Each section adds value, though there is some redundancy with the schema's parameter descriptions (e.g., the 'Important' note repeats the content parameter's description). It earns a high score for clarity and organization, but loses a point for minor repetition.

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

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

For a complex tool involving TipTap JSON, dashboard editor connectivity, and potential data loss, the description is remarkably complete. It explains the full workflow, prerequisites, side effects, and when to defer to the user. It also addresses the nuance of switching from HTML to compose mode, which is essential for avoiding destructive actions. No output schema is present, but for a mutation tool this is acceptable.

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

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

Schema description coverage is 100%, and the schema already provides detailed descriptions for each parameter (e.g., content param says 'Call get-tiptap-json-content (with include_schema: true) first...'). The tool description repeats this advice but doesn't add significant new semantics beyond the schema. It reinforces the workflow but does not go beyond what structured fields already convey.

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: 'Set the TipTap JSON content of a template, enabling it to be edited visually in the Resend dashboard editor.' It also distinguishes itself from siblings by noting it can 'also update metadata (subject, name) in the same call' and by highlighting that it is 'the recommended way to set email content' compared to raw HTML updates.

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: a 'When to use' list (after create-template, when user wants to write/edit/style email content, when collaborating in dashboard), a recommended workflow (get-tiptap-json-content → compose-template), and a caution about not using it when template already has HTML content without asking. It also implies an alternative (update/raw HTML mode) by referring to 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?

With no annotations, the description carries the burden for behavioral context. It discloses that users see an avatar while connected, that compose tools disconnect when done, and that returns a token and room ID. However, it does not state whether the connection persists until disconnect-from-editor is called, any limits on concurrent connections, or what happens if the agent connects while another is already connected.

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 and well-structured with bold section labels (Purpose, When to use, Returns). Every sentence adds value, and the key information is front-loaded in the first line.

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, the description covers purpose, usage, exclusions, and return values. Minor gap: it does not explicitly mention the need to call disconnect-from-editor when the agent is done outside compose workflows, but the sibling tool name implies this. Overall complete enough for correct invocation.

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

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

Schema description coverage is 100% for all 3 parameters, so the schema already provides full parameter documentation. The description does not add meaningful semantics beyond returning a token/room ID, 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 states a specific purpose ('Show agent presence in the Resend dashboard editor') with a clear verb-resource pairing. It distinguishes this tool from siblings by explaining when it is not needed (before compose-broadcast/compose-template) and that get-tiptap-json-content connects automatically.

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 when-to-use guidance: signal agent presence outside compose workflows. Also explicitly lists exclusions ('Not needed before compose-broadcast or compose-template') and names an alternative (get-tiptap-json-content), which is exactly the kind of guidance 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 takes on the full burden of behavioral disclosure and does so well by warning that the token is only shown once and MUST be displayed to the user. This is a critical, non-obvious behavior that an agent needs to handle correctly.

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

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

Two concise sentences front-load the core action and immediately follow with the critical security behavior. Every word earns its place, and the must-display note is actionable.

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

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

For a simple create operation with three optional/required parameters and a detailed schema, the description is largely complete: it says what is created, and the token-display warning addresses the only truly hidden part of the response. It could mention response shape beyond the token, but this is only a minor gap.

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

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

Schema description coverage is 100%, so the parameter details live entirely in the schema. The description adds no additional parameter-level meaning, but per the baseline for high schema coverage, this is adequate.

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 ('Create') with a clear resource ('a new API key in Resend') and immediately distinguishes this from sibling tools like list-api-keys or remove-api-key. The one-time-token warning further clarifies what makes this operation unique.

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

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

The description does not state when to use this tool versus alternatives like update-api-key or list-api-keys. While 'Create' strongly implies its own use case, there is no explicit guidance on prerequisites, decisions between full_access and sending_access, or exclusions.

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

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

With no annotations, the description carries full responsibility and delivers thoroughly. It specifies behavior for each step type, fallback semantics for 'from'/'subject', error modes (silent failure, run error), structural rules (tree-shaped, reachability), and return value (Automation ID and dashboard link). This is exceptionally 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?

Although lengthy, the description is meticulously structured with headers, bullet points, and examples. It front-loads purpose and usage, and every section serves a functional need given the tool's complexity. 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 high complexity (nested steps, multiple step types, branching rules), the description fully equips the agent to construct valid workflows. It covers all step types, config schemas, constraints, and return values, with multiple examples.

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

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

The schema already has 100% description coverage, but the tool description goes far beyond schema definitions. It explains the exact structure of workflow steps, config objects, operator semantics, dynamic variables, and provides three complete examples. This adds immense 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?

Clearly states 'create an automation workflow that triggers on events and executes a sequence of steps.' This is a specific verb and resource, and it differentiates from sibling tools that update, remove, or get automations.

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 a dedicated 'When to use' section listing two concrete scenarios (automated email sequences, event-based actions). It also references a workflow with prerequisite tools, but does not explicitly mention when not to use or alternatives like update-automation, 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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: 'does NOT send yet', requires a segment ('There is no all contacts option'), personalization placeholders, and that switching between compose and html/text modes is lossy. This is substantial context beyond a simple create 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 long but highly structured with bold headers, bullet points, and sections. Every sentence serves a purpose: purpose, exclusions, return value, when-to-use, workflow, content options. Front-loaded with the most critical information. 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?

Given 8 parameters, no annotations, and no output schema, the description is exceptionally complete. It covers returns, workflow, personalization, segment requirements, alternatives, and content-authoring modes. This provides a full operating context for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter context by explaining when to use html/text vs compose-broadcast, and clarifies that the name can be auto-generated. It also notes the 'all contacts' limitation relevant to segmentId. This goes beyond 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 explicitly states the purpose: 'create a broadcast campaign (one email sent to an entire segment)'. It clearly distinguishes from send-broadcast, send-email, and create-contact with specific 'NOT for' examples. The verb+resource+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?

Provides explicit guidance on when to use: user intents like 'email my list', 'send a newsletter', 'broadcast to my segment'. Also includes 'NOT for' exclusions and a clear workflow (list-segments → create-broadcast → get-tiptap-json-content → compose-broadcast → send-broadcast). Names alternatives such as send-email and create-contact.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention idempotency, duplicate handling, side effects (e.g., welcome emails), permission requirements, or what happens if a segment ID or topic subscription is invalid. Only the basic creation action is stated.

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

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

The description is two sentences, front-loaded with the primary action, and includes the most important optional capabilities. No wasted words.

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

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

Given the tool's complexity (7 parameters, nested objects, no output schema) and absence of annotations, the description is too sparse. It omits behavior around duplicates, error handling, response format, and usage context relative to sibling tools, leaving significant gaps for an AI agent.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds a high-level hint about optional segment assignment and topic subscriptions, but does not add detail beyond what the schema already provides. 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 states 'Create a new contact in Resend' with a specific verb and resource, and mentions optional segment assignment and topic subscriptions. It is clear, but it does not explicitly distinguish from sibling 'create-contact-import', which also creates contacts (albeit in bulk).

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

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

No guidance is given on when to use this tool versus alternatives like 'update-contact', 'add-contact-to-segment', or 'update-contact-topics'. The description implies segment assignment and topic subscriptions are possible here, but does not clarify when to use this tool vs. the dedicated segment/topic mutation tools.

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

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

With no annotations, the description does the heavy lifting: it discloses asynchronous processing, that an import ID is returned immediately, the 100MB size cap, and that filePath may be disabled server-side. It omits auth/permission requirements and rate limits, but the key operational behaviors are 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?

Front-loaded with purpose, then the async workflow, then parameter selection guidance, then limit. Every sentence carries actionable content; 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?

For an async, 8-parameter tool with no output schema, the description covers input sourcing, exactly-one constraint, environment caveats, size limit, and the polling follow-up. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by stating the parameters are mutually exclusive ('exactly one of') and the environment-dependent behavior of filePath, plus the size limit.

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?

Specific verb (bulk-import) + resource (contacts) + method (from a CSV file), and it names the streaming follow-up tool get-contact-import. An agent can distinguish it from create-contact (single) and list-contact-imports without opening 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?

Explicitly routes the agent: call this, then use get-contact-import to poll status/counts. It also states the selection rule among filePath/content/url and the environment condition (prefer content/url where filePath is disabled), leaving nothing to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new contact property' without explaining potential side effects such as duplicate key errors, immutability of the property type after creation, or any permission requirements. This is a significant gap for a mutation tool.

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

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

The description is two sentences, front-loaded with the action, and contains no filler. The first sentence states what the tool does; the second defines the domain concept with examples. Every word earns its place.

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

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

The tool is simple with three well-documented parameters, but the description lacks important context such as what happens when a property with the same key already exists, whether the type is immutable after creation, or what the successful response contains. The schema covers parameter details, but the absence of annotations and output schema leaves behavioral gaps that the description does not fill.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minor value by giving examples of property keys and explaining what a contact property is, but it does not provide additional semantics for the 'fallbackValue' parameter beyond what the schema offers. This meets the baseline for high coverage.

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

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

The description clearly states 'Create a new contact property in Resend' with a specific verb and resource, and provides illustrative examples (e.g., company_name, plan_tier) that clarify what a contact property is. This distinguishes it from sibling CRUD tools like update-contact-property or list-contact-properties by focusing on the creation action.

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

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

No guidance is given about when to use this tool versus alternatives. It does not mention that for modifying an existing property one should use update-contact-property, nor does it address scenarios like checking for existing keys before creation. The only implied usage is 'create a new property,' which is not explicit.

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

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

With no annotations, the description carries the full transparency burden. It goes beyond a simple 'creates' statement by disclosing the critical behavioral requirement: 'You MUST display the DNS records to the user so they can set them up.' This is a concrete, actionable side effect that the agent must handle. However, it does not disclose other potential behaviors (e.g., rate limits, irreversibility), so a 4 is appropriate.

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

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

The description is two sentences, front-loaded with the primary action, and every word earns its place. It efficiently communicates purpose, output, and a critical mandatory action 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 8 parameters (one required, nested objects) and no output schema, the description provides a complete enough picture: it explains what the tool does, what it returns (DNS records), and what the agent must do with them. It does not explain the exact structure of the DNS records, but that is beyond the necessary remit and the key usage context is covered.

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

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

The input schema has 100% parameter description coverage, including details about defaults and meanings (e.g., TLS modes, region enums). The description adds no parameter-specific information beyond what the schema already provides. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb+resource: 'Create a new domain in Resend.' It also mentions the unique output (DNS records for verification), which distinguishes it from sibling tools like get-domain, update-domain, or verify-domain. This makes the tool's 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 clear context for when to use this tool: when creating a new domain and needing DNS records for verification. It implies a workflow (create domain → configure DNS → verify), but does not explicitly name alternatives or state when not to use it. The mandatory instruction to display DNS records gives practical 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?

With no annotations, the description carries the full burden and does well. It discloses key side effects: domain is recreated, brand-new DKIM keys are generated, previous DNS records become invalid, and a TXT record is returned that must be displayed and added to DNS. It also details the follow-up workflow. It doesn't cover failure modes or auth requirements, but the core behavioral impact is well communicated.

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

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

The description is four sentences, each earning its place: purpose, side effects, required action, and workflow. It is front-loaded with the core purpose and uses concise, imperative language. No filler or redundancy.

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

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

For a tool that initiates a multi-step workflow, the description gives a complete flow: returns a TXT record, user must add it, then verify-domain-claim, then poll get-domain-claim until status is 'completed'. It also explains the DKIM key reset, which is crucial context. It doesn't elaborate on failure cases or output structure, but the essential workflow is well covered given the schema handles parameter details.

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

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

Schema description coverage is 100%, with all six parameters having meaningful descriptions. The tool description adds no extra parameter-level detail beyond the schema, so the baseline of 3 is appropriate. It doesn't need to compensate for schema gaps.

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

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

The description clearly states the tool's specific purpose: 'Start a claim for a domain another Resend account has already verified.' This distinguishes it from create-domain (for new domains) and aligns with the claim workflow. The verb 'start' plus the resource 'domain claim' is explicit 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 provides clear usage context: use when a domain is already verified by another Resend account. It also gives explicit next steps: 'use verify-domain-claim, then poll get-domain-claim'. It doesn't explicitly say 'use instead of create-domain', but the scenario is clear enough to guide selection.

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

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

Annotations declare a non-read-only, non-destructive, closed-world write. The description adds meaningful context beyond that: domain verification prerequisite, the forwarding mode that returns a receiving address to point an external mail provider at, plus 403 for plan-limit teams and 451 for blocked accounts. It does not describe the success response shape, but error and prerequisite disclosure is solid.

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 the action and definition, then prerequisites/errors. Slightly dense but every sentence carries information. 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?

For a creation tool with no output schema and full schema coverage, the description covers the key prerequisites, the forwarding variant, and failure modes. The main gap is the success return value, which matters for an agent that needs the new inbox ID, but the core decision inputs are present.

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 name, fromName, forwarding, and emailAddress in detail. The description restates some of that (forwarding behavior, domain must exist) but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Create an inbox in Resend') and then defines what an inbox actually does (receives mail at a domain address, groups into threads). This clearly distinguishes it from get-inbox, update-inbox, list-inboxes, and remove-inbox.

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

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

Gives the precondition for use: the domain must already be verified for receiving, or forwarding must be true. It also explains the forwarding alternative's purpose (domain sends through Resend but receives elsewhere). It does not explicitly contrast with create-domain or other setup tools, 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 only confirm the write/non-destructive profile; the description adds substantial behavior: nothing is sent until send-inbox-draft runs, the 404 cases for bad threadId/replyToEmailId, the one-unsent-reply-draft rule and its field-ignoring/attachment-replacing consequence, and the idempotency semantics. This is far beyond what annotations provide.

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

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

Bold section headers (Purpose / NOT for / Returns / When to use) front-load the key routing facts, and every paragraph carries actionable content. It is on the long side, but the density is justified by the tool's many edge cases rather than padding.

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 an 11-parameter mutation tool with no output schema, the definition covers purpose, alternatives, return value (the draft id), error behavior, and the draftId linkage to get/update/send/remove-inbox-draft. Nothing an agent needs to invoke it correctly is missing.

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

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

With 100% schema coverage the baseline is 3, but the description adds meaning the schema does not: the threadId+replyToEmailId pairing rule, reply-draft recipient/subject resolution when 'to' or 'subject' are omitted, and the cross-field interaction where a second reply draft ignores all fields except attachments.

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

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

States a specific verb+resource+scope: 'Create a draft in a Resend inbox: a message saved for later, NOT sent.' It immediately distinguishes itself from send-inbox-draft and disambiguates the draft-vs-send boundary an agent must not blur.

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?

Explicit 'NOT for' section naming send-new-inbox-email, reply-to-inbox-thread-email, and forward-inbox-thread-email as alternatives, plus a 'When to use' section giving the triggering user intent (draft, compose, or prepare without sending). Routing is fully specified.

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

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

Annotations already declare this is a non-destructive mutation, so the bar is lower; the description adds real context beyond them by stating that creation has no side effect on threads, that names are unique per inbox ignoring case, and that an inbox caps at 100 labels. These constraints imply failure conditions the agent should anticipate, though error behavior itself is not spelled out.

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?

Four short sentences, front-loaded with purpose, then the non-effect caveat, then the follow-up tool, then constraints. Every sentence carries information the agent needs and none is redundant.

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

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

For a mutation with no output schema, the description usefully references 'the ID this returns' and covers uniqueness and volume limits. It stops short of describing duplicate-name or limit-exceeded failure behavior, but the stated constraints give the agent enough to call 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?

Schema coverage is 100%, so all three parameters are already documented, including the hex color format and the inboxId/email-address option. The description's note that Resend picks a color when omitted largely repeats the schema's own wording, so it adds little beyond the baseline.

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

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

States a specific verb and resource (create a label in a Resend inbox) and defines what a label is, distinguishing it from siblings like add-inbox-thread-labels, update-inbox-label, and list-inbox-labels. The agent can tell exactly what this tool produces without opening 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?

Explicitly clarifies that creating does not apply the label and routes the agent to add-inbox-thread-labels to do so, which is strong when-to-use guidance. It does not explicitly contrast with update-inbox-label or list-inbox-labels, but the create-vs-apply distinction is the key ambiguity and it is resolved.

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 only states the action without disclosing operational details like uniqueness, persistence, permissions, or return value. For a mutation tool, this is insufficient.

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

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

Two concise sentences, front-loaded with the action, 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?

Despite being simple, the description explains the concept and the action. It lacks return value details, but given the one-parameter scope, it's reasonably complete for a create 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 covers the only parameter fully. Description adds context about what a segment is but doesn't add specific parameter semantics beyond the schema.

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

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

Clearly states it creates a new segment in Resend, and defines a segment as a group of contacts for targeting broadcasts, distinguishing it from other 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?

Provides context about segments being used to target broadcasts, implying when to use this tool. It doesn't explicitly name alternatives or exclusions, but the context is clear.

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

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

With no annotations, the description carries the transparency burden. It discloses draft status, the recommended workflow, and the lossy nature of switching between compose and html/text modes. This goes beyond typical create-tool descriptions, though it does not mention return values or potential validation failures.

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?

Well-structured with a clear title, bold headers, and bullet points. Every sentence provides useful information: purpose, draft status, workflow, and content options. No filler or redundancy.

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

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

The description covers the full lifecycle, including next steps and caveats. It does not describe the response shape, but no output schema is provided. For a create tool with a complex domain, this is reasonably complete given the rich 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 fully documents all 8 parameters. The tool description adds the triple-brace variable convention (already present in the schema) and workflow context, but does not explain individual parameters beyond what the schema provides. This meets the baseline for high coverage.

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

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

The description opens with 'Create a new email template in Resend,' a specific verb+resource statement. It immediately adds that templates are created in draft status, distinguishing this from publish-template. This clearly scopes the tool's function.

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 an explicit workflow (create-template → get-tiptap-json-content → compose-template → publish-template) and contrasts compose-template (recommended) vs update-template with html/text, including when each is appropriate. It also tells the user to ask before switching modes, giving clear decision support.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the concept of topics but does not disclose what happens on creation, such as response format, duplicate handling, required permissions, or side effects. The immutability of 'defaultSubscription' is noted in the schema, not the description.

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 states the action and scope; the second provides useful domain context. There is no wasted information, and the key point 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 creation tool with full schema coverage, the description is largely complete: it states the action, scope, and explains the domain relevance of topics. The main gap is the lack of return value or post-creation behavior, but this is minor for such a straightforward 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 100%, so the schema already documents all parameters (name, description, defaultSubscription) with clear explanations. The description adds no additional parameter-level meaning, but the baseline of 3 applies because the schema carries the burden effectively.

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 ('create'), names the resource ('topic'), scopes it to 'Resend', and adds value by explaining the purpose of topics (managing subscription preferences). This clearly distinguishes it from sibling tools like 'update-topic' and 'remove-topic'.

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 (create a topic when you need a new subscription preference group) and provides domain context, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when-not-to-use scenarios. The guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It conveys the concept of the resource but omits mutation traits an agent needs: whether creation returns a signing secret (relevant given the rotate-webhook-signing-secret sibling), permission/auth requirements, idempotency, or limits on number of webhooks/endpoints.

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

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

Two tight sentences with the action front-loaded and no filler. The second sentence is explanatory rather than differentiating, but it does earn its place by grounding the term 'webhook' for an agent that may not know the product's event model.

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

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

For a simple two-parameter create tool with no output schema, the description covers the core purpose adequately. However, with zero annotation coverage it should say more about the write operation's side effects (e.g. secret issuance) and any preconditions, which leaves it only minimally complete.

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

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

Schema description coverage is 100%, so both 'endpoint' and 'events' are already documented in the schema, setting the baseline at 3. The description reinforces the semantics with example event names (email.sent, email.bounced, inbox.email.received), but adds no format or validation detail 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?

States a specific verb and resource ('Create a new webhook in Resend') and the second sentence defines what a webhook is in this product, including example event types. The verb cleanly separates it from the list-/get-/update-/remove-webhook siblings without needing to name them.

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

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

The description explains what a webhook does but never says when to create one versus using an alternative, nor does it note prerequisites (e.g. needing a verified domain before subscribing to domain/email events, or that a signing secret is issued). Usage is only implied by the concept explanation.

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 states the state change (removing presence) but does not disclose potential side effects like whether unsaved edits are preserved or if the session is fully terminated. For a simple tool, this is acceptable but not rich.

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

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

Two sentences, front-loaded with the primary action, followed by a clear call-to-action. Every word earns its place; 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?

Given the tool's simplicity (no params, no output schema), the description fully covers purpose and usage. It tells the agent exactly when to invoke it and what it does, making it complete for this low-complexity tool.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter info because none are needed; baseline 4 applies.

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

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

The description states a specific action: 'Remove agent presence from the Resend dashboard editor.' It clearly distinguishes from siblings like 'connect-to-editor' and 'update-email' by naming the exact resource and action.

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

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

The description provides explicit usage timing ('Call this when done editing'), giving clear context. It doesn't name alternatives or exclusions, but the instruction is unambiguous and sufficient for a simple disconnect operation.

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

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

There are no annotations, so the description carries the full burden. It discloses the core behavior: creates a copy with its own ID and preserves steps/connections. It doesn't explicitly state side effects like whether the original remains untouched, but that is strongly implied by 'creating a copy' and there is no destructive behavior implied. It could add more detail about response or failures, but for this simple operation it 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 three sentences without unnecessary detail. It front-loads the action, then explains the result and the appropriate usage context, followed by the follow-up action on the new ID. Every sentence earns its place.

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

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

For a single-parameter, no-output-schema tool, the description covers the main usage, creation behavior, and next-step with update-automation. A minor gap is that it never explicitly states what the response returns, though it implies the new ID is accessible since it says 'Use update-automation on the new ID.' Overall, it's sufficiently complete for correct invocation.

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

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

The schema provides 100% parameter documentation, including the type, required status, and a clear description with an example URL format. The tool description reinforces this by mentioning 'by ID or Resend dashboard URL' but does not add new semantics beyond what the schema already communicates. This matches the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb and resource: 'Duplicate an existing automation by ID or Resend dashboard URL.' It clarifies that the result is a copy with its own ID and includes the original's steps and connections, distinguishing itself from create-automation, which builds work from scratch. The purpose is unambiguous.

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

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

The description explicitly says when to use this tool: 'Use this when the user wants a new automation based on one they already have, instead of rebuilding from scratch.' It also points to a concrete alternative: 'Use update-automation on the new ID to rename it or change its workflow.' This gives clear direction for the agent.

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

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

With no annotations available, the description carries the full burden and does well by disclosing that the operation creates a draft, not a sent broadcast; that it copies a specific set of fields; that the name is truncated to 70 characters; and that even sent broadcasts can be duplicated. It does not describe the response payload or explicitly confirm the original is untouched, but the 'creates a new draft' language makes the primary behavior clear.

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 cleanly structured with bolded headers, front-loads the core purpose, and each section (purpose, non-goals, triggers) earns its place. It conveys substantial guidance in a compact format without filler or repetition.

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

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

For a single-parameter tool with no output schema, the description covers what the tool does, when to use it, what it copies, and how it names the result. The only minor gap is that it does not explicitly state the return value, though the reference to 'the new draft's ID' implies the response will provide it.

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

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

Schema description coverage is 100%, and the schema already documents that broadcastId accepts either a Broadcast ID or a Resend dashboard URL with an example. The description repeats the ID/URL flexibility but adds no new meaning beyond what the parameter schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Duplicate a broadcast by ID or Resend dashboard URL') and precisely defines the output: a new draft with the same fields and a truncated '(copy)' suffix. It also distinguishes itself from nearby siblings like update-broadcast and send-broadcast, making the tool's role unmistakable.

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

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

The 'NOT for' section explicitly names which sibling to use instead for editing or sending, and the 'When to use' section enumerates the user intents ('copy', 'clone', 'duplicate', 'reuse') that trigger this tool. This gives a clear decision rule to an agent.

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

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

No annotations are provided, so the description carries the burden. It discloses that the operation creates a new draft copy with a new ID, giving some behavioral insight. However, it does not mention permissions, side effects on the original template, or reversibility, which would be expected for a mutation tool without annotation safety hints.

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 verb and resource, and every sentence provides essential information. The description is concise with no redundant or filler 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 simple single-parameter tool with no output schema or annotations, the description adequately explains the action and accepted input. It lacks some detail like the resulting template content, but the phrase 'new draft copy' gives sufficient context for this scope.

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

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

Schema coverage is 100% with the parameter description fully explaining 'ID, alias, or Resend dashboard URL.' The tool description repeats this same information without adding meaningful new semantics, so it stays at 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 specifically states 'Duplicate an existing email template in Resend' with a clear verb and resource, and adds the outcome 'Creates a new draft copy of the template with a new ID.' This distinguishes it from sibling tools like update-template, publish-template, or create-template.

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 duplicating an existing template, but it does not explicitly mention when to use it instead of alternatives or any exclusions. It lacks direct comparison like 'use search_calls_extensive instead' which would justify a higher score.

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 flag destructiveHint=true and openWorldHint=true, but the description adds substantial non-structured context: the email is sent immediately, it cannot be recalled, recipients retain the original, a 50-recipient cap across to/cc/bcc, attachments from the original are carried along, and URL-sourced originals cannot be forwarded. These are real behavioral constraints an agent must know.

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

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

Bold-labeled sections (Purpose / NOT for / Returns / When to use) make it scannable and front-loaded. It is slightly long and the double-check requirement is restated twice ('you MUST double-check' then 'only use this tool if the user explicitly confirms after you double-check'), which is minor 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?

No output schema exists, but the description states the return value (the sent email's id) and covers the mutation's side effects, limits, and edge cases. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond per-field text by stating cross-parameter rules the schema does not express: 'to' is the only required body field, html/text are optional notes that never replace the original body, and the 50-recipient aggregate limit across to/cc/bcc.

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

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

States a specific verb and resource ('Forward one message from a Resend inbox thread') and immediately names the two siblings it is NOT (reply-to-inbox-thread-email, send-new-inbox-email), so an agent can route without opening another 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?

Explicit 'When to use' section, explicit 'NOT for' section with the correct alternative for each excluded case, plus a hard precondition (mandatory user double-check and confirmation) and where to obtain emailId (get-inbox-thread). This is close to a complete decision rule.

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=true, so the read-only nature is already covered. The description adds behavioral context by explaining the two modes (with id returns workflow, without id lists with filtering/pagination) and mentions pagination parameters. This goes beyond the annotation without contradicting it.

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

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

The description is well-structured with bold headings (Purpose, Modes, When to use), front-loads the purpose, and every sentence provides necessary information. It is concise with no filler or redundancy.

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

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

The tool has no output schema, and the description compensates by stating what is returned in each mode ('full automation details including the workflow definition'). It covers modes, parameters, and usage context well. It omits error handling or authentication details, but for a read-only tool with simple parameters, this is sufficient for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with detailed descriptions for all 5 parameters. The description adds the meaning of omitting vs providing 'id' (list vs detail mode), which is not explicitly stated in the schema but is critical for correct invocation. This semantic clarification exceeds the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get details of a specific automation (with its workflow) or list all automations.' It distinguishes two modes (with/without id) and explicitly mentions the dual functionality, differentiating it from sibling tools like get-automation-runs. The purpose is specific and action-oriented.

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 'When to use' section provides explicit scenarios: user asks to show automations, inspect a specific workflow, or before update-automation to see current workflow. This gives clear context and implies an alternative (update-automation) but does not explicitly mention when not to use this tool versus other list/get 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 readOnlyHint=true already annotation, the description adds valuable context by explaining the two modes and the detail level: step-by-step execution status, outputs, and errors. It also lists run and step statuses, which goes beyond the schema and annotations. However, it does not address rate limits or pagination defaults.

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 bold headers, bullet points, and distinct sections for purpose, modes, when to use, and statuses. It is efficient, front-loaded with purpose, and every sentence contributes necessary information without redundancy.

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

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

For a tool with two modes and no output schema, the description explains both modes and what is returned (run info, step-by-step status, outputs, errors), and lists statuses. It lacks explicit mention of default pagination behavior, but the schema covers cursor parameters, making it nearly 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%, with each parameter already well-described (e.g., status is 'for list mode only', runId says 'If omitted, lists all runs'). The description reinforces these mode distinctions but does not add substantive meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'List runs for an automation, or get details of a specific run.' It uses specific verbs and a distinct resource, and explicitly differentiates the two modes, making it easy to distinguish from sibling tools like get-automation.

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

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

The 'When to use' section provides concrete scenarios such as checking if an automation is working or debugging a failed run, and explicitly answers common user questions like 'why did this automation fail?'. However, it does not mention when not to use the tool or name alternative tools, so it lacks exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context: it can accept either a bare ID or a Resend dashboard URL, and it returns both HTML and plain text content. This exceeds the schema and annotations, providing meaningful transparency.

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

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

The description is a single, well-structured sentence that front-loads the key action and resource, followed by the input format and output content. Every clause earns its place with no redundancy or filler.

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

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

With a single required parameter, a read-only annotation, and no output schema, the description adequately covers what the tool does, how to specify the target, and what is returned (HTML and plain text). This is complete for the tool's complexity.

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

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

Schema description coverage is 100% for the single parameter broadcastId, which already explains it accepts an ID or Resend dashboard URL. The description repeats this, adding no new meaning beyond the schema. Baseline 3 is appropriate when schema covers all parameters.

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

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

Description uses specific verb 'Retrieve' and resource 'broadcast', and clarifies it's for a specific broadcast by ID or dashboard URL, including content types. This clearly distinguishes it from siblings like list-broadcasts (which lists) and create/update/remove-broadcast (mutations).

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

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

The description clearly implies usage when needing full details of one specific broadcast, but does not explicitly name alternatives or state when not to use. This is clear context without exclusions, so it earns a 4.

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

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

The description adds minimal behavioral context beyond the readOnlyHint annotation, noting that either an ID or email can be used. It does not disclose details like what happens if both are provided, error behavior, or return format, but with annotations already signaling a safe read operation, this is acceptable for a simple getter.

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, front-loaded with the action and resource, and contains no extraneous words. It is concise and appropriately structured for a simple get operation.

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

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

The tool is simple, and the description covers the essential purpose and context (from Resend). However, it does not specify that at least one of id or email is required, nor the precedence if both are supplied, which is a minor gap given the optional parameters in the schema.

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

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

The schema already provides full descriptions for both parameters (ID and email), and the description merely restates 'by ID or email' without adding new semantic detail. With 100% schema coverage, the baseline is 3, and no additional meaning is contributed.

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

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

The description clearly states the verb 'Get' and the resource 'a contact', specifying that lookup is by ID or email. This distinguishes it from sibling tools like list-contacts, create-contact, and update-contact, making the tool's purpose unmistakable.

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

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

The description implies the primary use case: retrieving a single contact when you have an ID or email. It does not explicitly mention alternatives or exclusions, but the scope is clear enough that an agent can infer when to use this tool over list-contacts or other contact operations.

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 only declare readOnlyHint: true, so the description adds value by revealing that contact imports are asynchronous and can be in queued, in_progress, completed, or failed states. This is useful behavioral context beyond the read-only safety hint, though it doesn't describe return format or error handling.

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

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

The description is two concise sentences, front-loading the core purpose and immediately providing workflow context. There is no wasted wording.

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

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

For a simple read tool with one parameter, a read-only annotation, and no output schema, the description covers the purpose, usage context, and expected statuses sufficiently. It provides complete guidance for an agent to invoke it correctly.

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

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

The schema fully describes the single 'id' parameter with the description 'Contact import ID' (100% coverage). The description does not add any further parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves the status and counts of a contact import by ID, using a specific verb and resource. It distinguishes itself from siblings like create-contact-import and list-contact-imports by focusing on a single import's 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 gives explicit guidance to use this tool after create-contact-import to track progress, naming the allowed statuses. It provides clear context but does not mention when not to use it or suggest alternatives like list-contact-imports for viewing all imports.

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=true, and the description's 'Get' is consistent. No additional behavioral traits (e.g., error handling, pagination, response shape) are disclosed, so the description adds minimal value beyond annotations.

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

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

A single, concise sentence that is front-loaded with the core action. Every word earns its place, with no redundancy (aside from the minor 'from Resend' modifier).

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

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

For a simple read-only tool with one parameter and clear annotations, the description is sufficient. It does not explain return values, but the nature of 'get' implies returning the property, and no output schema is expected for such a simple 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%, and the parameter contactPropertyId is already described. The description only says 'by ID,' which adds no extra 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 the action ('Get') and the resource ('a contact property by ID'), distinguishing it from list/create/update/remove contact property tools. It 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 implies usage: when you need a single contact property by its ID. It does not explicitly mention alternatives or exclusions, though the purpose is fairly obvious given sibling tool 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 readOnlyHint annotation already signals a read operation; the description adds value by specifying that the response includes DNS records needed for verification. It does not cover error behavior or authentication, but the annotation lightens the burden.

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

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

The description is a single, front-loaded sentence that conveys purpose and return content without redundancy.

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

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

For a simple get-by-ID tool, the description adequately covers what it returns (full domain details plus DNS records). Without an output schema, it still gives sufficient guidance, though it could mention possible response fields or not-found behavior.

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

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

The input schema fully documents the single 'id' parameter with a description. The tool description adds no further semantics beyond what the schema provides, aligning with the baseline.

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

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

The description clearly states the tool retrieves a domain by ID from Resend, with a specific verb ('Get') and resource. The mention of DNS records helps differentiate from domain-related siblings like list-domains or get-domain-claim.

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 a single domain's details are needed, as opposed to listing all domains. However, it does not explicitly name alternative tools or exclusion conditions, so it stops short of the highest score.

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 readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral details: it returns claim status and the TXT record, and it indicates the polling behavior. It does not contradict the annotation and provides context beyond what annotations alone 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?

The description is two sentences long and front-loaded, immediately stating what the tool retrieves and how. It includes the essential information (input, output, usage pattern) without any waste or redundancy.

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

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

For a simple read tool with one parameter and no output schema, the description explains the return value (claim status and TXT record) and the intended polling loop. It does not enumerate possible statuses or error conditions, but given the tool's simplicity and the readOnlyHint annotation, this level of 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?

The schema fully describes the single parameter 'id' as 'The placeholder Domain ID created by the claim'. The description adds the exact provenance ('the domain_id from create-domain-claim') and calls it a 'placeholder Domain ID', reinforcing the semantic meaning. With 100% schema coverage, this additional clarification earns a 4.

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

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

The description uses a specific verb ('Retrieve') and names the resource ('latest claim for a domain'), clearly distinguishing it from sibling tools like create-domain-claim and verify-domain-claim. It also specifies the input identifier ('placeholder Domain ID') and the output (status and TXT record), leaving no ambiguity about the tool's function.

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

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

The description provides clear usage context: it tells the agent to poll until status is 'completed' and identifies that the input comes from create-domain-claim. It does not explicitly mention when not to use this tool (e.g., versus verify-domain-claim), but the context is strong enough to infer its role in the claim verification flow.

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=true, and the description's 'Retrieve' aligns without contradiction. The description adds value by specifying the included fields (message_id, HTML, plain text) beyond the annotation, which is useful for setting agent expectations.

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

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

The description is a single sentence that front-loads the action and resource, then lists the return contents. Every word contributes value; there is no fluff or repetition.

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

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

For a simple single-parameter read tool with annotations, the description covers the core behavior and return contents. It does not detail error handling or authentication, but that is not critical given the annotations and low complexity.

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

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

Schema coverage is 100% and the 'id' parameter is described in the schema as 'The email ID to retrieve.' The description adds the context that the ID refers to a sent transactional email, but this is marginal given the schema already covers the parameter. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Retrieve') and clearly identifies the resource as a specific sent transactional email by ID. It enumerates the returned content (message_id, HTML, plain text), which distinguishes it from siblings like get-received-email or list-emails.

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

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

The description implies usage context: use this when you need full details of a specific sent transactional email by ID. It does not explicitly mention alternatives or exclusions, but the specificity is clear enough for an agent to select it over list-emails or get-received-email.

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 accurately reflects a read-only operation, aligning with the readOnlyHint annotation. It adds useful context by stating the response can be totals-only by default and can be broken down by dimensions. However, it doesn't disclose behaviors like defaults for date range (6 days before endDate), default granularity (daily), max 100 IDs, or the mutual exclusions between emailId/broadcastId and dimensions. Those are in the schema, so this is not a contradiction, but the description itself adds limited behavioral depth beyond the annotation.

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

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

The description is a single well-structured sentence that front-loads the core purpose (retrieve metrics), scopes it (account-level), lists the key metric types, and states the available breakdown dimensions. Every element earns its place without redundancy. It is appropriately sized for a read-only analytics tool with rich schema documentation.

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 complete for an agent's initial selection and invocation: it names the resource, the metric families, the date range, and the optional breakdowns. Combined with 100% schema coverage and the readOnlyHint annotation, the agent has enough to call the tool safely for most cases. A small gap is that the description doesn't mention the default behavior (totals only) or the incompatibilities between parameters, but those are documented in the schema, and there is no output schema or complex nested structure demanding more.

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 conceptual meaning by listing the breakdown dimensions (period, domain, email, broadcast) and metric categories, but it doesn't add value beyond what the schema already documents. It does not clarify the mutual exclusion constraints or the meaning of 'defaults to none, which returns totals only' in a way that improves on the parameter descriptions, so it earns the baseline without exceeding it.

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

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

The description clearly states the tool retrieves account-level email delivery and engagement metrics with a specific verb ('Retrieve') and resource ('account-level email delivery and engagement metrics'). It enumerates the metric types and the optional breakdown dimensions, which distinguishes it from sibling tools like get-email or list-emails. The scope (account-level) and the filtering/breakdown options make the tool's 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 conveys the main use case: retrieving aggregate email metrics for a date range, optionally broken down by period, domain, email, or broadcast. It does not explicitly name sibling alternatives or state when not to use this tool, but the context (read-oriented analytics vs. tools like send-email, list-emails, get-broadcast) makes the intended usage reasonably clear. Slight deduction for lacking explicit exclusion guidance such as 'for per-recipient data use list-broadcast-recipients.'

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 openWorldHint=false, so the safety profile is covered and the description is not required to restate it. The description adds genuine value by disclosing what a lookup returns (a live snapshot of unread threads, drafts, and last-received time). It does not cover error behavior for a missing inbox, but the gap is minor against the annotation coverage.

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

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

Three tight sentences: what it returns, how to supply the identifier, and how to use the result. The return-value enumeration is front-loaded and every clause carries information; nothing is padded or restated from the name.

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

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

With no output schema, the description compensates by listing the fields the caller can expect. Combined with the annotations covering the read-only safety profile and the schema covering the identifier, an agent has everything needed to select and invoke 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% for the single inboxId parameter, including the caveat that it is not the Resend receiving address, so the schema already carries the semantics. The description's 'pass the address directly' guidance adds workflow context but no new parameter detail beyond what is documented, making the baseline 3 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?

Names a specific verb and resource ('Get an inbox') and then enumerates the returned fields (domain, receiving address, timestamps, unread thread count, draft count, last received mail). This distinguishes it clearly from sibling list-inboxes and the many other inbox-* tools without needing to open any 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?

Gives explicit branching guidance: pass the email address directly when the user names the inbox by address, otherwise resolve the ID via list-inboxes. It also states downstream intent ('Use the returned ID with the other inbox tools'), which is exactly the when-to-use context an agent needs.

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 this a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description still adds real behavioral context: the never-configured case returns empty settings, and it enumerates the four valid tone presets, which is valuable given no output schema exists.

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

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

Three sentences, front-loaded with the core action, then the edge case, then the enum values. No filler; every sentence carries information an agent would otherwise lack.

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

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

There is no output schema, so the description correctly compensates by naming the returned fields and the tone preset values. It is nearly complete for a single-parameter getter; only a brief note on the shape of "actions" would round it out.

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

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

Schema description coverage is 100% and the single inboxId parameter is fully documented there (including the email-address alternative and the note that it is not the receiving address). The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ("Get the AI agent settings of a Resend inbox") and then enumerates exactly what those settings consist of: instructions, tone, and allowed actions. The get/update verb contrast with the sibling update-inbox-agent is unambiguous, so an agent can select it without opening the schema.

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

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

Usage is only implied: the tool reads agent configuration and the sibling update-inbox-agent mutates it, but the description never states that routing explicitly. It does surface one useful condition — an unconfigured inbox returns empty settings — but offers no exclusions or prerequisites beyond that.

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 openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that by enumerating what the body contains (recipients, subject, html, text, attached files, and reply thread/message) and disclosing it returns the body unlike the thread sibling. No auth or rate-limit notes, but for a read operation against a fully-covered safety profile this is substantial.

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

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

Three tight sentences with zero filler: the return scope is front-loaded, the sibling contrast follows, and the workflow pointer closes. Every sentence carries distinct 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?

No output schema exists, so the description must carry return-value meaning, and it does by enumerating the returned fields. With 2/2 params documented at 100% coverage and annotations covering safety, the only small gap is the absence of any error/not-found behavior for an invalid ID.

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

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

Schema coverage is 100% and both parameters are schema-documented, so the baseline is 3. The description only reinforces the draftId origin ('from list-inbox-drafts'), adding no new syntax or format meaning beyond the schema, and says nothing extra about inboxId.

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

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

States a specific verb and resource ('Get a draft by ID from a Resend inbox') plus the scope of what is returned. It explicitly distinguishes itself from the sibling get-inbox-thread ('lists a whole conversation without the bodies'), so an agent can route between them without opening schemas.

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?

Names the workflow position explicitly: 'Use this to read a draft back before send-inbox-draft puts it in the mail.' It also tells the agent where the required ID comes from ('Get the draft ID from list-inbox-drafts') and contrasts the read shape against list-inbox-threads/get-inbox-thread.

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, so the safety profile is covered; the description still adds real behavioral detail by disclosing that no html/text bodies are returned and by describing the oldest-first return shape. It stops short of stating permission requirements or rate limits, so a 4 rather than a 5.

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

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

Markdown headers (Purpose / NOT for / Returns / When to use) front-load the key facts, and the negated use case appears before the return detail. It is longer than strictly necessary in the Returns block, but nearly every sentence carries operational 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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly - thread fields, per-email fields, ordering, and pagination. Combined with the usage routing, an agent has everything needed to call 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?

Schema coverage is 100%, which sets the baseline at 3. The description goes beyond the schema by explaining the actual paging protocol ('pass the last email's ID back as after', 'pass the first email's ID back as before'), turning generic cursor parameters into an actionable procedure.

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

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

States a specific verb and resource ('Get one thread in a Resend inbox: the thread itself plus the metadata of its emails') and immediately distinguishes itself from the sibling get-inbox-thread-email by refusing to return message bodies. An agent can tell it apart from list-inbox-threads and get-inbox-thread-email without opening 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?

Explicit 'NOT for' clause names the alternative (get-inbox-thread-email) and the reason. 'When to use' gives two concrete triggers and tells the agent where the required IDs come from (list-inbox-threads / search-inbox-threads), plus the ID relationship to reply/forward 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 and destructiveHint=false, so the safety profile is covered. The description still adds genuine behavioral context beyond them: attachments are listed but never fetched, and attachment contents cannot be downloaded through this server. It does not discuss pagination or error behavior, but the listed constraints are the ones an agent would otherwise get wrong.

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?

Labeled sections (Purpose / NOT for / Returns / When to use) front-load the purpose and keep routing information scannable. It is somewhat long, and the Returns inventory partly restates field names that the schema already implies, but with no output schema that enumeration is not wasted.

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

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

No output schema exists, so the explicit Returns enumeration (id, direction, from/to/cc/bcc, reply_to, subject, message_id, read state, received_at, attachment lines, html/text) is necessary and supplied. Combined with the routing guidance and the attachment limitation, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining the cross-tool provenance of emailId (take the 'Email ID' printed by get-inbox-thread) and reinforcing that inboxId is not the Resend receiving address. Minor inconsistency: the schema says the value is the 'id' get-inbox-thread returns while the description calls it 'Email 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?

States a specific verb and resource ('Read one message in a Resend inbox thread, body included') and immediately enumerates what that includes (html/text bodies, addresses, Message-ID, attachments). The 'NOT for' section names the exact sibling tools that cover the adjacent cases, so the agent can disambiguate without opening 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?

Explicit when-to-use and when-not-to-use guidance: names get-inbox-thread, get-email, and get-received-email as alternatives with the condition that selects each. It also documents the handoff workflow ('get-inbox-thread points here for a body... pass it as emailId'), which is exactly the routing information an agent needs.

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 readOnlyHint annotation already indicates this is a safe read operation, and the description adds valuable behavioral context by enumerating exactly what the log details include (id, created_at, endpoint, method, etc.). It does not over-explain, and the return fields provide transparency beyond the annotation.

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

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

The description is well-structured with clear sections for Purpose, Returns, and When to use. It is compact, front-loads the essential purpose, and every sentence adds value without unnecessary 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?

For a single-parameter get tool, the description is complete: it states the purpose, lists the return fields, and gives usage scenarios. Despite no output schema, the return field list compensates, making the tool's behavior fully understandable.

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

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

The input schema fully describes the sole parameter logId as 'The Log ID to retrieve' with 100% coverage. The description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool gets detailed information about a specific API request log, including full request and response bodies. It uses a specific verb ('get'), identifies the resource ('API request log'), and distinguishes itself from list-logs by focusing on a single log's detailed contents.

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 'When to use' section with concrete user intents and phrasings, such as debugging a specific API call or inspecting a request. However, it does not explicitly name alternatives or state when not to use it, such as mentioning list-logs for listing logs, leaving a small gap.

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

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

Annotations already declare readOnlyHint=true, and the description adds value by specifying exactly what content is returned (HTML, plain text, headers, raw email download URL). This goes beyond the annotation but does not cover potential side effects or rate limits, which are less relevant for a read-only retrieval.

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

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

A single sentence that is direct and front-loaded, naming the action, resource, and key return components without any filler or repetition.

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

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

For a tool with one parameter and no output schema, the description sufficiently explains the return value (full details including content and headers). It is complete for the tool's complexity and works well with the readOnlyHint annotation.

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

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

Schema description coverage is 100% and the 'id' parameter is described as 'The received email ID to retrieve'. The description adds minimal extra meaning beyond restating that it retrieves by ID, so it stays at the 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?

The description uses the specific verb 'Retrieve' with the resource 'a specific received email by ID', clearly stating what is included (HTML, plain text, headers, raw email download URL). It distinguishes itself from sibling tools like list-received-emails, which lists emails, and get-received-email-attachment, which gets attachments.

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

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

The description clearly implies this tool is for retrieving full details of a single received email when you have its ID. It provides clear context but does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Beyond the readOnlyHint annotation, the description adds the behavioral detail that the download URL is time-limited, which is valuable context for agents. This goes beyond the basic safe-read indication and informs expectations about URL expiry.

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

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

The description is a single, well-structured sentence that front-loads the primary purpose and includes a key detail about the output. Every word adds value, with no redundancy or clutter.

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

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

For a two-parameter retrieval operation with readOnlyHint and no output schema, the description sufficiently covers what it does and the nature of the response (details + time-limited URL). It is complete enough for an agent to select and invoke correctly.

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

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

Schema description coverage is 100% for both parameters, and they are clearly named. The description adds minimal parameter-specific meaning beyond mapping emailId to 'received email' and id to 'attachment', so it does not significantly elevate the baseline.

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

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

The description uses a specific verb ('Retrieve details') and clearly identifies the resource ('a specific attachment from a received email'), including a notable output trait ('time-limited download URL'). This distinguishes it from siblings like get-sent-email-attachment.

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

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

The phrase 'from a received email' provides clear context for when to use this tool, implicitly differentiating it from sent-email attachment tools. No explicit exclusions or alternatives are named, but the usage context is unambiguous.

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

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

The readOnlyHint annotation already indicates this is a read-only operation. The description adds minimal context beyond the annotation: it specifies the source ('from Resend') and the lookup constraint ('by ID'), both of which are also reflected in the schema. No additional behavioral details such as return format or error scenarios are provided.

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

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

The description is a single, front-loaded sentence that conveys the essential purpose without unnecessary words. Every word earns its place, making it highly concise and readable.

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

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

Given the tool's simplicity (one required parameter, read-only, no output schema), the description is sufficient to understand its purpose and usage. It could optionally mention what the response contains, but this is largely implied for a get-by-ID operation, so only minor completeness gap exists.

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

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

Schema description coverage is 100%: the 'id' parameter is described as 'Segment ID'. The description does not add any further semantics beyond what the schema already provides, so it meets the baseline but does not exceed it.

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

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

The description 'Get a segment by ID from Resend' uses a specific verb ('get') and resource ('segment') and explicitly identifies the lookup key (ID). It clearly distinguishes from sibling tools like list-segments, which retrieves multiple segments, and create-segment, which creates a new one.

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

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

The description implies this tool is for retrieving a single segment when its ID is known, which is clear context for use. However, it does not explicitly state when to prefer this over alternatives like list-segments, nor does it mention any preconditions 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?

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds the time-limited download URL behavior, which is a meaningful behavioral trait not covered by annotations. This goes beyond the minimal bar.

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

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

The description is a single sentence, front-loaded with the action and object, and contains no redundant information. Every word earns its place.

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

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

For a simple 2-parameter read tool with full schema coverage and a readOnly annotation, the description covers the essential aspects: what it does, the scope (sent email), and the notable behavior (time-limited URL). It lacks explicit references to alternatives, but the tool is simple enough that this is not a critical gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides; it merely ties 'specific attachment' and 'sent email' to the id and emailId parameters.

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

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

The description uses a specific verb ('Retrieve') and resource ('attachment from a sent email'), clearly distinguishing it from sibling tools like list-sent-email-attachments (list vs. get specific) and get-received-email-attachment (sent vs. received).

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 sets clear context: this tool is for retrieving a specific attachment from a sent email, implying you already have an attachment ID and email ID. It doesn't explicitly name alternatives or exclusions, but the sent-email scope is clear from both name and description.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds value by disclosing that the result includes the suppression origin (bounce, complaint, or manual), giving the agent expectations about the response content.

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

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

The description is two sentences with no fluff. It front-loads the primary action and then adds the usage rationale, making it highly scannable and efficient.

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

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

For a simple getter with one documented parameter and a read-only annotation, the description fully covers purpose, usage, and expected return context (suppression status and origin). No output schema is present, but the description gives enough detail for an agent to understand the tool's role.

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% and the parameter is described as 'Suppression ID or email address.' The description reinforces the same semantics ('by ID or email address') but does not add additional formatting or constraint details 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 the action ('Get a suppression list entry'), the resource ('suppression list entry'), and the identifier types ('ID or email address'). It also explains the purpose ('check whether a specific address is suppressed and why'), which distinguishes it from list-suppressions or mutation 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 explicitly says 'Use this to check whether a specific address is suppressed and why,' providing a clear when-to-use scenario. It does not name alternative tools explicitly, but the sibling context (list-suppressions, remove-suppression) makes the differentiation 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=true. The description adds valuable behavioral context beyond that by specifying what the response includes ('HTML content, variables, and publish status'). This discloses the output shape even without an output schema, but it stops short of discussing error handling or other edge cases.

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

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

The description is two sentences, front-loaded with the core action, and wastes no words. The example URL is redundant with the schema but harmless. Every part earns its place.

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

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

For a simple getter with one parameter and read-only annotation, the description is complete. It explains the input format and explicitly names the return contents, compensating for the lack of an output schema. No critical information is missing.

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

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

The schema description for the single 'id' parameter already covers the allowed formats (ID, alias, or dashboard URL) and even the same example. The tool description essentially restates this, adding no extra semantic meaning beyond what the schema provides. With 100% schema coverage, this is baseline.

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

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

The description uses a specific verb ('Get') and resource ('email template'), and clearly states the input can be an ID, alias, or dashboard URL. This distinguishes it from list/update/delete operations among the sibling tools, making the tool's function 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 clear context for when to use this tool: to retrieve a single template's full details by ID/alias/URL. However, it does not explicitly mention when not to use it or point to alternatives like list-templates, so it falls short of a perfect 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?

The description goes beyond the readOnlyHint annotation by disclosing that the tool automatically connects the agent to the editor and that subsequent compose calls disconnect. This side-effect is significant and not observable from annotations alone.

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 clear headings, bullets, and a tip. Every sentence contributes to understanding the tool's purpose, usage, and side-effects, with no unnecessary repetition.

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

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

Given the tool has no output schema, the description adequately explains the return value and how to use it as a base for modifications. It also covers the editor connection side-effect and parameter defaults, making it complete for an agent to invoke correctly.

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

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

The input schema provides 100% coverage of all parameters, so the baseline is 3. The description adds minimal extra value, such as the tip about include_schema, but largely repeats parameter behavior already documented 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 the tool retrieves TipTap JSON content of a broadcast or template, optionally including the schema reference. It also differentiates from siblings by instructing 'Always call this before compose-broadcast or compose-template', making its specific role 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 'When to use' section provides explicit contexts: always before compose-broadcast/compose-template, for edits/modifications, and for inspection. It lacks explicit when-not-to-use or alternative tool names, but the guidance is clear and actionable.

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