Wraps Email for Amazon SES

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with safety disclosure. It adds behavioral context beyond annotations: the tool requires no AWS credentials, produces an itemized bill, and depends on the account's SES pricing plan. These details help the agent understand what the estimate covers and what inputs matter.

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 the purpose front-loaded in the first sentence and practical guidance in the second. Every clause adds value—the list of AWS services is concrete, and the note about credentials prevents wasted calls. There is 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 with 7 parameters and no output schema, the description does a decent job by stating it returns the flat Wraps plan fee and an itemized AWS bill. However, it does not specify the output format, currency, or whether the estimate is provided as a detailed breakdown or a single number. Given the tool's complexity, a bit more detail about return value would improve completeness.

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

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

Schema description coverage is 100%, so the input schema fully documents each of the 7 parameters. The description mentions that the cost model has interacting variables and specifically calls out the SES pricing plan, but it does not add meaning beyond the schema's parameter descriptions. It earns the baseline 3 because 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?

The description opens with a specific verb and resource: 'Estimate the monthly cost of sending email with Wraps + AWS.' It clearly distinguishes this from the sibling tools (send_email, get_email_event_log, etc.) by focusing on cost estimation rather than sending or logging. The scope is explicit, so an agent immediately knows what the tool does.

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

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

The description provides clear guidance: 'Use this instead of calculating by hand' and notes 'Requires no AWS credentials,' which sets expectations. It explains that the cost model has interacting variables, signaling when this tool is valuable. It does not explicitly list when not to use it or name alternative tools, but the purpose is distinct enough that no exclusion is necessary.

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 and idempotentHint, so the safe read-only nature is covered. The description adds value by specifying that the tool returns ALL SES event types, which signals the full delivery timeline rather than a summary or recent send metadata.

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

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

Two sentences with no fluff. The first sentence states the action and target; the second lists the return contents. The key scoping detail ('for a specific email by its messageId') is front-loaded.

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

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

For a single-parameter, read-only tool with full schema coverage and an output schema, the description is complete enough. It covers the core purpose and return contents. Minor omissions like ordering/pagination are not critical given the annotations and output schema handle the behavioral context.

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 messageId parameter is fully documented as an SES message id returned by send_email or list_recent_sends. The description just restates 'by messageId' without adding semantic detail, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get'), a clear resource ('full delivery event log for a specific email'), and a precise identifier ('messageId'). It also enumerates the returned event types (Send, Delivery, Bounce, Complaint, Open, Click), which makes its function unmistakable and differentiates it from siblings like list_recent_sends or send_email.

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

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

The description makes the use case clear: retrieving the complete event history for one email when a messageId is available. It does not explicitly name alternatives or state when not to use it, but the scope is concrete enough that an agent can correctly select it over the sibling list/reply/setup 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?

The description explicitly states 'Read-only — makes no changes to your AWS account,' reinforcing the readOnlyHint and idempotentHint annotations. It also adds that the tool returns both sandbox status and a recommended action, which is behavioral context beyond what the 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?

Two sentences, front-loaded with the purpose and immediately followed by the safety guarantee. Every sentence earns its place with no redundancy.

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

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

The tool is simple, takes no parameters, is read-only, and has an output schema. The description fully conveys what the agent should expect: sandbox status plus a recommended next action. 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?

This tool has zero parameters, so parameter semantics are trivially satisfied. The schema coverage is 100% and there is nothing additional the description needs to clarify about inputs.

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

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

The description uses a specific verb ('Check') with a clear resource ('this AWS SES account's sandbox status') and an additional purpose ('get a recommended next action for getting a first send out'). It is unmistakably distinct from the sibling tools, especially verify_domain_status and send_email.

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 'for getting a first send out' implies this tool is for initial sandbox setup and orientation, which provides clear usage context. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide an agent toward correct selection among the siblings.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it states the timestamp is the send time and is stable across calls, which is important for pagination/consistency expectations. It also discloses the returned fields (send status, subject, recipient, timestamp, messageId) and the limit cap behavior. This is meaningful added context, though it doesn't discuss rate limits or error 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 compact and front-loaded: the core purpose and ordering are in the first sentence, followed by the stable timestamp note, return fields, sibling pointer, and parameter clarification. Every sentence earns its place and there is no fluff or repetition of schema details.

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

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

For a read-only list tool with an output schema present, the description is quite complete. It covers what is returned, the ordering, the stability of the timestamp, and how to follow up for full delivery details. It doesn't mention pagination beyond the limit parameter, but the stable timestamp and limit cap give enough for an agent to call it correctly. The output schema likely covers return structure, so the description need not explain it further.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (limit and since) with descriptions. The description adds a bit of extra meaning by explaining the `since` parameter accepts a full ISO 8601 datetime string with an example, and by noting the default limit of 20 is in the schema. However, the schema already covers the semantics well, so the description's added value is marginal. 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 verb ('List'), a specific resource ('recently sent emails from your Wraps email history'), and a clear ordering ('newest first'). It also names the sibling tool get_email_event_log for follow-up delivery details, which helps distinguish it from related tools. The scope is precise and an agent can tell it apart from send_email and get_email_event_log 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?

The description gives clear context for when to use this tool: to list recent sends and to obtain messageId for full delivery details via get_email_event_log. It does not explicitly state when not to use it or name alternatives for filtering/searching, but the sibling context and the explicit pointer to get_email_event_log provide adequate usage guidance. A small gap is that it doesn't mention that send_email is for creating sends, but that is fairly obvious from the sibling names.

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

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

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, so the bar for added value is high. The description still adds meaningful behavior: SES silently drops mail to suppressed addresses, listing is paginated and states truncation explicitly, and `reason`/`limit` are ignored when `email` is set. This is context an agent needs beyond the annotations.

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

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

The description is front-loaded with the action, then gives usage guidance, then the pagination caveat, then the optional filter. Every sentence earns its place, and the important warning about reputation damage is placed where it is most likely to influence an agent's decision.

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 rich output schema, full parameter coverage, and strong annotations, the description provides everything an agent needs to select and invoke the tool correctly. It explains when to use the exact-lookup mode, how to interpret truncation, and why checking is important.

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's own parameter descriptions already carry the important semantics: `email` is an exact lookup, `reason` and `limit` are ignored when `email` is set, and `limit` has a default and max. The tool description reinforces the email-vs-listing distinction but does not need to add parameter-level detail, 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 opens with a specific verb and resource: 'List addresses on your AWS SES account-level suppression list' and immediately adds the alternate exact-lookup mode with `email`. This clearly distinguishes the two behaviors the tool supports and leaves no ambiguity about what it operates on.

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 operational guidance: check before sending to unfamiliar addresses, always pass `email` for single-address questions, and never treat a truncated listing as proof of unsuppressed status. The input schema reinforces this with 'Do NOT answer that question from the listing instead,' making the decision path 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 readOnly=false and destructiveHint=true; the description adds actionable behavioral constraints: the WRAPS_WRITE_ENABLED prerequisite and the verified SES identity/region requirement. This enriches the safety and operational picture without contradicting the annotations.

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

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

Three short sentences front-load the core action, then state requirements and recipient flexibility. Every sentence earns its place, no repetition or filler.

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

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

The tool has an output schema, so return values are covered elsewhere. The description covers the essential prerequisites (env var, verified identity) and the key constraining rule (to accepts array). It could mention body requirements but those are in the schema. Overall 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?

Schema description coverage is 100%, so each parameter is already documented. The description restates the to field's array capability and the from identity requirement, but adds no new meaning beyond the schema—meeting the baseline for high coverage without additional value.

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

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

The description opens with 'Send a transactional email via your AWS SES account,' naming a specific verb, resource, and channel type. It immediately distinguishes this from sibling tools, which are all inspection or setup operations (get_setup_status, list_recent_sends, etc.), so an agent can tell exactly what this tool does.

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

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

The description provides clear usage context: it is for sending transactional email, requires WRAPS_WRITE_ENABLED=true, and the from address must be verified. While it doesn't explicitly contrast with alternatives, none of the sibling tools are send operations, so the context is sufficient without 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds specific return semantics (verification and DKIM status), which is useful and not redundant. It doesn't mention rate limits or auth, but for a read-only status check this is acceptable.

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

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

The description is two sentences with zero filler. It front-loads the primary action and result, and every clause adds value. No redundant phrasing or restatement of the tool name.

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

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

For a simple read-only tool with one parameter, a detailed schema, and an output schema present, the description fully covers what an agent needs to know: what it does and what it returns. No critical operational details are 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 parameter 'domain' is comprehensive (includes format, example, and per-region note), and schema coverage is 100%. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a clear verb ('Check') and identifies the exact resource ('verification and DKIM status of a sending domain in your AWS SES account'). It also specifies what is returned (verification and DKIM configuration status), making it distinct from all sibling tools, none of which target domain verification.

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

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

The purpose is clear enough that an agent would know when to call it, but the description provides no explicit guidance on when to prefer this over get_setup_status, which could plausibly overlap. It neither states when not to use it nor names any alternatives, so the usage context is only implied.

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