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

With no annotations, the description carries the full burden and does disclose key traits: this is an irreversible-ish mutation (draft creation or actual send), it is gated on explicit user approval, and the draft becomes 'visible'. It omits whether send can be blocked by send policy or what it returns, so it is strong but not exhaustive.

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 short sentences, front-loaded with the action and followed by the precondition. Every clause earns its place with no 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?

No output schema or annotations exist, so the description must stand alone; it covers the action, the gate, and the two delivery outcomes adequately. It stops short of describing the return payload or failure modes, which an agent calling a send path would benefit from.

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 67% and the enum on 'delivery' is documented in the schema itself. The description only restates that the item and delivery mode must match the approved one, adding no syntax or format detail beyond the schema. 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?

States a specific verb and resource ('turn one pending approval-queue item into a visible draft or send it') and constrains the unit of work to exactly one item. It clearly differentiates from siblings like queue_email_for_approval and discard_queued_email by describing the approval-outcome action.

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 an explicit precondition: only call after the user explicitly approved this exact item and delivery mode. It does not name an alternative sibling for the not-yet-approved or rejection case, but the when-to-use gate is 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the side effect profile — the draft is created and is visible/unsent, so nothing is transmitted — but says nothing about permissions, whether the draft is saved to a specific mailbox, or what happens if 'from' is omitted.

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, no filler, and the core action is front-loaded ahead of the usage rule. 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?

For a mutation tool with no annotations, no output schema, and half the parameters undocumented, the description is adequate but leaves real gaps: no return value or draft identifier, no error behavior, and no routing to the reply/approval siblings. The safety-relevant 'unsent/visible' framing is the strongest part.

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 50% (to and from are documented; text and subject are not), and the description contributes no parameter information at all. It neither explains the optional 'from' fallback nor the subject length constraint, so it fails to compensate for the coverage gap.

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+resource ('Create a visible unsent draft in Apple Mail') and adds the key qualifier 'unsent' plus the visibility trait, which separates it from a silent compose. It does not, however, distinguish itself from the sibling create_reply_draft, which covers the same operation for replies.

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 a clear conditional context: 'Use this before sending whenever the user should review the message.' That is a real when-to-use rule rather than a restatement. It stops short of naming alternatives (create_reply_draft for replies, queue_email_for_approval for approval flows), so there are no 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?

With no annotations, the description carries the full burden. It does disclose two behaviors: the draft is visible (opened in Mail) and nothing is sent, which is the key non-destructive signal versus send_email. It omits permission requirements, what happens if a draft already exists, and what the call returns.

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, zero waste, with the operation, the addressing rule, and the non-send guarantee front-loaded in that order. 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 draft-creation tool with no annotations and no output schema, the description covers the essentials (what it makes, what it doesn't send) but says nothing about the result — draft id, where it lands, or failure modes. Adequate but leaves real gaps for an agent verifying success.

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 all four parameters including the INBOX default are already documented in the schema. The description adds one useful semantic note — that the original message determines recipient and subject (i.e., message_id drives addressing) — but no format or syntax detail beyond that. 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?

States a specific verb and resource: open a reply draft for an existing message. 'Reply' implicitly separates it from the sibling create_draft (a fresh draft), but it never names that sibling, so an agent must infer the distinction. Clear purpose without explicit sibling differentiation.

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 phrases 'for an existing message' and 'This does not send anything' imply the usage context (replying to an existing thread without sending), but no alternative tool is named and no when-not-to-use condition is given. Usage is implied rather than stated.

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 and does disclose two meaningful traits: the side-effect boundary ('will not affect Apple Mail', distinguishing it from the Apple Mail-mutating siblings) and the authorization requirement. It does not state whether the discard is permanent or whether the original draft/thread is preserved, which is the main remaining gap for a destructive operation.

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, followed by the scope boundary and the precondition. Every sentence earns its place and nothing is padded.

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?

No output schema and no annotations, so the description must stand alone; it covers action, blast radius, and the approval gate. Remaining gaps are the irreversibility of the discard and the failure mode for a non-pending or missing item_id.

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%, so the description must compensate for both parameters. 'One pending approval-queue item' implies item_id's target and 'explicit user approval' maps to the user_approved flag, but neither is named or given format expectations (e.g., the UUID requirement); the const:true constraint is only visible in the schema. Partial compensation, not full.

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 (discard) and a precisely scoped resource (one pending approval-queue item), which cleanly separates it from approve_queued_email, list_approval_queue, and queue_email_for_approval. An agent can identify the target object and action 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?

Provides an explicit precondition ('Only call after explicit user approval') that gates invocation, and the pairing with the sibling approve_queued_email is implicit in the choice of the verb 'discard'. It stops short of naming the alternative tool or describing the state the item must be in (e.g., still pending).

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 one genuinely useful behavioral trait - email bodies are never stored, so the agent should not expect message content - and 'Read' implies a non-mutating operation. It omits auth/permission requirements, retention window, and ordering of entries.

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 no filler; the purpose is front-loaded and the privacy caveat is a deliberate second line. 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?

With no output schema and no annotations, the description should carry more about the shape of returned entries (fields, ordering, timestamp format). It gives the high-level subject and a key exclusion but leaves the return contract underspecified.

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% with a single optional 'limit' parameter whose bounds and meaning are fully documented in the schema. The description adds nothing beyond the schema ('recent' merely echoes the default ordering), 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 (Read), resource (audit metadata), and scope (recent, local, write actions). This clearly separates it from the email-centric siblings like list_messages and get_message. It does not, however, clarify what 'audit metadata' actually contains beyond the exclusion note.

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 implies the usage context (reviewing a trail of write actions) but never states when to reach for this tool versus any alternative, and gives no prerequisites. Adequate but leaves routing to 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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: read-only operation and that message bodies are excluded. However, it says nothing about whether it makes network calls, latency/cost of building the brief, permissions required, or what the brief actually contains.

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, front-loading the what and appending the safety/scope 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 4-parameter, no-annotation, no-output-schema tool, the description is thin: it omits parameter meaning entirely and never says what the brief contains (sections, fields) or how the limit bounds output. The read-only/body-exclusion note is the only substantive addition.

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% across 4 parameters, so the description must compensate and it does not. It never explains that 'email' identifies the contact, what 'account' scopes, how 'limit' bounds recent summaries, or what 'mailbox' selects.

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 ('Build') and resource ('contact brief'), plus the sources it composes: saved relationship context and recent inbox summaries. This distinguishes it in spirit from get_contact_context (raw stored context) and get_daily_briefing, but it never names a sibling 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 phrase 'from saved relationship context and recent inbox summaries' hints at aggregation, but there is no statement of when to call this versus get_contact_context or get_daily_briefing, and no prerequisites or exclusions. The agent must infer the routing.

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 behavioral burden. It discloses only that the operation is read-only, with nothing about what 'local relationship context' contains, what happens when the email matches no contact, or any auth/data-source (local vs server) implications.

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 terse sentences, front-loaded with the action and resource. Nothing superfluous; ideal size for a simple single-parameter lookup.

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 low-complexity read with one param and no output schema, the description is minimally viable, but it never says what the returned relationship context actually is, which leaves the agent guessing about the tool's value relative to get_contact_brief.

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 a single required 'email' parameter. The description indicates the key is one email address identifying the contact, which adds a little meaning, but it gives no format or matching semantics beyond that.

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 ('Read the local relationship context') scoped to 'one email address', so the operation is clear. However, it does not distinguish itself from the sibling get_contact_brief, nor from save_contact_context, which is the natural write counterpart.

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 guidance on when to use this versus get_contact_brief or the other contact-related siblings; no prerequisites or context for invoking it. 'Read-only' describes a trait, not a use condition, so the agent gets no routing help.

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 behavioral burden, and it does proactively disclose the read-only, non-mutating nature clearly. However, it omits other traits an agent needs: required permissions, whether results are cached/generated fresh, and any rate or scope behavior on the account.

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 core action and scoped by the read-only guarantee. No filler, though the second sentence largely restates the first's 'read-only' framing.

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 4-parameter generator with no output schema and no annotations, the description gives source scope and a safety guarantee but never says what the briefing actually returns or how the limit/day parameters shape it. Adequate but with concrete gaps.

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 only 25% (just 'account'), so the description must compensate, but it does not. It loosely gestures at the inbox and follow-up sources but never clarifies mailbox, unread_limit (default 10, max 50), or follow_up_days (default 7, max 30), leaving three of four parameters unexplained.

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 ('Create a read-only daily briefing') and enumerates its three data sources (one inbox, local approval queue, saved follow-up dates). It is distinguishable as a composite/aggregate tool, though it never explicitly names which sibling tools it overlaps with (list_approval_queue, list_follow_up_radar).

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?

There is no guidance on when to use this versus the sibling listers it aggregates (list_approval_queue, list_follow_up_radar, list_messages). The only constraint given is a negative one ('never drafts, sends, or changes email'), with no when-to-use or alternatives stated.

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 exist, so the description carries the full disclosure burden. It correctly declares 'Read-only', which is genuine safety context, but never mentions that the body can be silently truncated by max_body_characters (default 12000, cap 50000), nor authentication/permission requirements. Useful but incomplete for a no-annotation tool.

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, zero filler, with the core action front-loaded and the sequencing hint and read-only flag following. Nothing could be cut without losing 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?

For a 4-parameter read tool with no output schema and full schema coverage, the definition is nearly sufficient. The one meaningful omission is truncation behavior (what happens when the body exceeds max_body_characters), which an agent would want to know before rendering results.

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 all four parameters including account, mailbox default, message_id provenance, and max_body_characters are already documented in the schema. The description adds no semantics beyond it, 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+resource+scope: 'Read one message body by its id.' The word 'one' cleanly contrasts with the sibling list_messages/search_messages, which return many. It names those siblings, though only as a prerequisite rather than as explicit alternatives.

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?

'Use after list_messages or search_messages' gives a clear ordering/prerequisite that tells the agent when this tool is the right next step. It stops short of stating when not to use it, e.g. for metadata-only or bulk needs, but the context is 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?

With no annotations provided, the description carries the full burden, and it does declare the key behavioral traits: it is read-only, and credentials are deliberately withheld from the response. It still omits what the safeguards payload actually contains and any failure/auth behavior.

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 brief sentences with zero filler; the identity of what is returned is front-loaded and the safety qualifier follows instantly. 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 no-argument, read-only inspection tool with no output schema, the description adequately covers what it does and its safety profile. A sentence sketching the shape of the returned safeguards would make it fully self-sufficient, but the gap is small.

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 takes zero parameters and the schema is fully self-describing, so there is nothing for the description to compensate for. Baseline 4 applies; no parameter information is needed or missing.

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 ('Show') and a specific resource ('active local sending safeguards'), which is clearly distinct from sibling mutators like send_email, queue_email_for_approval, or preview_send. It does not, however, explicitly contrast itself with any sibling or clarify how it differs from a preview/gating check.

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 'active local sending safeguards' implies the agent consults this before or around sending decisions, but no when-to-use condition, prerequisite, or alternative (e.g., preview_send vs. queue_email_for_approval) is stated. Usage is inferable only from 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?

With no annotations, the description must carry the behavioral burden. It does disclose that the operation is read-only, which is a genuine safety trait, but says nothing about whether it reads local state only, what the mode values mean, or what the 'allowed MCP actions' list implies for behavior.

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 short sentences with zero filler, and the key subject (the active work mode) plus the safety tag are both front-loaded. Nothing is padded.

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 zero-parameter read tool with no output schema, the description effectively enumerates what comes back (the active mode and its allowed MCP actions) plus its safety profile. Only the enumeration of possible mode values is missing, which is a minor gap.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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 ('Show') and a precise resource ('active local AI-mail work mode and its allowed MCP actions'), which is clearly distinct from the sibling set_work_mode. It stops short of naming that counterpart explicitly, so the differentiation is implied by the get/set pairing rather than spelled out.

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 'Read-only' tag implies this is the safe inspection call you use before set_work_mode, but the description never states when to use it, what prompts it, or names the alternative. 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?

No annotations are provided, so the description carries the burden, but for a zero-parameter enumeration tool the surface is small. It does usefully declare 'Read-only', which reassures the agent this is a safe non-mutating call, but adds nothing about return volume, ordering, or failure modes.

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 short sentences, front-loaded with the verb and resource, and the read-only attribute appended economically. 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 trivial enum-style listing with no parameters and no output schema, the description effectively conveys what is returned (accounts plus configured sender addresses). Only the absence of any output schema leaves minor ambiguity about the exact field shape, which is not required for correct 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 tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a 0-param tool applies. Nothing in the schema needs compensating for.

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 ('List') and a specific resource ('Apple Mail accounts and their configured sender addresses'), which is distinct from the sibling list_mailboxes and list_messages. It does not explicitly name which sibling to prefer, but the resource itself is unambiguous.

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 guidance on when this tool is appropriate versus alternatives such as list_mailboxes; the agent must infer that accounts are the prerequisite to mailbox/message operations. No prerequisites or exclusions are stated.

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 provided, the description carries the full behavioral burden. It does disclose the key safety trait ('Read-only'), which is valuable, but says nothing about pagination, ordering, what happens with the default status filter, or the shape of the returned items.

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 short sentences, zero filler, with the core purpose front-loaded before the read-only note. Nothing redundant.

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 two-parameter, non-destructive list tool this is minimally adequate, but with no annotations and no output schema the description leaves return format, ordering, and status-filter semantics unstated. It is enough to call correctly but not fully informative.

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% and the description mentions neither 'limit' nor 'status'. The enum values and defaults exist in the schema, but the description does not explain the semantics of filtering by status (e.g., whether 'all' returns everything) nor any limit behavior, so it fails to compensate for the coverage gap.

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 (List) and resource (proposed emails in the local approval inbox), which is distinct from list_messages/list_mailboxes. It does not, however, explicitly tie itself to the sibling tools queue_email_for_approval, approve_queued_email, or discard_queued_email that operate on the same queue.

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?

There is no guidance on when to use this versus alternatives such as list_messages or search_messages, nor any mention that approve_queued_email/discard_queued_email are the follow-up actions. The agent must infer usage entirely from the name.

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 does disclose two important traits — read-only and never sends anything — but does not cover permissions, pagination, ordering, or what a returned record contains.

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 short sentences, front-loaded with the core purpose and followed by a critical safety clarification. Every sentence earns its place with no 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?

For a simple read-only list tool with one optional parameter and no output schema, the description covers scope and safety adequately. But with no annotations and no output schema, it could say more about what a returned contact record includes, ordering, or pagination behavior.

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 the single parameter 'within_days'. The description says 'within a chosen horizon', which vaguely implies the filter but gives no units, default, bounds, or explicit mapping to the 'within_days' parameter. It adds less precision than the schema's own default/min/max constraints.

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') and resource ('local contact records with a follow-up date'), and clearly scopes it to items due now or within a chosen horizon. It is distinct from all siblings, which are contact-context or mailbox/email tools, not follow-up radars.

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 implies when to use the tool by describing the target set: contacts with follow-up dates due now or in a chosen horizon. However, it gives no explicit alternatives, no when-not conditions, and no prerequisites or 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?

No annotations are provided, so the description carries the full disclosure burden. It contributes one useful fact - 'Read-only' - and the word 'top-level' implies non-recursive listing, but it says nothing about return format, ordering, or whether the list can be empty.

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 short sentences, front-loaded with the scope constraint and the read-only trait. Nothing is padded or redundant.

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 read tool with no output schema and a fully documented parameter, the description covers purpose and safety adequately. It could add a bit more on what a 'top-level mailbox' means or when to call it, but nothing essential 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 coverage is 100% and the single account parameter is already well documented (including its source, list_accounts). The description's 'in one Apple Mail account' only restates what the schema provides, 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 (list), resource (mailboxes), and scope qualifier (top-level, in one Apple Mail account). The resource name distinguishes it from message-oriented siblings, but it does not explicitly contrast with any sibling the way a top-tier definition would.

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 'in one Apple Mail account' implies the account must be known (and the schema points at list_accounts), but there is no explicit when-to-use statement or mention of alternatives. Usage is inferable rather than stated.

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 usefully declares read-only semantics and that bodies are excluded, which sets return expectations, but says nothing about ordering, pagination behavior with the limit cap, permissions, or error conditions for invalid account/mailbox.

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 short, front-loaded sentences with no filler; the core action leads and the scope caveat follows. Efficient, though the second sentence is brief enough that more could have been said without bloat.

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 must set return expectations, and it does partially ('summaries', 'bodies not included'). However, for a 4-parameter listing tool it omits ordering, total-count/pagination behavior, and what a 'summary' contains, leaving gaps relative to what an agent may need.

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 every parameter (account, mailbox, limit, unread_only) is already documented with defaults and bounds. The description adds no parameter-specific detail beyond implicitly confirming summary-level output, 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+resource: 'List message summaries from an Apple Mail mailbox.' The word 'summaries' signals this is a lightweight listing, not full message retrieval. It does not name or contrast with siblings like search_messages or get_message, so it falls short of a 5.

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 only implied: an agent can infer this is the browse/list entry point for a mailbox, versus get_message for full bodies or search_messages for queries. No explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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 carry the behavioral burden. It discloses the user-approval gate and the same-account constraint (useful, since the schema's destination_mailbox never says cross-account is forbidden), but says nothing about what happens to the message in the source mailbox, whether the destination must already exist, or whether the operation is reversible.

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 short sentences, zero filler, with the core action stated first and the safety gate second. 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 no-annotation mutation with no output schema, the description covers the action, its scope limit, and the approval requirement. It stops short of describing failure modes or the destination-must-exist assumption, which an agent would only learn by trying.

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%, with each parameter (account, mailbox, message_id, user_approved, destination_mailbox) documented in the schema itself. The description adds no syntax, format, or default detail beyond that, 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 (move) and resource (a message) with a scope qualifier ('to another mailbox in the same account'). No sibling tool does moving, so an agent can identify it unambiguously from the list.

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 an explicit precondition ('Only call after the user explicitly approved this exact action'), which is the key gate for this mutation. It does not mention alternatives or when a move should be preferred over, say, drafting a reply, but there is no real competing tool.

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 does disclose the most important trait — read-only, no creation, no sending — which is genuine value. But it says nothing about what a failed validation looks like, whether it returns a pass/fail or a list of policy violations, or how the 'active local send policy' is resolved, which matters for a tool with no output schema.

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 the action and its constraint front-loaded, no filler. 'Read-only' is slightly redundant with 'without creating or sending anything', but it is a cheap and useful emphasis rather than 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 four-parameter, no-annotation, no-output-schema tool, the description covers the safety profile but not the result contract. Since there is no output schema, the description should indicate what a validation outcome looks like; that gap leaves the agent unsure how to interpret the response.

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% and the description mentions no parameters at all. It does not clarify that `from` is optional, nor that subject/text are length-bounded, nor that the message body goes in `text`. The field names are largely self-explanatory, but the description adds no meaning beyond them.

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?

Specific verb (validate) plus resource (a proposed email) plus the standard it is checked against (the active local send policy). It also negates the side effects of the nearest siblings (send_email, create_draft) with 'without creating or sending anything', so an agent can distinguish it from those tools without opening a 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?

The context of use is implied — validate a draft before it is sent — and the description rules out side effects. However, it never says explicitly when to call this versus get_send_policy, queue_email_for_approval, or simply calling send_email, nor does it name an alternative, so the routing is left to 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?

With no annotations, the description carries the full burden and usefully bounds the side effect (local inbox only, no draft, no send). However it omits reversibility, whether the item waits for approve/discard, and any permission or idempotency notes, so the disclosure is partial.

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 short sentences, front-loaded with the action and then the key non-behavior. Nothing is wasted and the disambiguation is placed where it will be read first.

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 10-parameter tool with no annotations and no output schema, the definition is complete enough to invoke but thin on the surrounding approval workflow (what happens after queuing, how it is reviewed/discarded). More context on the queue lifecycle would help the agent use 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 60%, so the non-obvious fields (note, tone, risks, intent, rationale, source_message_ids) are already documented in the schema and the self-evident required fields (to, subject, text) need little. The description adds no parameter-level meaning 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+resource ('Save a proposed email in the local approval inbox') and explicitly negates the two most confusable siblings (create_draft, send_email). An agent can tell this apart from the draft/send tools 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?

The exclusions ('does not create a Mail draft or send anything') give clear context and route the agent away from the sibling write tools, so the approval path is well signaled. It stops short of naming the adjacent approval siblings (approve_queued_email, discard_queued_email) or stating the positive 'when to use' condition.

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 behavioral burden. It usefully discloses that the write is confined to local storage and contacts no one, but omits the mandatory user-approval gate and says nothing about whether a repeat save merges or overwrites existing context.

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 short, waste-free sentences with the action front-loaded and the safety caveat second. Efficient, though the second sentence is doing double duty as usage and behavior guidance.

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 11-parameter mutation tool with no annotations and no output schema, two sentences are thin. Missing pieces include approval semantics, merge/overwrite behavior on repeat saves, and any indication of what the call returns.

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 only 36%, so the description is expected to compensate, and it adds nothing about any of the 11 parameters. Fields like notes, open_commitments, timeline_summary, preferred_language, and timeline_direction are left to bare type declarations.

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 (Save) plus resource and scope (local relationship context for one contact), and explicitly separates itself from email-modifying siblings. It does not name its read counterpart get_contact_context, so the differentiation from siblings is implied rather than stated.

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 an implicit trigger (saving local relationship context) and an explicit exclusion ('does not modify Apple Mail or contact the person'), which helps route the agent away from email tools. However, it never says when to prefer this over get_contact_context or similar, and does not surface the user_approved prerequisite.

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, and it does disclose two real behaviors: the write is local and it 'does not modify Apple Mail'. That is meaningful because it tells the agent the source mailbox is untouched. However it says nothing about where the summary is persisted, whether an existing summary is overwritten, or what permissions are required, so disclosure remains partial.

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 core action and followed by the non-obvious safety clause. Every clause earns its place, including the closing 'It does not modify Apple Mail'.

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 four-required-param mutation with no annotations and no output schema, the description covers the safety profile and the approval precondition but leaves the storage location, overwrite behavior, and the meaning of the email parameter unexplained. Adequate but with clear gaps an agent would want before calling it.

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 only 25% (just user_approved), so the description must compensate, and it partially does by clarifying that source_message_ids must be 'the exact source message ids used' — semantics the bare array-of-strings schema does not convey. It says nothing about the email parameter (contact address vs account) or the summary field, so the compensation is incomplete.

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 gives a precise verb and resource ('Save a local, user-approved summary of a selected contact thread') and notes the payload ('the exact source message ids used'), so an agent can tell it produces a stored summary rather than sending mail. It never names a sibling such as save_contact_context or get_contact_context, so differentiation is inferred rather than stated, which keeps it out of the top band.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, even though save_contact_context, get_contact_context, and get_contact_brief sit in the same family. The only usage signal is 'user-approved', which merely echoes the required user_approved const already enforced by the schema.

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 does disclose two useful traits: the operation is read-only and message bodies are excluded from matching. However, it says nothing about permissions, result ordering, pagination, or what 'recent' means relative to the scan_limit parameter.

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 short sentences, zero filler, with the core action front-loaded and the read-only/no-body-search caveat immediately after. 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 five-parameter read tool with no output schema and no annotations, the description covers purpose, safety profile, and search scope. The one gap is the vague 'recent' framing, which leaves the interplay between default result limit and scan_limit unstated.

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 all five parameters are documented in the schema itself; baseline is 3. The description's 'by subject or sender' loosely restates the query parameter's documented semantics and adds no syntax or format guidance beyond it.

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 (search) plus resource (messages) and narrows the match field to subject or sender within one mailbox. That is enough to separate it from list_messages (unfiltered listing) and get_message (single retrieval), though no sibling is named 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 phrase 'search recent messages by subject or sender' implies the use case, and 'bodies are not searched' implies a boundary, but no alternative tool is named and no explicit when/when-not condition is given. Usage must be inferred from the sibling set.

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 present, so the description carries the full burden. It usefully discloses the critical approval-gating behaviour and the Apple Mail transport. It does not disclose that sending is irreversible, whether the message is dispatched immediately or queued, or how failures surface — meaningful gaps for a destructive, outbound action.

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 action and followed immediately by the gating constraint. Every clause carries weight 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?

For an irreversible outbound action with no annotations and no output schema, the description covers the approval gate but leaves the post-send behaviour unspecified. It also misses the opportunity to route the agent to preview_send or queue_email_for_approval when approval is absent, so it is adequate but incomplete for the risk level.

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 60%; 'to', 'from', and 'user_approved' are documented in the schema, while 'text' and 'subject' are not. The description references 'this exact recipient, subject, and body', adding the semantic that the three required values must correspond to a single user-approved draft, which is meaningful but not a full parameter treatment.

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 ('Send an email using Apple Mail'), so the agent immediately knows the action and transport. However, it does not differentiate from relevant siblings such as preview_send or queue_email_for_approval, which perform adjacent send-related functions, leaving the agent to infer the distinction.

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 a clear, explicit precondition: call only after the user approved this exact recipient, subject, and body. This is strong usage context. It stops short of naming alternatives (preview_send, queue_email_for_approval) for cases where approval has not yet been granted, so it is clear but lacks 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?

With no annotations provided, the description carries the full burden and it does disclose a meaningful gate: explicit user approval is required before invocation. That safety context is valuable for a mutation tool. However it omits reversibility, whether the change persists server-side, and any rate or permission constraints, so behavioral disclosure is only partial.

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 short sentences with zero filler, and the action is front-loaded ahead of the approval 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?

The tool is fully self-describing on the input side thanks to the required const-constrained user_approved field at 100% schema coverage, and no output schema exists to explain. The description's approval statement is sufficient for correct invocation, but with no annotations it could add more about the mutation's effect and relationship to sibling flag tools.

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 account, mailbox, message_id, is_flagged and user_approved are all documented in the schema itself. The description adds no additional meaning such as message_id sourcing or flag semantics beyond what is already structured, 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?

The description states a specific verb and resource ('Flag or unflag a message'), which is clear and unambiguous. However it does not distinguish itself from sibling tools like set_message_read_status, which the agent must infer operates on a different flag.

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 gives a clear precondition ('Only call after the user explicitly approved this exact action'), which tells the agent when this tool is permissible. It does not name alternatives or contrast with set_message_read_status or move_message, so the routing guidance is partial rather than explicit.

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 behavioral burden. It does disclose the key trait, an explicit approval gate that is emphasized as 'this exact action', which is meaningful context. However, it says nothing about reversibility (marking read is undoable), permission requirements, error/failure behavior, or side effects on unread counts.

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 short sentences, front-loaded with the action and followed by the safety condition. No filler, no redundancy with the schema.

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 state-toggle tool with no output schema, the description plus the fully documented schema covers what an agent needs to call it correctly, including the approval gate. Minor gaps remain around failure modes and reversibility, but nothing essential 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%, with each of the five parameters documented, including the const-constrained user_approved flag. The description adds no syntax, defaults, 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?

The description names a specific verb and resource ('Mark a message read or unread'), which is unambiguous on its own. It does not, however, differentiate itself from the adjacent sibling set_message_flag_status, so the agent must infer the boundary between read-state and flag-state 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?

It gives a clear, explicit precondition: 'Only call after the user explicitly approved this exact action.' That is genuine when-to-use guidance. It stops short of naming alternatives or stating when not to use it (e.g. bulk operations), so it is strong but not complete.

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 behavioral burden. It usefully discloses that the mode gates queue/draft/send capability and that it does not affect Apple Mail, but omits persistence of the setting, effect on already-queued items, and the authorization requirement beyond what the schema already states.

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, front-loaded sentences with zero filler; the core action is stated first and the scope caveat follows.

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 state-changing tool with no annotations, no output schema, and a non-obvious enum, the description covers the gist but leaves the meaning of each mode and the durability/scope of the change unexplained.

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 50%: user_approved is well documented in the schema, but the mode enum values (general, inbox_zero, sales_follow_up, support, deep_work) have no description anywhere and their effects are not self-evident. The description adds the queue/draft/send framing but does not explain the individual modes, so it only partially compensates for the gap.

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 (Set) and resource (local AI-mail work mode) and clarifies the scope boundary with 'This does not change Apple Mail.' It does not explicitly name the sibling get_work_mode, so differentiation is left partly 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 description explains what the mode governs (queue, draft, send), which implies why one would set it, but gives no explicit when-to-use guidance, no condition for choosing a mode, and no reference to alternatives like get_work_mode.

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