Wraps Email for Amazon SES

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

Annotations already declare readOnlyHint and openWorldHint. The description adds value beyond them by disclosing that no AWS credentials are required—a meaningful behavioral trait—and by flagging that the estimate depends on interacting variables such as the SES pricing plan, which aligns with the open-world hint. It does not contradict 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?

Two sentences with no filler. The first sentence front-loads the action and components; the second explains why it should be used and the credentials constraint. 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?

For a tool with 8 parameters eliminates no output schema, the description is fairly complete: it conveys what the result represents (itemized monthly cost) and alerts the caller to input dependencies. The main minor gap is that it does not describe the exact return format or units, but the term 'cost' plus 'itemized AWS bill' gives a sufficient general picture.

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 of 3 applies. The description groups parameters into cost buckets (Wraps fee, tracked-event overage, AWS bill) and references the sesPlan dependency, but does not add per-parameter details beyond what the schema already documents.

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 enumerates what the estimate covers (platform fee, tracked-event overage, itemized AWS bill across named services), which precisely defines the tool's scope. It is clearly distinct from the sibling tools, all of which concern sending or inspecting emails, not cost projection.

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: 'Use this instead of calculating by hand' and explains why (the cost model has several interacting variables). It also states a key prerequisite/constraint, 'Requires no AWS credentials.' It does not name alternative tools, but no sibling overlaps with cost estimation, so this is clear enough context.

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

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

Annotations already 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 mark this as destructive and non-idempotent, so the mutation nature is disclosed. The description adds configuration prerequisites (WRAPS_WRITE_ENABLED, verified domain) but does not mention side effects like queuing, rate limits, or error responses. 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: first states purpose and key constraint, second covers address verification and array acceptance. Every word earns its place; no redundant phrasing.

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?

Prerequisites and address constraints are covered. An output schema exists, so return format is handled. Missing rate-limit or quota guidance is minor for a send operation. Overall adequate 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 covers all 5 parameters with descriptions (100% coverage). The tool description adds only the verification requirement for 'from' and clarifies the array option for 'to', which is already in the schema. Minimal added value beyond 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?

Description states a specific action ('Send a transactional email'), the resource ('your AWS SES account'), and key constraints (verified domain, array support). It clearly differentiates from siblings like list_recent_sends and get_email_event_log, which are read/verification tools. No ambiguity.

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

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

Provides explicit prerequisites: WRAPS_WRITE_ENABLED=true and a verified Wraps domain for the from address. While it doesn't name alternatives or state when not to use, the purpose is self-evident versus sibling tools, and the conditions are actionable 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?

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.