Check a prepared or attempted email send to review its full preview and known SMTP outcome, without network access or retries.
Inspect a prepared or attempted send, including the full preview and known SMTP outcome. No network access or retry.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| operationId | Yes |
Changes observed during successful MCP inspections.
v0.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds real value beyond them: it discloses the returned content (preview + SMTP outcome) and explicitly states that no network call or retry occurs. It omits auth/permission requirements, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The resource being inspected is front-loaded, followed by the return contents and the safety constraint, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does partial duty by naming the return contents (preview, SMTP outcome). However, with two undocumented parameters at 0% coverage, an agent still lacks the identifiers needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both required parameters, so the description carries the full burden of clarifying them. It mentions neither accountId nor operationId explicitly; 'a prepared or attempted send' only loosely hints at what the operationId identifies.
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 ('Inspect') and resource ('a prepared or attempted send') and names exactly what is returned ('the full preview and known SMTP outcome'). It is clearly distinguishable from mail_send_prepared and mail_prepare, though it does not explicitly name the sibling it differs from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No network access or retry' implies this is the safe inspection step taken before or instead of mail_send_prepared, so usage is implied rather than stated. There is no explicit 'use this when...' or 'use X instead when...' guidance, leaving the agent to infer the workflow position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.