inbox-preview

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the polling behavior and return content, but it does not mention potential errors, timeouts, or whether the operation is strictly read-only, leaving some behavioral aspects implicit.

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 concise and well-structured, with no redundant words. It front-loads the key action and outcome and adds the polling instruction in a clear second sentence.

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

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

For a simple single-parameter tool, the description provides enough context: it states what will be returned (status and screenshots) and how to use it (poll until completed). It does not detail output format, but that is not essential for basic invocation.

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

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

The only parameter, job_id, is described as the ID returned by submit_preview, which precisely tells the agent where to obtain the value. This fully covers the parameter's meaning and origin.

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

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

The description clearly states the tool gets status and screenshots for a preview job, making the primary purpose obvious. It does not explicitly contrast with sibling tools like get_screenshot, but the resource and action are specific enough to avoid confusion.

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

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

It provides direct usage guidance by instructing the agent to poll until status is 'completed', which is exactly when this tool is appropriate. It does not explicitly mention when to prefer alternatives, but the polling instruction gives clear context for use after submit_preview.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return value (image URL) but does not state whether the operation is read-only, any side effects, authentication requirements, rate limits, or error behavior. The lack of explicit safety information lowers the score.

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 short sentences with no filler or redundancy. It front-loads the primary action and return value, making it easy to parse quickly.

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

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

Given the full schema coverage and the simple nature of the tool, the description is sufficient. It states what the tool does and what it returns. There is no output schema, but the return type is implied as a URL, which is adequate for this 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% for all 5 parameters, so the baseline is 3. The description paraphrases the parameters ('width' for viewport_width, 'environment' for color_scheme/images_disabled) but adds little novel explanation beyond the schema's own descriptions.

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

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

States a clear verb ('Fetch') and resource ('rendered screenshot'), and mentions it returns the image URL. Sibling tools like get_job, list_clients, and submit_preview are distinct enough that the purpose is unambiguous, though it does not explicitly contrast with them.

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

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

Provides no guidance on when to use this tool instead of siblings. It does not mention any triggering conditions, prerequisites, or alternative scenarios, leaving the agent to infer usage from the parameter list alone.

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

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

No annotations are provided, so the description must convey behavior. It states the tool lists clients that 'this deployment can render right now', implying current state read-only access, but does not explicitly mention idempotency, data freshness, or side effects.

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

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

The description is a single, well-structured sentence that conveys the essential information without any redundant or irrelevant 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?

The tool is simple with no parameters and no output schema, but the description adequately explains what is returned (list of clients with rendering tier, engine, and capabilities). It meets the needs for this tool's complexity.

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

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

The tool has no parameters, so schema coverage is 100%. The description adds no parameter information because none exists, but the baseline for zero-parameter tools is 4.

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

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

The description clearly states the tool lists email clients with rendering details (tier, engine, capabilities), distinguishing it from sibling tools like get_job, get_screenshot, and submit_preview which focus on different operations.

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 is clear about the tool's function but does not explicitly state when to use it vs alternatives. However, the sibling list shows distinct tool purposes, so usage context is implied and sufficient.

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

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

With no annotations, the description carries the full burden. It discloses the asynchronous job pattern and the response type (job ID), which is the most relevant behavioral trait. However, it doesn't mention side effects of submission, job lifecycle, rate limits, or error conditions.

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 wasted words: the core action, input formats, constraint, and async response are all front-loaded. Every sentence earns its place.

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

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

For a 6-parameter tool with no output schema, this description gives the essential selection and invocation info (what it does, input constraint, job ID response). It doesn't detail the response schema, but that's delegated to the poll tools, so the gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3. The description only recaps the html/eml mutual exclusion already documented in the schema, adding no new parameter-level meaning.

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 direct verb+resource ('Submit an email for rendering across email clients') and specifies the two accepted input forms (HTML or base64 .eml) plus the exactly-one constraint. This clearly distinguishes it from siblings get_job/get_screenshot (which retrieve results) and list_clients (which enumerates client options).

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

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

The description sets clear context: this is the submission entry point, and 'Returns a job ID to poll for results' implies the subsequent get_job/get_screenshot steps. It also states the exactly-one-of-html/eml rule. There are no explicit when-not-to-use or alternative-tool statements, so it misses the top score.

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