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

The description does not disclose any behavioral traits beyond the action itself. Annotations indicate it is not read-only, but the description does not mention side effects (e.g., task location defaults, verification of repetition). The schema's repetition description mentions verification failure removing the task, but the main description omits this.

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 very concise, using a single sentence. It is front-loaded with the core action, but lacks structure for complex details. It earns its place as a starting point.

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 complexity (13 parameters, nested objects) and no output schema, the description is insufficient. It does not explain return values, behavior when project is missing, or how failure is handled. The schema provides some details, but the description should cover high-level context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional meaning or context beyond the schema's descriptions. Baseline of 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?

The description clearly states the action (add) and resource (task to OmniFocus). However, it does not differentiate from sibling tools like add_project or batch_add_items, which are also addition 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools might be more appropriate.

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 does not disclose behavioral traits beyond the basic action. With annotations lacking destructive/readOnly hints (both false), the description should mention potential side effects, required permissions, or error conditions like duplicate names.

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 sentence that is concise and front-loaded. However, some additional context could be included without becoming verbose.

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 11 parameters, no output schema, and no annotations with behavioral hints, the description is insufficient. It does not explain return values, fail cases, or setup requirements, leaving the agent underinformed.

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 parameters are documented in the schema. The description adds no extra meaning beyond 'Add a new project', missing opportunities to clarify parameter interactions or 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 verb and resource: 'Add a new project to OmniFocus'. It is specific and differentiates from sibling tools like add_omnifocus_task or add_folder, which deal with tasks or folders.

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, such as when to create a task instead of a project. No exclusions or prerequisites are mentioned.

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 indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive), which the description complements by explicitly stating 'without overwriting'. This adds meaningful behavioral context beyond the annotations, but does not cover error conditions or side effects.

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

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

The description consists of two clear, front-loaded sentences without unnecessary words. Every part serves a purpose: defining the action and suggesting use cases.

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?

While the tool is relatively simple, the lack of an output schema and no mention of return values or error cases leaves a gap. The description covers the core action well but is incomplete for a fully self-contained definition.

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 has 100% coverage with descriptions for all 5 parameters. The description does not add significant parameter-level information beyond what the schema already provides, so a baseline score of 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?

The description clearly states 'Append text to a task or project note without overwriting', which specifies the verb (append) and the resource (note of task/project). It distinguishes itself from potential alternatives like edit_item that might overwrite, thus achieving a high score.

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 context for when to use the tool ('useful for logging progress or adding context'), but does not explicitly state when not to use it or compare with sibling tools. This gives good guidance 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?

Annotations already indicate the tool is not read-only. The description adds no behavioral context beyond the fact it adds items; it does not disclose atomicity, error handling, limits, or what happens on conflict. Given the presence of annotations, the description 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 a single, clear sentence with no unnecessary words, fully conveying the tool's purpose.

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 one parameter with nested objects fully described in the schema. The description is adequate for a batch add operation, though it lacks details on operational aspects like atomicity and partial failure handling.

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 all parameters described in the schema. The description adds no additional meaning beyond the schema, warranting the baseline score of 3.

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 ('Add multiple tasks or projects to OmniFocus in a single operation'), distinguishing it from sibling tools like add_omnifocus_task (single task) and add_project (single project).

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 bulk usage but does not explicitly state when to use this tool over alternatives (e.g., adding items individually). No when-not or alternative guidance 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?

The description goes beyond the annotations by detailing preflight validation, result verification, rollback on failure, and the special behavior for repeating tasks. These are not captured in the annotations (readOnlyHint, destructiveHint) and provide valuable insight into the tool's safety and side effects.

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

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

The description is concise at three sentences, each earning its place: the first defines the core action and batch limit, the second covers operational guarantees (preflight/verification/rollback), and the third highlights an important edge case. No unnecessary words are used, and key information is 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?

The description provides comprehensive context for a complex batch mutation tool: it addresses failure handling, result verification, and repeating task behavior. The absence of an output schema is compensated by the high level of operational detail. A minor omission is the lack of mention of the return format, but this is not critical for tool selection.

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 provides 100% coverage for the 'items' parameter, including descriptions for taskId, action, and completionDate. The description adds minimal new parameter-level semantics, mainly restating the 'stable ID' concept and optional completion dates. It does not significantly enhance what the schema already explains, so the baseline of 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?

The description clearly states the tool's function: 'Mark tasks complete or incomplete by stable ID.' It uses a specific verb (mark) plus the resource (tasks) and distinguishes itself from sibling batch tools like batch_move_tasks and batch_remove_items by focusing on completion status.

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 usage context by noting it accepts up to 100 items, implying a batch operation. However, it does not explicitly mention when not to use it or name alternatives, such as using edit_item for single-task updates. The batch scope is communicated but no 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?

Annotations already mark it as destructive; the description adds behavioral details (preflight validation, post-verification) that go beyond the annotations, providing useful context for an AI agent.

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 redundant words. The first sentence states purpose, the second adds behavioral details. Highly efficient.

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 no output schema and complex input, the description covers the key behavioral pattern (validation then execution). Could mention atomicity or partial failure handling, but overall adequate.

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 detailed descriptions for all parameters. The description reinforces the 'confirmed' and 'preflighted' aspects but does not add significant new meaning 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 verb 'Move' and the resource 'tasks', specifying destinations (projects, parent tasks, Inbox) and emphasizing a 'confirmed set', distinguishing it from the sibling 'move_task' tool.

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 batch use with validation and verification, but does not explicitly state when to use versus single-task alternatives or when not to use it.

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 destructiveHint=true, but the description adds valuable behavioral context: the batch is validated before deletion and every ID is verified absent afterward, which is not captured by annotations alone.

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

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

Two sentences with no wasted words. The key information is front-loaded in the first sentence.

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

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

For a batch operation with validation, the description adequately covers pre- and post-conditions. No output schema exists, so it's complete enough.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, such as 'stable ID' and 'user-confirmed set', but these are largely redundant.

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 it removes a batch of tasks or projects by stable ID, using specific verb 'Remove' and resource 'tasks or projects'. It distinguishes from the sibling 'remove_item' which presumably removes a single item.

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 mention when to use this tool vs alternatives like 'remove_item' or 'batch_move_tasks'. No explicit context or exclusions are 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by stating it is 'fast' and describing the return shape ('total plus a breakdown by status'). No contradictions or hidden behaviors are 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?

The description consists of two tightly packed sentences. The first sentence states the core purpose (count without full list), the second adds speed and output details. No wasted words; every phrase 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 tool with 18 parameters and no output schema, the description covers the essential context: purpose, usage distinction from filter_tasks, and high-level return shape. The annotations handle safety, and the schema handles parameter details. Minor omissions like explicit note about zero-result behavior are not critical, so it's nearly complete.

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 provides 100% parameter coverage with descriptions for all 18 properties, so the baseline is 3. The description adds no additional parameter-specific meaning beyond referencing that it 'uses the same filters as filter_tasks,' which is a usage hint rather than parameter semantics. Thus, it neither improves nor degrades the schema's clarity.

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 verb ('Count tasks matching filters') and resource ('tasks'), and distinguishes the tool from siblings like filter_tasks by explicitly noting it does not return the full list. It also mentions the output (total plus breakdown by status), 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 indicates usage for 'fast how many queries' and notes that it uses the same filters as filter_tasks, implying filter_tasks is the alternative for retrieving full lists. However, it doesn't explicitly state 'when not to use' scenarios or name alternatives like get_tasks, so it falls just short of the highest guideline clarity.

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 are generic (no hints set), so the description carries the burden. It discloses key behaviors: user confirmation, preflighting, single-request creation, and read-back verification, which go beyond the minimal annotation info.

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, zero fluff: first states purpose with key qualifiers, second explains process. Every word adds 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?

Given the complex nested schema and no output schema, the description covers the essential creation flow (preflight, atomic creation, verification). It omits return values and error scenarios, but the stated behavioral traits are sufficient for an agent to 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?

Schema description coverage is 0%, and the tool description adds no parameter-level meaning. The nested 'project' object has inline schema descriptions for its properties, but the tool description itself does not compensate for the missing schema-level description.

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 'Create' and resource 'project tree', and adds clarifying context: 'user-confirmed', 'stable folder/tag IDs'. This distinguishes it from siblings like add_project (single project) and batch_add_items (flat batch).

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 the creation process (preflighted, one request, verification) but does not explicitly state when to use this tool versus alternatives like add_project for simple projects or batch_add_items for flat structures.

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, destructiveHint=false, idempotentHint=true. The description adds no further behavioral context (e.g., performance impact, payload size). It is consistent but does not exceed what annotations 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, front-loaded sentence with no extraneous words. It is concise, though it could benefit from additional context without sacrificing brevity.

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 broad dump tool, the description lacks detail on what 'current state' includes (all data? metadata?), and does not mention potential resource usage or output format. Given no output schema, more completeness is needed.

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

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

Schema coverage is 100%, so parameters are well-defined. The description does not add extra meaning beyond the schema, meeting the baseline expectation.

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 verb 'Gets' and specifies 'current state of your OmniFocus database', clearly indicating a full data dump. It distinguishes from sibling tools that target specific entities like folders or tasks.

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 tool versus the many sibling tools for specific queries (e.g., list_folders, filter_tasks). An agent lacks context on trade-offs or scenarios where a full dump is appropriate.

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 are limited. Description adds optional subtask copying and renaming, but doesn't detail which properties are copied or side effects. Adequate but not rich.

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?

Single sentence with key info. Could be slightly more structured, but efficient 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?

With 4 parameters and no output schema, description covers core purpose and options. Missing return value details and error handling. Adequate.

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 covers 100% of parameters with descriptions. Description rephrases schema info without adding new semantic depth. Baseline score.

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?

Clear verb 'duplicate' and resource 'task' with options for subtasks and new name. Distinguishes from sibling tools like move_task, edit_item.

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?

Mentions 'template-based workflows' for context but lacks explicit when-to-use vs alternatives or when-not scenarios.

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 only says 'Edit', which matches the destructiveHint=true annotation, but provides no additional behavioral details (e.g., that it can modify multiple fields, move items, or change status). The burden falls on annotations, but the description adds almost no value beyond them.

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, front-loading the core purpose. However, it is so brief that it may omit necessary context for a tool with 23 parameters, making it slightly underspecified.

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 complexity (23 parameters, no output schema, limited annotations), the description is insufficient. It fails to summarize the scope of editable fields, the side effects of edits, or any constraints. The agent must rely entirely on the schema for operational context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no further meaning beyond the schema; it merely restates that the tool edits tasks or projects. No parameter-specific elaboration is provided.

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 'Edit' and the resource 'task or project in OmniFocus', providing a specific purpose. However, it does not differentiate from sibling tools like edit_folder or edit_tag, which may cause confusion.

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

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

The description offers no guidance on when to use this tool versus alternatives such as add_omnifocus_task, add_project, or other mutation tools. No when-to-use or when-not-to-use information 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 safety. The description adds the behavioral detail of optional subtask-tree expansion, which is useful. However, it doesn't mention pagination, default limits, or how multiple filters combine, which would be valuable behavioral context. No contradiction with annotations exists.

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 conveys the core purpose without wasted words. It is appropriately concise for its role as a high-level summary, given the detailed schema provides specifics.

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 the complex schema with 44 parameters, the description gives no contextual guidance on how to combine filters, whether filters are AND/OR, or how the tool relates to sibling tools. It also doesn't explain pagination or output mode behavior, which are important for correct invocation. The description is too sparse to fully support an agent in using this complex tool effectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description groups parameters into categories (status, dates, projects, tags, search) which helps orient the agent, but does not add new per-parameter meaning beyond what the schema already provides. The mention of subtask expansion aligns with showSubtasks and maxSubtaskDepth, but adds little extra.

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 performs advanced filtering on tasks by multiple criteria such as status, dates, projects, tags, and search. This distinguishes it from simpler sibling tools like get_tasks, though it doesn't explicitly name an alternative. The verb 'filtering' and resource 'tasks' are specific, and the mention of subtask-tree expansion adds clarity.

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 no guidance on when to use this tool versus alternatives like get_tasks or count_tasks. It does not state exclusions or prerequisites, such as whether it is intended for complex queries while simpler tools exist for basic listing. The word 'advanced' implies a use case but is not explicit 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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that view=all is the default and that view=due_for_review targets overdue reviews, but it does not disclose other behaviors like result shape or pagination. This is a modest addition beyond 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, front-loaded with the primary purpose, and contains no fluff. Every word earns its place, and the key distinction between the two views is stated clearly.

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 read-only list tool with 5 optional parameters and no output schema, the description covers the main usage options and default behavior. It doesn't detail return fields, but since it's a 'list projects' tool and annotations cover safety, the description is complete enough for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters and their descriptions. The description reinforces the view parameter's purpose but does not add substantial meaning to status, folderName, includeOnHold, or includeReviewData beyond what the schema provides. 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?

The description uses the specific verb 'List' with the resource 'OmniFocus projects', clearly identifying what the tool returns. It distinguishes between two view modes (all vs due_for_review), which separates it from sibling tools like get_tasks that focus on tasks.

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 states when to use each view parameter: view=all for status/folder filters, view=due_for_review for overdue review work. This gives clear context on how to choose between modes, though it doesn't explicitly compare against alternative tools. It is clear enough for most scenarios.

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 and destructiveHint=false, so the tool is safe. The description adds detail about alternative lookup by name and the ability to expand subtasks, which annotations do not cover. No 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?

The description is a single concise sentence that front-loads the verb and resource. No wasted words, and every part adds 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?

Given the rich input schema, clear annotations, and no output schema required, the description is adequate. It explains the core functionality (get by ID or name) and hints at subtree expansion via parameters. Minor missing details like return format are not critical for this simple 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%, so each parameter is already documented. The tool description does not add new meaning beyond the schema, but it confirms the dual lookup by ID or name, which aligns with the schema. Baseline of 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?

The description clearly states the verb 'Get', the resource 'information about a specific task', and the means 'by ID or name'. It distinguishes the tool from sibling tools that list or filter tasks by criteria.

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 get_inbox_tasks or filter_tasks. It lacks context about when not to use it or what prerequisites exist.

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 read-only, idempotent, non-destructive behavior. The description adds the note that source-specific parameters are strictly validated, which is useful, but it doesn't describe output format, pagination, or error behavior. The added value is modest and comparable to a typical read 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?

The description is two sentences, front-loaded with the core action and scope, and contains no filler. Every phrase 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 14 params and no output schema, a brief description is somewhat insufficient. The schema covers parameter semantics, but the description does not explain what the return value looks like (e.g., list vs single object) or any additional behavior like default filters. The core read intent is clear, but an agent might want more context on expected response shape.

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 detailed per-parameter descriptions including conditional usage (e.g., 'forecast only', 'tag only'). The description adds no additional parameter meaning beyond restating that parameters are validated per source. 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?

The description specifies a clear verb+resource: 'Read tasks' and enumerates five distinct sources (inbox, flagged, forecast, tag, custom). This differentiates it from siblings like filter_tasks or get_task_by_id, which handle different retrieval modes.

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 direct instruction on how to select a view ('Use source to select the view') and highlights that source-specific parameters are validated. It does not explicitly mention alternatives or when not to use this tool, but the context is clear enough for an agent to understand selection behavior.

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?

Beyond the annotations (destructiveHint: true), the description discloses the specific consequence of removal ('permanently deletes contained projects and tasks') and clarifies the mixed read/write nature. This adds valuable context not present in the structured 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?

Two sentences totaling ~30 words, front-loaded with the operation list and immediately followed by the critical destructive warning. No filler or redundant restatement of schema details.

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

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

Given the tool's complexity (7 params, no output schema), the description covers purpose, operations, and destructive consequences well. It does not describe return values, but the absence of an output schema and the straightforward nature of folder operations make this a minor gap rather than a critical omission.

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 each parameter already has a description. The tool description adds value by tying actions to mutability (e.g., 'add/edit mutate'), enriching the meaning of the action parameter. However, it does not describe parameter formats beyond schema, so it stays just above the baseline.

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 ('List, get, add, edit, or remove') with a clear resource ('OmniFocus folders'), immediately distinguishing this tool from siblings like manage_tags or manage_perspectives. It enumerates all supported operations, leaving no ambiguity about its 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 provides clear context on when to use the tool (any folder operation) and clarifies the safety profile of each action ('list/get are read-only, add/edit mutate, remove permanently deletes'). It does not explicitly mention alternatives or exclusions, but the operation breakdown serves as implicit guidance for 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 mark destructiveHint=true. The description adds crucial context by specifying 'update rewrites rules in place and never creates or deletes a perspective' and 'list/get are read-only'. This tells the agent exactly what destructive behavior occurs and what does not, going beyond the annotation.

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 action verbs, no filler. Every clause adds value, making it both concise and structurally sound.

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 complex 7-parameter tool with nested rules, the description conveys high-level purpose, read-only vs destructive actions, and distinguishes perspectives from tags. It doesn't describe return values, but no output schema exists; the schema covers rule details. Missing explicit 'read first before update' but the schema's rules description handles it. A touch more could push to 5.

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 detailed parameter descriptions. The description adds little beyond the schema (e.g., 'Perspectives are saved views, not tags' is already in the schema). Baseline 3 applies due to full 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 opens with a specific verb+resource: 'List, inspect, and edit OmniFocus custom perspectives and their filter rules.' It explicitly distinguishes perspectives from tags ('Perspectives are saved views, not tags.'), separating it from the sibling tool manage_tags. This makes the tool's purpose unmistakable.

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: 'Use this to explain why a perspective shows what it shows, or to change its rules.' It also clarifies read-only vs mutating actions. However, it does not name alternative tools or explicit when-not-to-use scenarios, so it stops short of a 5.

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 set destructiveHint=true, but the description adds crucial nuance: list/search are read-only, add/edit mutate, and remove deletes the tag plus child tags while preserving tasks. This goes well beyond the binary annotation and gives the agent concrete understanding of what to expect for each action. The description is consistent with annotations and enriches them.

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 enumerates all operations, the second clarifies behavioral nuances (read-only vs. mutating vs. destructive with child tags). Every word earns its place, and the most important information is 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 complex 10-parameter mixed-operation tool, the description covers the key operational semantics and the destructive edge case (child tags removed, tasks kept). It does not detail per-action parameter combinations, but the schema already provides that. The absence of an output schema is a minor gap, since return values are not described, but overall the description is sufficient for an agent to use the tool safely.

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 each parameter already has a detailed description (e.g., 'Tag ID (edit/remove only)', 'Search text (required for search)'). The tool description does not add parameter-level meaning beyond this, so the schema shoulders the semantic load. 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?

The description opens with 'List, search, add, edit, or remove OmniFocus tags,' giving a specific verb for each operation and the resource (tags). This clearly distinguishes it from sibling tools like manage_folders or manage_perspectives, which target different OmniFocus entities.

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 when to use this tool: any tag management need falls here. It does not explicitly name alternatives or exclusion conditions, but the operation list ('list, search, add, edit, remove') makes the intended use clear. The conservative destructive marking also hints that read-only operations are safe, though no alternative tool is suggested.

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 significant context beyond annotations by explaining that despite the destructiveHint, list is read-only and remove can delete one or all notifications. This clarifies the conservatively marked destructive flag and outlines side effects for each operation, which is valuable for an AI agent.

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, front-loaded sentences. It states the tool's purpose first, then adds the key behavioral nuance about the destructive flag. 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?

Given the tool's complexity (7 parameters, 3 actions, mixed operations), the description adequately covers operation semantics and parameter mapping. It does not describe return values, but no output schema exists, and the absence is not critical for selecting the tool. Slightly more detail on invalid parameter combinations would push it higher.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces which actions use which parameters (e.g., 'remove deletes one or all notifications') but does not add detail beyond what each parameter description already provides. It is sufficient but not additive.

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 manages task notifications ('List, add, or remove task notifications'), using a specific verb and resource. It explicitly distinguishes three operations, and no sibling tool handles notifications, removing ambiguity.

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 the mixed-operation nature and how each action behaves (list read-only, add mutates, remove deletes), giving clear context for using the tool. It does not name alternative tools for notification management, but none exist among siblings, so context is sufficient.

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

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

The description adds value beyond annotations by disclosing batch validation and date verification processes. Annotations only indicate destructiveness; the description provides useful behavioral 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?

The description is two sentences, with the first sentence front-loading the core action and scope. No extraneous information is present.

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 and annotation coverage, the description provides sufficient context about batch processing and validation. However, it does not explain failure modes or idempotency, which are partially covered by annotations.

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 description adds no new meaning beyond the schema description for projectIds. It repeats the schema's information without additional clarification.

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 marks a set of active or on-hold projects as reviewed, using specific verbs and resources. It distinguishes itself from siblings like get_projects_due_for_review and add_project by specifying the action and 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 the tool should be used after user confirmation on a set of projects, but lacks explicit guidance on when not to use it or alternatives. It does not mention 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?

Annotations already indicate destructive and non-idempotent nature. The description adds 'move', confirming mutation, but does not detail what happens to the original location or any side effects. Some implied transparency but insufficient for complete understanding.

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 that front-loads the verb and object. No superfluous words, achieves maximum brevity while conveying essential purpose.

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 7 optional parameters and no output schema, the description lacks details on return values, default behavior when multiple target options are provided, and error handling (e.g., duplicate name errors only mentioned in schema). Adequate but incomplete.

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 baseline is 3. The description generalizes the destinations but adds no extra semantic detail about parameters beyond what the schema provides. Adequate but not enhanced.

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) and resource (task), and lists possible destinations (project, parent task, inbox). It effectively communicates the core purpose, though it does not explicitly differentiate from batch_move_tasks sibling.

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 like batch_move_tasks. The description does not mention prerequisites, exclusions, or context for choosing this over similar 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 declare readOnlyHint=true and destructiveHint=false. The description adds behavioral detail: images are returned as MCP image content when possible. This goes beyond annotations, though it does not cover non-image behavior or error handling.

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 wasted words. The purpose and a key behavioral detail are front-loaded. Every word 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?

No output schema, so the description should explain return values. It covers images but not other file types or potential failures. For a read operation with strong annotations, it is adequate but leaves 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 100%, so the schema already documents all 4 parameters. The description adds no extra meaning beyond referencing get_task_by_id, which is also in schema descriptions. Baseline of 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?

The description clearly states the verb 'Read' and the resource 'task attachment', and references get_task_by_id as the source. It is distinct from sibling tools, none of which read attachments.

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 via 'reported by get_task_by_id' but does not explicitly state when to use this tool vs alternatives, nor when not to use it. No sibling tool serves the same purpose, so guidance is minimal.

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 set destructiveHint=true. Description adds no behavioral context beyond 'remove', which matches. No extra disclosure of consequences, permissions, or irreversibility.

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?

Single sentence with no wasted words. Could be slightly more informative without harming conciseness.

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 destructive action, the description plus annotations and schema cover basic usage. However, lack of output schema or notes on success/failure leaves some 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 100%, so parameters are fully documented. Description does not add any additional meaning beyond what the schema provides (itemType enum, id/name fallback). Baseline score 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?

Description states 'Remove a task or project from OmniFocus' with a specific verb and resource. It clearly distinguishes from sibling tools like add_omnifocus_task or edit_item.

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 tool vs alternatives like batch_remove_items. No mention of prerequisites or 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?

Annotations already declare destructiveHint=true. The description adds value by listing the supported aspects (ICS rule strings, schedule type, etc.) and clarifying that the operation can set, update, or clear a rule, which goes beyond the annotation's binary destructiveness.

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-load the action and then succinctly enumerate supported capabilities. Every word 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 description covers the core function and supported fields, but lacks details on default behavior (e.g., what happens when clear is false), success/failure indicators, or the effect on existing rules. Given the 8 parameters and no output schema, more context would be beneficial.

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

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

Schema description coverage is 100%, so the baseline is 3. The description merely summarizes the parameter groups already documented in the schema, without adding new meaning or context.

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?

Clearly states the action 'Set, update, or clear the repeat rule on a task', which is a specific verb-resource combination. No sibling tool handles repetition rules, so it is well-distinguished.

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 setting repetition rules but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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