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

The annotations indicate a non-read-only, non-idempotent write operation. The description adds context by specifying 'new' (create vs. update) and 'local' (calendar scope), which goes beyond the annotations. However, it does not disclose permissions, side effects, or duplicate 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?

The description is a single concise sentence with no fluff, front-loaded with the verb and object. It is appropriately sized for the purpose clarity it provides.

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 7 parameters, low schema coverage, and no output schema, the description is insufficient. It doesn't explain parameter values, behavior on local calendars, or how to use the tool in context. It's a minimal one-liner.

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 very low (only 'calendar' has a description). The tool description adds no parameter information, leaving date format, allDay semantics, and required parameters unexplained. This is a significant gap for a tool with 7 parameters.

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

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

The description clearly states the action ('Create') and the object ('a new local Calendar.app event'), distinguishing it from sibling tools like apple_calendar_update_event and apple_calendar_delete_event. The 'local' qualifier adds specificity.

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 does not provide any guidance on when to use this tool versus alternatives like apple_calendar_update_event, nor does it mention prerequisites such as available calendars or required date formats. It only implies usage by its name and description.

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

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

The description adds 'existing' and 'local' context beyond the annotations, which already declare destructiveHint. It explicitly states 'This is destructive,' which reinforces the annotation but does not add significant new behavioral details such as permissions or reversibility.

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

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

The description is two concise sentences, delivering the essential purpose and destructive nature without any unnecessary wording. It is well-structured and front-loaded.

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

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

For a simple delete tool, the description is adequate but lacks specifics about behavior when the event is not found, return values, or prerequisites. The annotations and schema cover some aspects, but the description could provide more context for complete understanding.

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 50%, with only 'calendar' having a description. The tool description does not explain 'uid' at all, leaving it ambiguous. Since there are only two parameters, the description should have clarified that uid is the event identifier, but it does not.

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

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

The description clearly states the tool deletes an existing local Calendar.app event, using a specific verb and resource. It distinguishes itself from sibling tools like create_event or list_events by focusing on deletion and specifying 'local Calendar.app'.

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 usage: use this tool when you need to delete an existing local Calendar.app event. However, it does not explicitly mention when not to use it or provide alternative tool recommendations, leaving the guidance mostly implied.

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

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

The description explicitly labels the tool as 'Read-only,' matching the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true). It adds valuable context by specifying the output includes calendar names and writable status, which goes beyond what the annotations convey. No contradictions.

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

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

The description is a single, well-structured sentence. It front-loads the 'Read-only' behavior, states the resource and output, and gives a usage directive. Every word earns its place with zero 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?

Given the tool's simplicity (no parameters, no output schema), the description fully covers its purpose, output, and context. The usage note about creating/modifying events provides the needed situational context, making the tool complete for an agent to select and invoke correctly.

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

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

The tool has zero parameters, so the schema fully covers any inputs (none). The description adds no parameter details, but none are needed. The baseline for 0 params is 4, and the description's mention of listing names and writable status already implies what is returned.

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 action ('list local Calendar.app calendar names') and the output detail ('whether each calendar is writable'). It also connects to sibling tools by indicating it is a precursor to creating or modifying events when the calendar name is unknown, distinguishing it from event-related tools.

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

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

The description provides an explicit usage condition: 'Use this before creating or modifying events when the exact calendar name is unknown.' This clearly tells the agent when to invoke this tool and implicitly when not (when the calendar name is known). It gives actionable context without naming alternatives, which is sufficient for the simple use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'local' context and time-range scoping, but does not disclose pagination, return format, or default filtering behaviors beyond what annotations/schema provide.

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

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

The description is a single well-structured sentence that front-loads the read-only nature, then states the action and scope. Every word adds value 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 a simple list tool with four parameters, strong annotations, and no output schema, the description plus schema provide sufficient context for an agent to invoke it correctly. It clearly indicates read-only behavior, the resource, and the time-range requirement.

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

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

The schema covers 75% of parameters with descriptions (start, end, calendars). The description does not add parameter-level detail beyond the schema, so it holds at the baseline for high schema coverage.

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'), resource ('local Calendar.app events'), and scope ('in a time range'), clearly distinguishing it from sibling tools like apple_calendar_list_calendars (which lists calendars) and mutation tools like create/update/delete.

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 usage for read-only retrieval of calendar events within a time range, but it does not explicitly state when to use this tool over alternatives or mention exclusions. No alternatives are named, so guidance is only implied.

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 convey destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds little beyond that, but clarifies the scope ('existing local Calendar.app event'). It doesn't contradict annotations, and the existing annotations carry the primary safety information.

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 concise sentences, front-loaded with the main purpose. The second sentence adds actionable guidance. No wasted words.

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 8 parameters and no output schema, this description is sparse. It lacks essential context such as whether all fields are required or only provided fields are updated, what happens on success/failure, and how to handle time zone or allDay interactions. The prerequisite note helps, but overall completeness is low.

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 13% (only 'calendar' has a description). The description compensates minimally by explaining that uid comes from apple_calendar_list_events, but it does not add semantics for start, end, title, allDay, location, or notes. It also doesn't clarify whether the update is partial or full replacement, which is critical for correct usage.

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

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

The description clearly states the verb and resource: 'Modify an existing local Calendar.app event.' This distinguishes it from sibling tools like create and delete, and specifies the domain (Calendar.app). The additional instruction to obtain the uid from apple_calendar_list_events reinforces the purpose.

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

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

The description provides a clear prerequisite: 'Obtain the uid from apple_calendar_list_events.' This implies the appropriate workflow and when to use this tool (for existing events). It doesn't explicitly mention alternatives like create/delete, but the context is clear enough.

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 destructiveHint=true and readOnlyHint=false. The description adds useful context that deletion follows Mail.app's behavior (e.g., moving to Trash), and specifies it applies to local messages. This goes beyond the annotations without contradiction.

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 concise sentences deliver the essential action, destructive warning, and behavioral nuance. No filler or redundant 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 delete operation with three parameters and no output schema, the description covers the core behavior, destructive nature, and Mail.app-specific handling. It could mention prerequisites (e.g., mailId from apple_mail_list) but the schema already documents that.

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 parameter meanings are fully documented in the schema. The description itself doesn't add parameter-specific detail, but doesn't need to given the schema's completeness.

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

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

The description clearly states the action ('Delete a local Apple Mail message') and the resource (Apple Mail message). It distinguishes from sibling tools like apple_mail_move and apple_mail_update_status by specifying deletion behavior.

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 indicates when to use this tool—for deleting a local Apple Mail message—and notes the destructive nature. It doesn't explicitly name alternatives or when-not conditions, but the purpose is clear and context is provided.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds the behavioral detail that the body is included and that the id is local, but does not describe return format or error behavior. This is acceptable given the annotation coverage.

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

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

The description is two sentences with no redundant content. It front-loads the core purpose and then provides the key usage step, making it efficient and well-structured.

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?

Despite lacking an output schema, the description clearly states the message body is included, which is the most important return detail. It also gives the prerequisite workflow. A minor gap is the lack of detail on other returned message fields, but the description remains sufficient for a simple read tool.

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 clear parameter descriptions for mailId, account, and mailbox. The description does not add extra parameter-specific meaning beyond referring to the local id, so it relies on the schema as expected.

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 explicitly states the action (read), the resource (one local Apple Mail message), and the scope (including its body). It differentiates from sibling tools by being read-only and focusing on a single message, making the purpose 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?

The description provides clear usage context by instructing to call apple_mail_list first to obtain the local mail id. It implies the appropriate workflow but does not explicitly exclude alternative tools such as send or delete, so it stops short of full when-not guidance.

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 read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond these: it lists exact metadata fields returned, clarifies that message bodies are not accessed, and scopes to 'local Apple Mail metadata'. This transparency helps an agent understand side effects (none) and output granularity.

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

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

The description is two sentences, with the primary action and scope front-loaded ('Read-only: list local Apple Mail metadata'). The second sentence adds return fields and an explicit exclusion (no bodies). Every word earns its place with no redundancy.

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

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

With no output schema, the description compensates by listing the returned fields and clarifying body exclusion. It also covers the local scope. Minor gaps exist (e.g., no mention of ordering, pagination, or default mailbox) but the schema provides defaults for account and mailbox, and the simplicity of the tool reduces the need for more detail.

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%, as each parameter (limit, account, mailbox) has a clear description. The tool description adds no additional parameter-specific detail beyond the schema, so a baseline score of 3 is appropriate; the schema carries the semantic load.

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

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

The description uses a specific verb ('list'), names the resource ('local Apple Mail metadata'), and enumerates return fields (message ID, sender, subject, received time, read/flag status). It clearly distinguishes from siblings like apple_mail_get (which reads bodies) and apple_mail_send/delete/move (which mutate mail).

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 establishes clear context: it is a read-only listing operation and explicitly states it does not read message bodies, which implies use apple_mail_get when bodies are needed. It does not explicitly name alternatives or provide when-not-to-use instructions, but the context is sufficiently clear for safe selection.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying exactly what data is returned (account names, sender addresses, mailbox names), which helps the agent anticipate the output. No destructive behavior is implied, consistent with annotations.

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

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

The description is two sentences: the first declares the read-only function, the second provides usage guidance. Every word earns its place, and it front-loads the key information. No redundant content.

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-only discovery tool with no output schema, the description is complete: it states the function and usage context, and lists the returned data. An agent can confidently invoke this tool before other Mail tools without needing more details.

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

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

The tool has zero parameters and the schema coverage is 100% (empty properties). With no parameters to document, the baseline is 4 per the rubric. The description adds value by implying the tool takes no input and lists all local accounts, which is sufficient.

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

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

The description uses a specific verb and resource: 'list local Apple Mail account names, sender addresses, and mailbox names.' It clearly distinguishes itself from sibling tools like apple_mail_list (which likely lists emails) by focusing on account-level metadata and is labeled 'read-only.'

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

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

The description provides explicit timing: 'Use this before other Mail tools when the exact names are unknown.' This gives clear context for when to use the tool, though it does not mention when not to use it or alternative tools. This is strong guidance but lacks explicit 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?

Annotations already mark this as destructive (destructiveHint=true) and non-read-only. The description adds the constraint that the operation works only within the same account and that it concerns local messages, which is useful. It does not elaborate on side effects or error conditions, but the annotation covers the primary behavioral concern.

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?

A single, front-loaded sentence with no extraneous words. The verb appears first, followed by the object and constraints.

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

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

The tool is simple and the description covers the essential action and scope, but it leaves ambiguity about the mailbox parameter's relationship to the source mailbox and does not mention return values. Given the lack of an output schema, a bit more detail about expected behavior would improve completeness.

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

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

The schema provides descriptions for three of four parameters; targetMailbox is left undocumented. The description does not clarify the role of the source mailbox parameter (mailbox) or the format for targetMailbox, relying mostly on parameter names. It adds the 'same account' context but little else beyond the schema.

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

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

The description clearly states the action (move), the resource (a local Apple Mail message), and the destination (another mailbox in the same account). This distinguishes it from sibling tools like delete, send, or update.

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

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

The purpose makes it evident when to use: to relocate a message within the same account. However, it does not offer explicit guidance on when not to use it or mention alternatives such as apple_mail_delete or apple_mail_update_status for related operations.

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

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

The description adds behavioral context beyond annotations by stating that sending is immediate ('immediately sends email') and that it comes from a selected local account. This is useful because annotations only indicate it's a write operation (readOnlyHint=false) without specifying timing or source selection. However, it does not disclose irreversibility or potential error conditions.

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

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

The description is concise, front-loaded with the core action, and every sentence adds value. It is two sentences long with no redundant content, making it easy to parse quickly.

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

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

For a tool with 6 parameters and no output schema, the description is too brief. It states the immediate send behavior but does not explain return values, error scenarios, or how the account parameter relates to available accounts. Sibling tools could provide some context, but the tool itself leaves gaps for an agent relying solely on the description.

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?

With only 33% schema description coverage, the description needed to compensate but barely does. It mentions 'specified recipients' which covers the 'to' parameter, but does not explain subject, body, cc, bcc, or account beyond a vague reference to 'selected local account'. This leaves users guessing about required fields and defaults.

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

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

The description clearly states the action with a specific verb ('Send'), the resource ('Apple Mail message'), and the source context ('from the selected local account'). It distinguishes itself from sibling tools like apple_mail_list and apple_mail_get by focusing on sending rather than reading or managing.

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

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

The description provides some context ('from the selected local account') but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like listing accounts or needing a subject. The usage is implied by the verb 'send' but without concrete guidance 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?

The description adds useful context by specifying the message is 'local' and by naming the exact status fields that can be modified. However, it does not disclose additional behavioral traits such as side effects, return values, or how partial updates behave. The annotations already provide destructiveHint and idempotentHint, so the description adds limited transparency beyond those.

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

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

The description is a single, front-loaded sentence of 14 words. It contains no filler and directly states the tool's purpose. Every word contributes to understanding the function.

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 has 5 parameters, annotations, and no output schema. The description is sufficient to grasp the basic operation, but it lacks usage context, alternative guidance, and any indication of what the tool returns (e.g., updated message or success status). Given the mutation nature and absence of an output schema, the description is adequate but has clear gaps, making it minimally viable.

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 input schema describes 3 of 5 parameters (mailId, account, mailbox) but leaves isRead and isFlagged without descriptions. The tool description partially compensates by mentioning 'read/unread and/or flagged status', but it does not clarify boolean semantics (e.g., true means read) or that omitted fields leave status unchanged. It adds some meaning but not enough to fully cover the gaps.

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

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

The description uses the specific verb 'Modify' and identifies the resource ('local Apple Mail message') along with the affected attributes ('read/unread and/or flagged status'). This clearly differentiates it from sibling tools like apple_mail_list, apple_mail_get, apple_mail_send, apple_mail_move, and apple_mail_delete.

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 usage for updating a message's status but provides no explicit when-to-use guidance, alternatives, or exclusions. It does not mention prerequisites like listing messages first to obtain a valid mailId, which the schema hints at but the description omits.

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=false and destructiveHint=true, and the description's 'Mark as completed' is consistent with those. The description adds the qualifiers 'local' and 'existing', which are useful, but it does not disclose side effects or error behavior beyond the annotations. With annotations present, the bar is lower, and this meets it minimally.

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

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

The description is a single, unambiguous sentence with no filler or redundant wording. It conveys the action clearly in the fewest possible words.

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 one-parameter tool with annotations and no output schema, the description is adequate but incomplete. It lacks explicit usage distinction from apple_reminders_update and does not mention idempotency or error behavior if the reminder is already completed. Adding a note about idempotence or a pointer to the update tool would improve completeness.

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

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

The schema description covers 100% of the parameter semantics, stating that 'id' is the 'Reminder id returned by apple_reminders_list'. The description adds no additional parameter details, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Mark' and the resource 'Apple Reminder' with the specific outcome 'as completed'. It is distinguishable from create/delete/list, though it does not explicitly contrast with the sibling apple_reminders_update, which could also modify a reminder.

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 is given on when to use this tool versus alternatives like apple_reminders_update. The description only states the action without prerequisites, context, or exclusions, leaving the agent to infer the intended use case.

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

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

The word 'local' adds a minor behavioral trait indicating the reminder is stored locally rather than synced. Annotations already indicate a write operation (readOnlyHint=false), so the description contributes little beyond this. No side effects, permissions, or return behavior are disclosed.

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

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

The description is a single, front-loaded sentence that wastes no words. However, it is so minimal that it borders on under-specification, though conciseness itself is strong.

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

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

Given the tool has five parameters, no output schema, and no parameter descriptions, a one-sentence description is severely inadequate. It does not explain required fields, valid inputs, or expected behavior, leaving critical 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 coverage is 0% and the description provides no semantics for any of the five parameters (list, title, dueAt, notes, priority). The agent only has type/constraint information from the schema, which is insufficient for correct invocation.

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

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

The description clearly states a specific action ('Create') and resource ('Apple Reminder'), and the qualifier 'local' distinguishes it from other reminder operations like complete/delete/update. It effectively communicates the tool's primary purpose.

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 is provided on when to use this tool versus alternatives (e.g., apple_reminders_update, apple_reminders_complete). There are no prerequisites mentioned, such as needing an existing list or proper permissions.

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 destructiveHint=true and readOnlyHint=false, so the description's 'This is destructive' is redundant. It adds only the 'local' scope detail, which provides minimal extra context. No further consequences or side effects are disclosed.

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 no fluff. Every word earns its place, making it highly concise and easy to parse.

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 delete tool with one parameter, full schema coverage, and annotations covering destructive behavior, the description is nearly complete. It lacks explicit irreversibility wording, but annotations already signal destructive intent, so the overall context is sufficient.

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 parameter 'id' already described as 'Reminder id returned by apple_reminders_list'. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb 'Delete' and resource 'existing local Apple Reminder', clearly distinguishing it from sibling operations like complete or update. It leaves no ambiguity about what the tool does.

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 usage context (deleting a reminder) but does not provide explicit when-to-use or exclusions, such as 'use complete instead if you want to mark as done' or 'cannot be undone'. While the purpose is clear, alternatives and prerequisites are not addressed.

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

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

The description repeats the readOnlyHint annotation (read-only) and adds 'local' as minor context. It does not disclose behaviors like default limits, filtering options, inclusion of completed items, or any return format. With annotations already covering safety, this adds minimal value.

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

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

The description is concise and front-loaded with 'Read-only', using a single sentence without waste. However, it is borderline under-specified, though not as extreme as a pure tautology; it provides at least the core action and resource.

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

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

Given the tool has 3 parameters and no output schema, the description lacks essential context such as how filtering by lists works, the meaning of includeCompleted, default behavior, or what the output looks like. It is too sparse to fully handle the tool's complexity, leaving significant gaps for the agent to guess.

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 low (33% – only 'lists' has a description), and the description does not mention any parameters. The parameter names (limit, includeCompleted, lists) are somewhat self-explanatory, but the description fails to clarify their semantics or relationships, leaving the agent to infer from names alone.

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 clear verb ('list') and resource ('local Apple Reminders'), which distinguishes it from sibling tools like apple_reminders_list_lists (which lists lists, not reminders). However, it does not explicitly mention this distinction, relying on the tool name and the word 'Reminders' to infer the resource type.

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 is provided on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific use cases beyond the bare 'list local Apple Reminders.' The agent has no help in deciding between this, list_lists, or other reminder 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 already disclose readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read-only' prefix is redundant. It adds the 'local' scope and a practical use case, but does not reveal further behavioral traits such as return format specifics or potential limitations. The description does not contradict the annotations.

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

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

The description is two sentences long, front-loaded with the key read-only nature, and conveys the exact purpose and usage context without any fluff. Every word contributes to understanding.

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, parameterless tool with no output schema, the description fully covers the tool's role: it lists list names and IDs, is read-only, and provides a clear use case. The sibling list shows this is a distinct operation, and nothing critical 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?

With zero parameters, the schema coverage is effectively 100% and there is no parameter information to clarify. The description does not need to add parameter semantics, and the baseline of 4 for no-parameter tools is appropriate.

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

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

The description clearly states the tool lists 'local Apple Reminders list names and IDs' with the specific verb 'list' and a defined resource. It distinguishes itself from sibling tools like apple_reminders_list (which lists reminders) and the create/update/delete tools by focusing on list names and IDs.

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 explicitly advises using this tool 'before creating reminders when the exact list name is unknown,' providing clear context for when to use it. It does not explicitly mention when not to use it or name an alternative, but the guidance is direct and useful for an agent.

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

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

Annotations already indicate write/destructive/idempotent behavior, but the description adds no extra context—not even that it performs a partial update, returns the updated reminder, or that it requires an existing id. 'Modify' adds little beyond the tool name.

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

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

The description is a single, front-loaded sentence with no filler. It gets straight to the point, which is concise and easy to parse. It doesn't include unnecessary details, though a bit more context might add value.

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, no output schema, and sparse annotations, the description is far too minimal to fully inform an agent. It doesn't explain the full effect of the update, return values, error cases, or partial-update semantics, leaving significant gaps for a non-trivial mutation tool.

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 20% (only the 'id' field has a description), and the tool description does not compensate by explaining any of the other parameters (title, notes, dueAt, priority). It doesn't mention that dueAt can be null to clear a date, or that priority must be 0-9, leaving the agent to rely on bare schema types.

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

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

The description clearly states the action ('Modify') and the resource ('existing local Apple Reminder'). It distinguishes itself from sibling tools like create, delete, and complete, though it doesn't explicitly name alternatives. The word 'local' adds useful scope.

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 that this tool is used to change an existing reminder, but it does not specify when to prefer it over complete or delete, nor does it mention prerequisites like obtaining an id from list. No exclusions or alternative tool references are provided.

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