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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, and the description is consistent with them ('Nothing is sent' matches a non-destructive draft creation). Beyond that, it adds genuinely useful behavioral limits: recipients/Re: subject/threading are inherited from the original, the reply cannot be re-addressed, and it cannot carry attachments.

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, front-loaded with the action and outcome, then the constraints. No filler or restated schema noise; 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 5 parameters fully documented in the schema, annotations covering the safety profile, and no output schema to explain, the description is nearly complete for correct invocation. It omits minor operational detail such as which folder the new draft lands in, but nothing essential to calling 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 baseline is 3, but the description adds real meaning beyond the schema by explaining that recipient, subject, and threading parameters deliberately do not exist because they come from the original. The 'written above the quoted original' note also contextualizes the includeQuote toggle.

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+resource ('Save a reply to an email as a draft') and clarifies the outcome ('for the user to review and send'), so the agent knows exactly what is produced. It does not explicitly distinguish itself from the sibling update_draft (which edits an existing draft), leaving that inference to the agent.

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?

'Save a reply ... as a draft for the user to review and send' plus 'Nothing is sent' gives clear situational context for when this tool applies. However, it names no alternatives or exclusions (e.g., use update_draft to modify an existing draft), so routing between siblings still requires 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 already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond them: emails are not marked as read (an important side effect for a read-only listing) and each result carries an automated-mail heuristic, which an agent could not otherwise anticipate.

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, front-loaded with the operation and ordering, then the return shape and the read-status caveat. 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 no output schema, the description compensates by enumerating the returned fields (sender, subject, date, read status, automated flag) and the non-marking-as-read behavior. For a four-parameter read-only listing tool this is sufficient 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 coverage is 100% and every parameter (count, since, folder, unreadOnly) already carries a description with defaults, so the baseline is 3. The description adds no syntax or format detail beyond what the schema supplies, though it does echo the folder scoping.

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 recent emails in a folder') plus ordering (newest first) and the fields returned, so the agent knows exactly what it gets. It does not name or contrast with the sibling search_emails, so the boundary between listing and searching is left to inference.

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 'recent' plus the folder/count framing implies the intended browsing use case, but there is no explicit statement of when to prefer this over search_emails or read_email, and no exclusions. Usage is inferable but not guided.

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?

Adds real value beyond the readOnlyHint/openWorldHint annotations: it warns that sender-written content arrives wrapped in <untrusted-content> blocks and must be treated as data, not instructions, and it discloses the important side effect that emails are NOT marked as read. It also states the batch ceiling of 10.

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 limit, followed by the security warning and the read-state caveat. No filler or repetition of the 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?

With no output schema, the description still conveys the return shape ('as the text a person would see', wrapped in untrusted-content blocks) and the read-state behavior, leaving nothing critical unstated for a read-only email fetch.

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 parameters are already documented (UIDs sources, folder default INBOX). The description adds only the batch-size constraint ('up to 10'), which is a minor supplement rather than new per-parameter semantics.

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?

Names a specific verb (read) and resource (emails) plus a hard scope limit ('up to 10 emails by UID'). It implicitly separates itself from the list/search siblings by operating on known UIDs, though it never names those alternatives 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 schema notes UIDs come from list_emails or search_emails, so the workflow (list/search first, then read) is inferable, but the description itself gives no explicit when-to-use or when-not-to-use guidance relative to the sibling 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?

Annotations only declare readOnlyHint and openWorldHint, but the description adds real behavioral context: whole-word matching by default, dates interpreted as local calendar days keyed to the sent date, results ordered newest first, and the side-effect guarantee that emails are not marked read. It omits anything about result-set size/pagination or the shape of a match, which keeps it short of 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?

Four short sentences, front-loaded with the searchable fields and continuing into match semantics, date semantics, ordering, and side effects. Every sentence adds information and none is padding.

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 an 8-parameter, output-schema-less search tool with read-only annotations, the description covers matching rules, date interpretation, ordering, and the crucial non-mutation guarantee. It leaves result payload/pagination and the meaning of count's interaction with matches unstated, so it is strong but not fully closed.

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, but the description adds semantics the schema does not: that dates are local calendar days anchored on the send date, and the consequences of whole-word matching ('bill' does not match 'billion'). Those clarifications materially change how since/before/query/wholeWord should be set.

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 plus the searchable fields ('Search emails by text (subject, sender, and body), sender, and date range'), which is far more than a tautology. It does not, however, name or distinguish itself from the sibling list_emails, so the agent must infer the split.

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 filter vocabulary (use this when you want to match text/sender/dates), but there is no explicit when-to-use, no when-not-to-use, and no mention of list_emails as the unfiltered alternative. The agent is left to infer routing from the filter set 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?

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds material behavior beyond them: recipients and subject are preserved, the quoted original is retained unless keepQuote is false, the draft receives a NEW UID, and nothing is sent. The UID-change behavior in particular is non-obvious and operationally important.

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 short sentences, front-loaded with the core action, followed by invariants, the UID consequence, the eligibility constraint, and the safety note. No sentence is redundant padding.

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 mutation tool with no output schema, the description covers what is replaced, what is preserved, the side effect on the UID, the eligibility restriction, and the fact that nothing is sent. An agent has everything needed to invoke 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 100% and already documents uid, body, and keepQuote (including its default). The description largely restates these ('quoted original is kept below the new text unless keepQuote is false', 'new reply text'), adding little 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 ('Replace the reply text of a draft') and scopes it to drafts 'created by this server', which cleanly distinguishes it from create_reply_draft and the read-only siblings. An agent can identify the operation 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 preconditions: only drafts created by mail-brief-mcp can be changed, and the caller must use the newly returned UID. It does not explicitly contrast with create_reply_draft or state when to prefer updating over recreating, so it falls short of full alternative routing.

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