SenderKit

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful constraint that only pending messages can be cancelled, but says nothing about idempotency, failure behavior when the message is already sent, or any auth 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?

A single front-loaded sentence with no filler; the verb and its precondition come first and the identifier requirement closes it out.

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

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

With an output schema present, return values need no explanation, and annotations carry the destructive/safety profile. The description covers the essential scoping, though it omits edge-case behavior such as what happens on an already-delivered message.

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 the id and context parameters are fully documented in the schema itself. The description only echoes 'by its public id' and adds no syntax or format detail beyond the schema's example ("msg_…").

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

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

The description states a specific verb (cancel) and resource (message) and narrows scope with 'still-pending (scheduled or queued) by its public id.' That qualifier distinguishes it from read-only siblings like senderkit_messages_get, but no sibling is named explicitly.

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 'still-pending (scheduled or queued)' serves as an implied precondition, telling the agent this only applies to messages not yet sent. There is no explicit when-to-use/when-not guidance and no comparison to alternatives such as senderkit_messages_get.

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

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

Annotations already declare readOnlyHint, destructiveHint false and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the mode is fixed for the whole connection, and test mode records without delivery. That is a non-obvious invariant an agent needs.

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 zero filler; the returned fields are front-loaded and the mode explanation follows. 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?

An output schema exists, so return values need not be detailed, yet the description still names the returned fields. Combined with the send-mode semantics, an agent has enough to call this correctly; only an explicit trigger condition for when to call it is absent.

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

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

The single 'context' parameter has 100% schema description coverage, including a word-count rule and a worked example, so the schema carries the semantics entirely. The description adds nothing about the parameter, which is the baseline case 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?

States a specific verb (returns) and resource (connected workspace plus send mode) with the exact fields returned (id, name, slug). No sibling tool retrieves context, so an agent can immediately distinguish this as the setup/discovery call.

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 description explains what live vs test mode means, hinting at why an agent would call it, but never says when to call it (e.g. before sending) or what alternatives exist. With read-only siblings like messages_list this is not misleading, just under-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 readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description adds genuine behavioral context beyond that: it enforces the workspace's plan limit and validates forwardTo/webhookEndpointId, which tells the agent this call can fail on quota or bad input. It stops short of describing what an exceeded-limit failure looks like.

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

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

Two sentences with zero filler, and the core action is front-loaded before the constraint/validation note. Every clause carries information an agent needs.

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

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

An output schema exists so return values need not be explained, and all 7 parameters are fully documented in the schema. The description is adequate for the call, though a mutation tool that consumes a plan-limit quota could say what happens on limit exhaustion or whether the address is usable immediately.

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

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

Schema description coverage is 100%, so every parameter (livemode semantics, catch-all '*', mail-loop constraint on forwardTo, endpoint binding) is already documented in the schema. The description adds essentially nothing new about parameters beyond flagging that forwardTo/webhookEndpointId are validated, 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 ('Create a new inbound email address') plus the two core behaviors of the created object (receives mail, optionally forwards/webhooks). An agent can tell it apart from the list/delete inbound_addresses siblings without opening 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?

The description implies when it applies (minting a receiving address for the workspace) and notes a prerequisite — the plan limit is enforced — but it never states when to prefer this over related tools such as senderkit_inbound_domains_create, nor any explicit when-not condition. Usage is inferable but not spelled out.

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

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

Annotations already declare destructiveHint=true, so the description's job is to add blast-radius detail, and it does: mail stops immediately while already-received messages are unaffected. It stops short of saying whether the deletion is permanent/reversible or what permissions are needed, so it is useful but not fully complete.

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

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

Two sentences, front-loaded with the action and target, then the immediate behavioral consequence. No filler, no restatement of the tool name, every clause carries 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 only two required params, full schema coverage, an output schema, and annotations covering the destructive profile, the description supplies what is missing: the blast radius of the delete. Only the irreversibility/permission dimension is left unaddressed, which is a minor gap for a 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?

Schema description coverage is 100%, with the id parameter fully documented as the inbound address publicId. The description only restates 'by id' and adds no format or constraint details beyond the schema, 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?

States a specific verb (delete) plus resource (one of the workspace's inbound email addresses) and scope (by id). This cleanly separates it from the sibling create/list tools for the same resource, so an agent can pick it without opening any 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?

Usage is implied rather than stated: the tool deletes an inbound address the workspace owns. There is no explicit when-to-use/when-not guidance and no mention of alternatives (e.g. keeping the address but routing mail elsewhere), which leaves the selection logic to inference among the inbound_addresses siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds useful domain context about what inbound addresses do, but says nothing about pagination, auth scope, or result size; with an output schema present, return format is reasonably omitted.

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

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

A single front-loaded sentence with the action verb first and zero filler; the definitional dash clause earns its place by clarifying the resource. Nothing to trim.

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 read-only list tool with annotations covering safety, a fully documented single parameter, and an output schema explaining the return shape, the description supplies the conceptual grounding an agent needs. Only the lack of explicit sibling differentiation keeps it short of a 5.

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

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

There is a single parameter (context) with 100% schema description coverage, so the schema already carries the semantics and the description adds nothing about parameters. Baseline 3 is correct when the schema does the work and the description stays silent.

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 ('List the workspace's programmatic inbound email addresses') and defines what those addresses are, so an agent understands the object being listed. It does not, however, explicitly distinguish itself from siblings like senderkit_inbound_domains_list or senderkit_inbound_messages_list, which a reader must infer from the resource name alone.

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

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

Usage is implied by the clear list semantics and the definitional clause about receiving/forwarding mail or firing webhooks, but there is no explicit when-to-use, when-not-to-use, or alternative (e.g. domains_list vs messages_list) named. Adequate but leaves routing 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?

Annotations declare destructiveHint=true and openWorldHint=true, and the description adds crucial context beyond them: the existing_mx failure with the current host(s), that acknowledging redirects ALL domain mail, and that nothing is received until records are live and verification completes. This level of consequence disclosure is exemplary.

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, front-loaded with the core action and immediately followed by return semantics and the failure/override path. Every clause earns its place with no filler.

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

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

With an output schema present (DNS records) and annotations covering the mutation/open-world profile, the description supplies the missing behavioral detail: failure mode, override consequence, and the prerequisite that verification must complete. Nothing an agent needs to invoke this correctly is absent.

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

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

Schema coverage is 100%, so the schema already documents all three parameters including the acknowledgeExistingMx behavior. The description reinforces the MX-redirect consequence but adds no syntactic or format detail beyond the schema; 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?

Specific verb+resource ('Claim a custom domain for receiving mail') with a concrete example ('inbound.acme.com'), and it is clearly distinguishable from domain siblings like list/delete. The purpose is unmistakable from the opening clause.

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?

Explains the operational condition for the acknowledgeExistingMx path and describes the existing_mx failure mode, effectively guiding when the flagged flag is needed. It does not explicitly reference alternatives or prerequisites like plan requirements, but context for the primary decision point is clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real consequence detail beyond that: addresses stop receiving mail immediately (immediacy/irreversibility of impact) and the shared domain is protected. It stops short of stating auth requirements or whether deletion is reversible/undoable.

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

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

Three short sentences, zero waste, with the action front-loaded and the two most decision-relevant facts (immediate mail cutoff, shared-domain protection) placed immediately after.

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

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

An output schema exists so return values need no explanation, and the destructive annotation plus the description's impact statement cover the mutation's risk profile. Minor gap: no mention of cascading effects on stored inbound messages or whether the action is reversible.

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

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

Schema description coverage is 100% and both parameters (id, context) are fully documented in the schema, including a detailed usage note for context. The description only restates 'by id', adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete a custom inbound domain by id') and scopes it to custom domains, which cleanly distinguishes it from siblings like inbound_domains_list, inbound_domains_create, and inbound_addresses_delete.

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 the operative condition for the tool — deleting a custom domain — and adds a clear exclusion: the shared {slug}.in.senderkit.email domain cannot be deleted. It does not explicitly route the agent between deleting a domain versus deleting individual addresses, but the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it discloses that the shared domain may appear and that DNS records are returned only for pending custom domains, which is conditional output behavior an agent cannot get from 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 sentence with zero filler; the resource and its scope are front-loaded before the parenthetical clarifications about shared and pending domains. Every clause 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?

With an output schema present, the description needn't document return values, yet it still summarizes what comes back (verification status, needed DNS records). For a no-argument read-only list tool this is essentially complete; only the absence of any routing to sibling list tools keeps it from a 5.

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

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

There is a single 'context' parameter whose schema description is fully covered (100%), so the schema does the heavy lifting. The description adds no information about parameters, which is acceptable given the baseline for fully documented, single-parameter schemas.

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

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

The description names a specific verb ('List') and resource ('the workspace's custom inbound domains'), and clarifies scope by noting the shared {slug}.in.senderkit.email domain is included when used. It is plainly distinguishable from the sibling create/delete domain tools, though it never names them explicitly.

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

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

Usage is implied rather than stated — an agent can infer this is the way to inspect domain verification status and outstanding DNS records. There is no explicit when-to-use/when-not guidance or reference to alternatives such as senderkit_inbound_addresses_list.

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

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

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the description is freed from the safety profile. It then adds genuinely non-obvious context: attachments are returned as authenticated v1 API links requiring a Bearer key with the inbound scope, and explicitly are not signed/presigned URLs. That access-model detail is a real behavioral trait an agent could not infer from annotations or 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?

A single sentence, front-loaded with purpose and then the returned fields, with no filler. It is dense with parentheticals, but every clause carries information rather than repeating the title.

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-param read tool with an output schema and read-only annotations, the definition is essentially complete; the agent knows what it gets back and how attachment links are authorized. It could be strengthened by noting the list-tool alternative for lookup-by-criteria, but nothing needed 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 description coverage is 100%, so the 'id' publicId format and the 'context' intent-tracking contract are fully documented in the schema. The description's 'by id' merely restates the schema's required identifier without adding syntax or constraints. 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 ('Fetch') and resource ('a single received inbound email message by id') and enumerates the returned payload. An agent can distinguish it from senderkit_inbound_messages_list (plural/list) and senderkit_messages_get on the 'inbound' qualifier without opening 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?

The 'by id' framing and 'single' contrast with the sibling list tool for the same resource, so usage is implied. However, no explicit when-to-use/when-not guidance or named alternative is provided, so an agent must infer the routing itself.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds traits the annotations do not: a guaranteed newest-first ordering and the existence of cursor-based paging over recent receipts, which tells the agent how to walk the result set.

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

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

Two sentences, no filler, with the resource and ordering front-loaded before the filtering and usage guidance. Every clause earns its place.

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

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

An output schema exists, so return values need no explanation, and all four parameters are fully described in the schema. With annotations covering safety, the description supplies the remaining context an agent needs 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 schema already documents limit, before, address, and context, giving a baseline of 3. The description restates the address filter and the receivedAt cursor but adds no format or syntax detail beyond the schema (and uses a slightly different label for the 'before' param).

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 (List), resource (received inbound email messages), scope (workspace's programmatic addresses), and ordering (newest first). This cleanly separates it from senderkit_messages_list (outbound) and senderkit_inbound_messages_get (single message) without opening 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?

Explicitly names two usage contexts: checking whether mail has arrived, and paging through recent receipts. Strong positive guidance, but no when-not-to-use condition or named alternative tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that the payload includes delivery status values (delivered/bounced/failed); it says nothing about behavior on a missing/invalid ID, auth requirements, or rate limits, and an output schema is present to cover returns.

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

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

A single front-loaded sentence with zero filler: the verb, resource, keying parameter, and the motivating outcome all appear before the em-dash clause. Nothing could be removed 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 two-parameter read-only lookup with 100% schema coverage, full annotations, and an output schema, the description supplies enough to call the tool correctly. The one minor gap is behavior on a non-existent or inaccessible message ID, which the agent cannot infer from any supplied field.

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' format ("msg_…") and the mandatory analytics 'context' wording are fully documented in the schema. The description adds no syntax, format, or constraint information beyond that, 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 gives a specific verb and resource ('Fetch full details and delivery status for a single message by ID'), and the singular 'single message' implicitly separates it from the sibling senderkit_messages_list. It stops short of explicitly naming that sibling or senderkit_inbound_messages_get, so differentiation requires the agent to infer from the name.

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 states a clear use case — check whether a specific email or SMS was delivered, bounced, or failed — which tells the agent when this tool applies. It offers no exclusions or named alternatives (e.g. 'use messages_list to discover IDs first'), so routing decisions against siblings remain partly inferred.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description confirms a pure listing/audit operation but adds nothing on pagination behavior, result ceilings beyond the schema's limit, or latency, which is the bar for going above baseline here.

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: the first front-loads what is listed and its channel scope, the second covers filtering and intended use cases. No filler, no repetition of the title.

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

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

With an output schema present, return values need not be explained, and the schema fully documents all 8 parameters including the required context field. What remains thin is disambiguation from the inbound-listing and single-get siblings, which the agent would ideally have to call this tool 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?

Schema description coverage is 100%, so every parameter is already documented in the input schema, including search semantics, status enum meaning, and the metadata filter. The description's mention of 'channel, template, delivery status, or metadata' only restates filter dimensions already in the schema, so baseline 3 applies.

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

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

States a specific verb (List) and resource (sent and scheduled messages) plus the channel scope (email, SMS, push, web-push). The 'sent and scheduled' framing implicitly separates it from the inbound siblings, but it never names senderkit_messages_get or senderkit_inbound_messages_list, so the differentiation is inferred rather than stated.

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 concrete reasons to call it — monitor deliverability, debug failed sends, audit transactional history — and enumerates the filter dimensions. It stops short of saying when NOT to use it or which sibling handles a single-message lookup, so the routing guidance is one-sided.

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 destructiveHint=true and openWorldHint=true but not what that means in practice; the description adds real value by explaining the test-vs-live delivery distinction, that the result's `mode` field reports which was used, and the draft-vs-published template rule. It stops short of covering irreversibility/rate limits or pointing at senderkit_cancel_message for undoing a live send.

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 tight sentences with no filler: purpose first, then mode binding, then mode reporting, then the draft/published constraint. Every sentence carries information an agent needs before invoking.

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

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

With an output schema present the description needn't explain return values, and it covers the non-obvious behavioral rules of a 15-param mutation tool. Minor gaps remain around cancellation, idempotency behavior and side-effect limits, though idempotencyKey and scheduling are at least documented in the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 15 parameters including channel, version, scheduledAt and attachments. The description adds no parameter-level syntax or format detail, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (send) plus resource (transactional email/SMS/push/web-push notification) and constrains it to 'using a saved template', which implicitly separates it from senderkit_send_raw. An agent can tell what this tool does and how it differs from raw sending 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?

Gives clear operating context: test mode records without delivering, live mode actually sends, and draft templates are only usable in test mode. It does not, however, name alternatives (e.g. senderkit_send_raw for untemplated content) or state exclusions, so routing is implicit rather than spelled out.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: test mode records without delivering, live mode really sends, and the 'mode' field in the result reports which was used. It does not cover failure modes or rate limits.

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

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

Three short sentences, front-loaded with the primary action and followed by the mode semantics. Every sentence carries information the agent needs; nothing is restated from the schema.

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 25-parameter, multi-channel send tool with an output schema (so return values need not be explained) and full annotation coverage, the description supplies the crucial test/live mode caveat. It stops short of noting channel-required-field constraints at a glance, but that lives in the schema.

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

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

Schema description coverage is 100% across all 25 parameters, so the schema already documents channel-specific fields (html required for email, E.164 for sms, etc.). The description adds no parameter-level syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (Send) plus the four supported channels and the scope qualifier 'inline content, without a registered template', which cleanly separates it from the template-based sibling senderkit_send. An agent can pick 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?

'without a registered template' implicitly routes template-based sends to senderkit_send, and the test-vs-live mode sentence tells the agent when delivery actually occurs. No explicit when-not statement or named alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false with destructiveHint=false, so the agent knows this is a non-destructive write. The description adds real value beyond that: it specifies the result is a DRAFT, that nothing is dispatched until review and publish, and that a review link is returned. That is exactly the mutation-side-effect disclosure the annotations cannot carry.

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

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

Three short sentences, each load-bearing: the action and its output state, the return value, and the safety guarantee. The most important fact (a draft is created, not a send) is front-loaded. Zero 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 an output schema present for the review link, 100% parameter coverage, and annotations covering the safety profile, the description only needs to close the remaining gap — which it does by pinning down the draft/publish lifecycle. 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 description coverage is 100%, so all five parameters including channel, brief, slug, description and the context-intent field are documented in the schema itself. The description restates the channel list ('email, SMS, push, or web-push') and the brief concept but adds no syntax, defaulting, or format guidance beyond what the schema already provides. Baseline 3 applies.

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

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

Specific verb-and-resource: 'Generate a new email, SMS, push, or web-push template from a plain-language brief', plus the resulting state ('save it as a DRAFT'). An agent immediately knows what this does and what it produces. It does not, however, explicitly contrast itself with the close sibling senderkit_templates_regenerate, so sibling differentiation is left implicit.

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 ('from a plain-language brief', 'Nothing is sent until the user reviews and publishes the draft') which signals when this tool is the right choice over senderkit_send. But it never states when to prefer this over senderkit_templates_regenerate, nor any prerequisite for the brief/context inputs. Usage is implied rather than instructed.

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 safety is covered. The description adds genuinely useful behavioral context beyond that: that rendered content is NOT returned (an important negative disclosure) and that declared variables are the ones to populate in `vars` on send.

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

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

A single front-loaded sentence with a parenthetical; no filler, no restating the title, and the most decision-relevant fact (lookup by slug, what you get) comes first.

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

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

An output schema exists, so return-value detail is optional, and the safety profile is covered by annotations. Naming the correct sibling for slug discovery (templates_list) would make it fully complete, but nothing needed to call the tool 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 description coverage is 100%, including a detailed spec for the `context` analytics parameter, so the schema carries the parameter burden and the baseline is 3. The description reinforces the slug lookup but adds no syntax or format detail for either parameter; the `vars` hint refers to a different tool's field rather than this tool's inputs.

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

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

States a specific verb and resource ('Look up a template by slug') and enumerates exactly what is returned: channel, status, version number, publish time, declared variables. This is clearly distinguishable from senderkit_templates_list (discovery) and senderkit_templates_create/regenerate (mutation) 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?

The parenthetical 'fill these in `vars` when sending' implies the downstream workflow, and 'by slug' implies the caller already has a slug. But there is no explicit when-to-use vs templates_list (find a slug) or templates_regenerate (change content), and no stated prerequisites, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by narrowing scope to workspace-wide enumeration and naming the channels returned, but discloses nothing about pagination, ordering, or volume limits for a list operation.

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

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

A single front-loaded sentence with no filler, immediately stating verb, resource, scope, and returned fields. Every clause earns its place.

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

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

With an output schema present, annotations covering the safety profile, and a fully documented parameter, the description only needs to identify scope and purpose, which it does. It could be stronger by noting pagination or the sibling get-tool distinction, but nothing essential is missing.

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

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

Only one parameter exists (the boilerplate 'context' analytics field), and schema description coverage is 100%, so the schema fully documents it. The description contributes no additional parameter meaning, which 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?

States a specific verb (List) and resource (message templates) scoped to the workspace, plus the channel coverage and returned fields (slugs, channels). It implicitly contrasts with templates_get/templates_create/templates_regenerate by emphasizing 'all', but never names an alternative, so it falls just short of explicit sibling differentiation.

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 word 'all' implies an enumeration/browse use case, but the description gives no explicit when-to-use condition, no prerequisites, and no mention of templates_get for single-template retrieval. Usage is only inferable from the phrasing.

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 destructiveHint=true and readOnlyHint=false, and the description adds the specific consequence an agent needs: draft content is replaced and manual editor edits are discarded. It also clarifies the blast radius (drafts only, published templates untouched), which is exactly the context annotations cannot express.

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

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

Three short sentences, front-loaded with the action and scoping, then the destructive consequence, then the lifecycle boundary. No filler or redundancy.

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

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

With an output schema present, return values need not be explained, and annotations plus the description together cover the destructive semantics and the draft-only constraint. Nothing needed 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 description coverage is 100%, so the schema already documents slug, brief, and the context parameter fully. The only added nuance ('new brief fully replaces the draft's content') restates the brief property description, so this sits at 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 gives a specific verb and resource ('Regenerate an existing DRAFT template from a new brief') and immediately scopes it by lifecycle state, which separates it from senderkit_templates_create and the read-only template siblings. An agent can tell what this does 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?

It clearly states the applicability condition ('Only drafts can be regenerated; published templates are left untouched'), which is real when-to-use guidance rather than implication. It stops short of naming alternative tools (e.g., create for new templates, get for published ones), so it is strong but not exhaustive.

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