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

With no annotations, the description carries the full behavioral burden but says nothing beyond the mutation itself: it does not disclose whether duplicate names are allowed, whether the parent must already exist, what is returned (a folder ID is presumably needed for follow-up calls), or how failures surface. The important ambiguity-failure behavior exists only in the schema text.

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 filler or redundancy. Its brevity is efficient, though it edges toward under-specification rather than optimal density.

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 three-parameter creation tool with fully documented schema fields, the description is minimally sufficient to invoke correctly. However, with no output schema and no hint about the return value or error conditions, an agent cannot anticipate what comes back after a successful add.

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

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

Schema description coverage is 100%, and the property descriptions already explain parentFolderId vs parentFolderName, the root-level default, and the multi-match failure mode. The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Add a new folder') plus the target system (OmniFocus), so an agent knows exactly what it creates. It does not explicitly differentiate itself from near siblings like add_project or add_omnifocus_task, leaving the folder-vs-project distinction to inference.

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

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

There is no statement of when to use this tool versus add_project, add_omnifocus_task, or edit_item, and no prerequisites mentioned. The only usage-adjacent guidance (root-level default, nesting behavior) lives in the schema, not the 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?

No annotations are provided, so the description carries the full disclosure burden, yet it only adds a performance hint about batching. It says nothing about failure modes (e.g., unknown projectName/projectId), precedence when both projectId and projectName are supplied, whether it mutates existing data, or what is returned on success.

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 the core action front-loaded and the batching caveat immediately after. No filler and nothing buried.

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 13 parameters and a nested repetition object, the fully documented schema compensates for most of the description's brevity. However, for a write tool with no annotations and no output schema, the description still leaves the agent without guidance on conflict/precedence behavior and result 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 description coverage is 100%, including detailed nested docs for repetitionRule, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 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 states a specific verb and resource ('Add a SINGLE task to OmniFocus') and emphasizes the single-item scope, which immediately distinguishes it from the batch siblings. An agent can tell what it does without opening the schema.

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

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

It gives an explicit routing rule: use this for one task, use batch_add_items for 2+ tasks, with a concrete justification (9x faster, single API call). This is exactly the when/when-not/alternative structure the dimension rewards.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states that this is a mutating write, does not describe the return value, permissions, or failure behavior — the folderName failure mode is only mentioned in the schema, not the description.

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

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

Two short sentences, zero waste, and the scope constraint is front-loaded before the alternative pointer. Nothing could be removed without losing 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 10 parameters, full schema coverage, and no annotations or output schema, the description is just barely sufficient: the schema documents inputs but nothing tells the agent what the tool returns or how it behaves on failure.

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 ten parameters including folderName/folderId disambiguation are already documented. The description adds no parameter-level meaning, which is acceptable at full coverage but earns only 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?

States a specific verb and resource ('Add a SINGLE project to OmniFocus') and immediately distinguishes the single-item scope from the batch sibling. An agent can pick between add_project and batch_add_items without opening either schema.

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

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

Names the alternative (batch_add_items) and the exact condition that selects it (multiple projects). No other guidance such as folder prerequisites or what happens on duplicate names, but the primary routing decision is explicit.

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

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

No annotations exist, so the description carries the full behavioral burden. It adds a useful performance claim (9x faster) but says nothing about partial-failure semantics, atomicity, ordering, or what is returned — critical for a batch mutation tool. The only failure-behavior detail available lives in the schema's folderName description, not here.

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

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

Three short sentences with the preferred status and batch scope front-loaded. Nothing is redundant or padded.

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

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

There is no output schema or annotation coverage, so the description should at least indicate what a call returns (created IDs, per-item results) and how failures are reported. It omits both, leaving the agent to discover batch-result semantics empirically.

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%, including the tempId/parentTempId linking mechanism and per-field guidance, so baseline 3 applies. The description adds no parameter-level 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?

States a specific verb and resource ('Add multiple tasks/projects') and explicitly scopes it to batch operation in one call, which cleanly separates it from the single-item sibling add_omnifocus_task.

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

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

Gives an explicit decision threshold ('Always use this for 2+ items') and names the alternative (individual add_omnifocus_task calls), so an agent can choose between batch and single-item paths without inference.

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

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

No annotations are provided, so the description carries the full burden and delivers little: it asserts '12x faster' (an unverifiable performance claim) but says nothing about atomicity, whether a single bad edit aborts the whole batch, permission requirements, or what errors look like. For a bulk mutation tool this is a significant omission.

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

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

Three short sentences with the recommendation front-loaded, then the rationale, then the decision rule. No filler, nothing buried.

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 annotations and no output schema mean the description should explain what a batch call returns and how partial failures surface, but it is silent on both. The rich nested schema compensates for edit-field semantics, so the gap is narrow but real for a destructive bulk 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% and the single 'edits' array has per-field descriptions covering every edit kind, including edge cases like folder matching and empty-string date clearing. The description adds nothing about the array's structure, ordering, or size limits, so baseline 3 applies.

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

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

States a specific verb and resource plus scope: 'Edit multiple tasks/projects in ONE call.' The batching scope is exactly what distinguishes it from the sibling edit_item, so an agent can select it without opening the schema.

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

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

Explicitly routes the agent: 'Always use this for 2+ items' and names the alternative (individual edit_item calls) as the thing it replaces. It stops short of an explicit when-not (single-item edits) and gives no guidance on large batch sizes or partial-failure handling.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses batching semantics (one call replaces N calls), but says nothing about the result shape, whether tasks are grouped by project, or how the per-project limit interacts with aggregation – all material for a 27-parameter tool with no output schema.

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

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

Two sentences, zero waste, and the PREFERRED/preferred-selection cue is front-loaded ahead of the condition. Nothing here needs to be trimmed or reordered.

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 27-parameter, zero-required, no-output-schema read tool, the description nails routing but stops short of telling the agent what comes back – whether results are keyed by project, whether a missing project ID errors or is skipped, and how limit applies per project. Those gaps are only partly covered by the schema's per-field notes.

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

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

Schema description coverage is 100%, so every parameter including limit, sortBy and the date-window flags is already documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies rather than anything higher.

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

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

States a specific verb and resource ("Filter tasks") with a clear scope ("across multiple projects in ONE call"). It explicitly names the sibling it is not (filter_tasks) and the condition that separates them, so an agent can tell them apart without opening either schema.

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

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

"Always use this instead of multiple filter_tasks calls when querying 2+ projects" names the alternative and the triggering condition in one sentence. The only mild gap is that the single-project or single-task query case is left implicit, but the decision rule itself is unambiguous.

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

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

With no annotations, the description carries the full burden, and it does disclose the key side effect: next review dates are advanced. It omits the rest of the mutation profile — whether it is idempotent, what happens with unknown IDs, whether partial failures are reported, and what permissions or auth it needs.

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?

One sentence, front-loaded with verb and object, with the behavioral consequence in a tight parenthetical. Nothing wasted and nothing buried.

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 two-parameter batch mutation with no annotations and no output schema, the description covers purpose and effect but leaves return behavior and the ID-vs-name selection rule unexplained. Adequate, but an agent still has to guess at batch semantics.

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 adds nothing about the mutual exclusivity/priority of projectIds vs projectNames, which is the one ambiguity an agent could get wrong here.

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

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

States a specific verb+resource ("Mark multiple projects as reviewed") and adds the consequential effect ("advances their next review dates"), which lets an agent distinguish it from generic mutators like batch_edit_items or edit_item. It does not explicitly name siblings, so it stops short of a 5.

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

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

No when-to-use or when-not-to-use guidance. Nothing says to pair it with get_projects_for_review (the obvious read-side sibling) or explains why an agent would pick this over batch_edit_items for changing project state.

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

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

No annotations are provided, so the description carries the full behavioral burden for a destructive operation. It discloses performance ('9x faster') but says nothing about whether deletion is permanent, whether confirmation is required, or what happens if some items in the batch fail — critical for a removal tool.

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

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

Three short sentences, front-loaded with 'PREFERRED' so the routing signal lands first. Every sentence carries a distinct piece of information: preference, rationale, threshold.

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?

Routing and scope are complete for a batch-delete tool, but with no annotations and no output schema the description should say whether deletion is irreversible and how partial failures are reported. Those gaps matter more here than for a 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 coverage is 100%, so the nested item fields (id, name fallback, itemType enum) are already fully documented in the schema. The description adds no meaning beyond the structured data, which is the baseline case.

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

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

States a specific verb ('Remove'), resource ('tasks/projects'), and batch scope ('multiple ... in ONE call'). It plainly distinguishes itself from the sibling remove_item by contrast, so an agent can route without opening either schema.

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

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

Gives an explicit decision rule: use this for 2+ items, with remove_item as the implied single-item alternative, plus a justification (9x faster). Both the when and the when-not 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?

No annotations are provided, so the description carries the full disclosure burden. It implies a non-mutating preflight check but never states that it is read-only, side-effect free, or what it returns (no output schema exists). For a zero-parameter preflight call this is adequate but leaves the agent guessing about the response shape.

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 waste, with the purpose first and the actionable trigger second. Every sentence earns its place.

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

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

The tool is simple, but with no annotations and no output schema the description should say roughly what a successful or failed diagnosis yields (a status report? an error?). As written the agent knows when to call it but not what to expect back.

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

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

The tool takes no parameters and the description introduces none, so there is nothing to mis-specify. Baseline for a zero-parameter tool.

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

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

States a specific verb ('Check') and a concrete scope: OmniFocus connectivity, permissions, and server status. An agent can distinguish it from data-retrieval siblings like list_projects, though the description never contrasts it with the adjacent get_system_health or get_server_version, leaving some overlap ambiguous.

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?

'Run this first if experiencing issues' gives an explicit triggering condition, which is exactly what a diagnostic tool needs. It stops short of naming alternatives (get_server_version, get_system_health) or saying when not to bother running 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?

No annotations exist, so the description carries the full burden. It never warns that the default behavior (resetDates=true, clearCompleted=true) wipes all dates and resets every task to incomplete — a materially destructive default — nor does it mention permissions, side effects, or what happens when folderName is ambiguous.

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

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

Three short sentences, front-loaded with the core action, and no repetition of schema content. The middle sentence on templates is the weakest but still carries a use-case signal.

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

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

For a 10-parameter mutation tool with a nested object, no annotations, and no output schema, the description is thin. It omits the sourceProjectId/sourceProjectName fallback, the folderName ambiguity-failure behavior, and the date-reset defaults an agent must know before calling.

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 ten parameters including the nested shiftDates object are already fully documented in the schema. The description only echoes two of them ('date shifting', 'hierarchy preservation') without adding format or interaction detail such as shiftDates overriding resetDates.

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 first sentence gives a specific verb and resource — 'Create a copy of a project including all its tasks' — which clearly separates it from add_project or get_project_by_id. It stops short of naming any sibling explicitly, so the differentiation is implicit rather than stated.

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

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

'Useful for templates and recurring workflows' hints at a scenario but never states when to prefer this over add_project or batch_add_items, and gives no preconditions such as needing a source project identifier. Usage 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?

No annotations are provided, so the description carries the full behavioral burden; it discloses the performance trait (12x faster in batch) which is genuine added context. However, for a 28-parameter mutation tool it says nothing about failure behavior, partial application, idempotency, or what happens when the id/name matches nothing. Key mutation semantics live only in the schema, not the description.

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

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

Two short sentences, zero waste, with the scope constraint front-loaded ahead of the alternative. Nothing could be removed without losing routing 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?

The exhaustive schema compensates for most gaps, and there is no output schema to explain. Still, the description never mentions that itemType is required or that the target is identified by id or name, nor what the call returns or how it fails — gaps an agent must discover from the schema.

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

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

Schema description coverage is 100%, so every parameter including itemType, id-vs-name fallback, and the newFolderName collision behavior is already documented in the schema. The description adds no parameter guidance beyond scope, so the baseline 3 applies.

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

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

States a specific verb (Edit) and resource (a SINGLE task or project in OmniFocus), and explicitly bounds the scope with 'SINGLE'. It names the sibling tool it is not (batch_edit_items), so an agent can distinguish the two without opening either schema.

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

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

Provides an explicit routing rule: use this for one item, use batch_edit_items for 2+. The '12x faster' rationale makes the tradeoff concrete rather than arbitrary. No further inference is needed to pick between the two editing 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?

No annotations exist, so the description carries the full behavioral burden, yet it discloses none of the key semantics for a mutation: whether unspecified properties are left untouched (partial update), whether renaming affects tasks carrying the tag, what happens to child tags when a parent changes, or whether edits are reversible. Listing the editable fields is scope, not behavior; nothing here warns the agent about side effects of a write.

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

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

Two tight sentences with the operation and its field scope front-loaded, then the usage motivation. No filler, no restatement of the name.

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

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

Seven parameters with zero marked required and no output schema means the agent must infer that one of tagId/tagName is mandatory and that tagId/tagName and newParentTagId/newParentTagName are alternative pairs — the description says nothing about this, nor about what a successful edit returns. It is adequate for a simple mutation but leaves the identity requirement entirely to the schema.

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%, including the enum values and the 'empty string makes top-level' trick, so the baseline is 3. The description mirrors the same field list without adding syntax or constraints beyond it, and notably never mentions that an identifier (tagId or tagName) must be supplied.

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 ('Edit a tag's properties') and enumerates exactly which properties — rename, status, parent, allowsNextAction — so an agent knows this is a tag-only mutation, not a generic item edit. It stops short of explicitly contrasting with the very similar 'edit_item' sibling, which is the only thing separating it from a 5.

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

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

'Use to reactivate dropped tags or reorganize tag hierarchy' gives concrete, actionable contexts for selection rather than a generic 'use this to edit tags'. However it never states when NOT to use it (e.g. moving tasks between tags belongs to edit_item, bulk renaming to batch tools) and names no alternative.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only query, but says nothing about result volume, pagination/limit behavior, the default 100 cap, or the performance shortcut of countOnly — all left to the schema. It also doesn't clarify that omitting a project filter (or using perspective='all') can return tasks spanning projects despite the 'ONE project' framing.

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

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

Three short sentences, front-loaded with the scope constraint and the routing rule. No filler; every clause carries decision-relevant 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 39-parameter tool with no annotations and no output schema, the description is thin: 'and more' hides the parameter surface, and neither the return shape nor the countOnly fast path is explained. Coverage is adequate to route between siblings but not to call confidently without reading the schema.

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

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

Schema coverage is 100% and every one of the 39 parameters is described in-schema, so baseline is 3. The description only adds a generic summary ('status, dates, tags, search, and more') without surfacing high-value parameters like countOnly, untagged, exactTagMatch, or the tagId/tagFilter and projectId/projectFilter alternatives.

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

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

States a specific verb+resource ('Advanced task filtering') and immediately bounds scope to ONE project, then names the sibling for the multi-project case. An agent can distinguish it from batch_filter_tasks and search_tasks without opening a schema.

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

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

Explicitly names the alternative ('use batch_filter_tasks instead') with the triggering condition ('2+ projects') and a rationale ('single API call'). The enumeration of supported filter families (status, dates, tags, search) also tells the agent what this tool is good for.

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

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

No annotations are provided, so the description bears the full disclosure burden. It adds useful behavioral detail about the return output ('sorted list with counts and percentages'), but says nothing about permissions, result-size caps, or behavior when a date range is omitted.

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

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

Three tight sentences: purpose first, then return shape, then the routing rationale. Nothing is wasted and the 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?

With no output schema, the description correctly sums up the return value as a sorted list with counts and percentages, and the parameters are fully self-documented in the schema. Minor gaps remain around omitted date-range defaults and any limits, but an agent has enough to call this correctly.

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

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

Schema description coverage is 100% and all four parameters carry their own descriptions with defaults and format patterns. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (task completion counts) plus the exact grouping dimensions and date-range scope. It also names the sibling alternative (multiple filter_tasks calls) so an agent can tell this aggregation tool apart from the raw-listing siblings without opening a schema.

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

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

Explicitly frames the use case (analytics) and the alternative it beats (multiple filter_tasks calls), which gives clear routing context. No explicit 'when not to use' exclusions, but the situation that selects this tool is unambiguous.

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

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

No annotations are provided, so the description carries the full burden, and it omits the one non-obvious behavior: with ignoreFocus defaulting to true the call clears Focus mode, mutating application state. It does disclose that hierarchy display is supported, but says nothing about read-only nature, result volume defaults, or pagination.

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

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

Three short sentences, front-loaded with purpose, then the disambiguation, then a capability note. The 'etc.' after the examples is slightly loose but the overall size is appropriate for a 6-parameter tool with no annotations.

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?

There is no output schema and no annotations, so the description should say more about what comes back (flat vs. hierarchical shape, whether completed tasks are included by default) and about the Focus-mode side effect. It is adequate for tool selection but thin for invocation expectations.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the perspectiveName-vs-tag caveat and the limit/showHierarchy interaction. The description adds only the example perspective names, which is a minor supplement rather than new semantic depth.

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

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

States a specific verb and resource ('Get tasks from a specific OmniFocus custom perspective') and explicitly disambiguates the concept from tags, which is the most likely confusion given the sibling tool get_tasks_by_tag. An agent can route correctly without opening the schema.

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

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

Gives a concrete trigger: 'Use this when user refers to perspective names like Today, Daily Review, This Week'. It clearly marks the when-to-use case and rules out tags, but never names the alternative tool (list_custom_perspectives for resolving IDs) even though the schema references 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?

No annotations exist, so the description carries the full behavioral burden, yet it discloses almost nothing: no read-only confirmation, no note on result volume, ordering, or whether completed flagged tasks are included by default (that detail lives only in the schema). 'Get' implies a read but nothing more is characterized.

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 filler. The core purpose and the optional filtering capability both land immediately.

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 no-param-required read tool with full schema coverage this is minimally adequate, but it says nothing about the returned tasks' shape or the default hideCompleted behavior, and offers no navigation to the many filtering siblings that overlap with it.

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

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

Schema description coverage is 100%, so the parameters are already documented; baseline 3 applies. The description mentions optional project filtering, which loosely maps to projectId/projectFilter but doesn't clarify when to prefer one over the other.

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

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

States a specific verb+resource ('Get flagged tasks') plus the data source (OmniFocus), which is enough to separate it from siblings like get_inbox_tasks or get_forecast_tasks. It stops short of naming those siblings or stating scope explicitly.

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

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

There is no guidance on when to use this versus filter_tasks, search_tasks, or get_tasks_by_tag, all of which could plausibly return flagged items. 'Optional project filtering' hints at the use case but nothing says 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?

No annotations are provided, so the description carries the full behavioral burden. 'Get information' implies a read-only operation, but the description does not state whether a missing folder errors, what permissions are required, or what 'information' is returned. It adds little beyond a generic retrieval statement.

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?

It is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation.

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?

This is a simple lookup tool with fully documented parameters, so the description is mostly adequate. However, with zero required parameters and no output schema, it should clarify that one of folderId or folderName is needed and mention the ambiguity failure mode that the schema describes.

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 schema itself explains both folderId and the ambiguous folderName path behavior in detail. The description's phrase 'by ID or name' adds no meaning beyond what the schema already 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 clearly states a specific verb and resource: retrieving information about a folder. It also names the lookup keys, ID or name. It is clear enough to distinguish from creation tools like add_folder, though it does not explicitly differentiate itself from sibling retrieval tools such as get_project_by_id or get_task_by_id.

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 only the basic implied usage of retrieving a folder. It does not say when to use folderId versus folderName, what happens if neither is supplied, or how it relates to alternatives like list_projects. The schema carries the only real guidance about ambiguous names.

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

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

No annotations provided, so description carries burden. It mentions due/deferred tasks and date range but omits read-only nature, permissions, or result formatting. The name 'get' implies safe operation, but more detail would improve transparency.

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, clear sentence that conveys the essential purpose without wasted words. 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 tool with 3 parameters and no output schema, the description covers basic purpose but lacks details on return format, ordering, or pagination. Adequate but not comprehensive.

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 has 100% description coverage for all three parameters, so baseline is 3. The description adds no extra meaning beyond schema, e.g., does not explain 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 tool retrieves tasks from OmniFocus forecast perspective, specifying it includes due/deferred tasks in a date range. This distinguishes it from sibling tools like get_flagged_tasks or get_today_completed_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 explicit guidance on when to use this tool versus siblings. With many similar get tasks, the description should indicate scenarios for forecast perspective or mention alternatives.

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

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

With no annotations, the description carries the full burden. It only states the basic function and does not disclose behavioral traits like sorting, pagination, or scope of returned tasks. For a simple retrieval tool, more context would be helpful.

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, but it is too minimal. While concise, it could include more useful details without being verbose, striking a balance between brevity and informativeness.

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 (1 parameter, no output schema), the description is adequate but lacks elaboration on what the inbox perspective entails, which is useful for understanding its scope. Not fully 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?

Schema coverage is 100% for the single parameter, which already describes its purpose and default value. The description adds no additional semantics, meeting the baseline 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 tool gets tasks from the OmniFocus inbox perspective, which identifies the resource and action. However, it does not differentiate from siblings like get_flagged_tasks or get_forecast_tasks, leaving some 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?

No guidance is provided on when to use this tool versus alternatives, such as get_tasks_by_tag or get_custom_perspective_tasks. The agent receives no context 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?

No annotations are provided, so the description carries the full behavioral burden. It says only that the tool gets information and does not disclose behavior for missing projects, ambiguous project names, or precedence when both projectId and projectName are supplied.

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 wasted words. It states the resource and lookup keys immediately.

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

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

For a simple two-parameter lookup with full schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it does not say what project information is returned or how lookup ambiguity is handled.

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 both parameters are already documented in the schema, including that projectName is an alternative to projectId. The description mentions ID or name but adds no precedence or conflict-resolution semantics beyond what the schema provides.

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 clear verb and resource: 'Get information about a specific project.' It distinguishes a single-project lookup from broader project listing by specifying ID or name, though it does not explicitly name list_projects as the alternative.

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

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

Usage is implied: call this when you know a project ID or name and want that specific project. However, the description does not state when to prefer this over list_projects or get_projects_for_review, nor does it address what to do if both projectId and projectName are omitted.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the selection criterion based on next review date, but it does not describe return ordering, pagination behavior, or any permissions/rate-limit context beyond the schema-documented limit.

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 efficient sentence with the core selection criterion front-loaded. Every phrase earns its place and there is no redundant restatement of the tool name.

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

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

For a simple read/list tool with two optional, fully documented parameters and no output schema, the description gives the essential selection logic. It could mention ordering or what a returned project entry contains, but those gaps are minor.

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

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

Schema description coverage is 100%, so both optional parameters (limit and includeOnHold) are already documented in the input schema. The description adds no parameter-level meaning beyond the schema, which is acceptable at baseline 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 uses a clear verb and resource: getting projects due for review, and defines 'due' as next review date in the past or today. It is specific about the resource subset, though it does not explicitly name sibling alternatives such as list_projects or get_project_by_id.

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 use case by defining 'due for review,' but it gives no explicit guidance on when to choose this tool over list_projects, get_project_by_id, or batch_mark_reviewed. There are no stated prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the burden. 'Get ... version and build information' reasonably implies a read-only, side-effect-free call, but the description never says so explicitly, nor does it mention whether it contacts OmniFocus or works offline.

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 short sentence that leads with the verb and names the exact payload. Nothing wasted, nothing buried.

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, no-output-schema metadata getter, the description gives enough to call it correctly. It would be complete at 5 if it clarified the read-only nature or distinguished it from the other diagnostic siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies, and the description correctly adds no noise about inputs.

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

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

States a specific verb and resource: 'Get OmniFocus MCP server version and build information.' An agent knows exactly what comes back. It does not distinguish itself from the near-neighbor diagnostics siblings diagnose_connection and get_system_health, which keeps it off a 5.

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

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

Usage is only implied by the resource name — an agent infers this is for checking server version/build. There is no explicit statement of when to call this versus diagnose_connection or get_system_health, which overlap in the 'is the server OK' space.

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

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

With no annotations, the description carries the full burden and does disclose the return shape, including the health indicator semantics (🟢/🟡/🔴) and that percentages are included. It omits cost/latency notes and aggregation window details, but for a zero-parameter read-only aggregate this is substantially informative.

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

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

Three sentences, front-loaded with the headline behavior, then the return contents, then the comparative advantage. No filler or restatement of the name.

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

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

No output schema exists, but the description compensates by enumerating the metric categories and indicator format an agent will receive. Combined with zero parameters, an agent has everything needed to decide to call it and interpret the result.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-param tool applies. The description correctly implies no filtering or scoping input is accepted.

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?

Opens with a specific verb+resource ("Get all OmniFocus health metrics in a single call") and enumerates exactly what is returned: inbox counts, projects by status, tasks by status, tags, flagged/untagged tasks. It also differentiates itself from the many list_/filter_ siblings by framing itself as the aggregate dashboard call.

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

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

Gives a clear context for use ("for dashboards") and names the alternative it replaces ("multiple filter_tasks calls"). It stops short of explicit when-not guidance — e.g. it doesn't say to prefer the specific list_* tools when only one metric is needed — but the routing signal is strong.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't clarify aspects like authentication needs, error handling (e.g., what happens if the task doesn't exist), rate limits, or response format. For a tool with no annotation coverage, this is a significant gap in transparency.

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, efficient sentence that front-loads the core purpose ('Get information about a specific task') and adds necessary detail ('by ID or name'). There is no wasted verbiage or redundancy, making it highly concise 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?

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves task information. It doesn't explain what information is returned (e.g., task details, status, metadata), potential errors, or how to handle the 'ID or name' choice. For a read operation with no structured output documentation, this leaves critical gaps for the agent.

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 coverage is 100%, with clear descriptions for both parameters ('taskId' and 'taskName'), so the schema does the heavy lifting. The description adds marginal value by noting that 'taskName' is an 'alternative to taskId', but doesn't provide additional semantics like format examples or usage constraints beyond what's in the schema. This meets 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 clearly states the verb ('Get information') and resource ('specific task'), making the purpose understandable. It specifies retrieval by 'ID or name', which adds useful detail. However, it doesn't distinguish this tool from potential sibling tools that might also retrieve tasks (e.g., 'get_tasks_by_tag' or 'filter_tasks'), so it doesn't reach the highest 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_tasks_by_tag' or 'filter_tasks', nor does it specify prerequisites or exclusions (e.g., whether it works for all tasks or only certain types). This leaves the agent with minimal context 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?

No annotations are provided, so the description carries the disclosure burden; 'Get' implies a safe read, but nothing states permissions, ordering of results, or how tag matching is resolved beyond the schema's parameter defaults. It does add real semantic context by defining what a tag is and that tags attach to individual tasks, which is beyond structured fields, but return shape and behavior with large tag sets are left to the schema's 'limit' note.

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

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

Three short, front-loaded sentences with zero filler: purpose first, exclusion second, definition third. Nothing repeats the schema or could be cut without losing information.

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

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

For a zero-required-parameter read tool with full schema coverage and no output schema, the description covers purpose, scope, and the key disambiguation. It lacks guidance on choosing tagId vs tagName and notes on result ordering, but those are largely covered by the schema descriptions.

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

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

Schema description coverage is 100%, so every parameter (tagId vs tagName, exactMatch, tagMatchMode, hideCompleted, includeDropped, limit) is already documented in the schema. The description only contributes tag examples (@home, @work, @urgent), which is marginal added value, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get tasks filtered by OmniFocus tags') and explicitly distinguishes tags from custom perspectives, which is exactly the confusion an agent could have given the sibling get_custom_perspective_tasks. The definitional sentence 'Tags are labels assigned to individual tasks' removes ambiguity about the filter target.

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

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

Gives a clear when-to-use rule ('tag-based filtering') and a clear when-not rule ('NOT for custom perspective names'), which preempts a common misfire. It stops short of naming the alternative tool (get_custom_perspective_tasks) or contrasting with filter_tasks/search_tasks, so the routing is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only query but never states the timezone/day boundary that defines 'today', the ordering of results, whether recurring or completed subtasks are included, or what happens past the 20-item default cap — all material for a time-scoped completion query.

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?

Very short and front-loaded, which is good, but the second clause 'view today's accomplishments' merely rephrases the first and earns no place. That space would have been better spent on the day-boundary or ordering behavior.

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?

A simple one-optional-param read tool with no output schema, so the bar is modest. Still, the definition of 'today' (timezone/rollover) and result ordering are gaps an agent would want before relying on the output.

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

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

Schema description coverage is 100% for the single 'limit' parameter (default 20, max 100), so the schema does the work and the description adds nothing about it. Baseline 3 is appropriate; the description neither compensates nor detracts.

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

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

States a specific verb and a well-scoped resource: tasks completed today. The 'today' qualifier distinguishes it from the generic filter_tasks/search_tasks siblings, though the description never names those alternatives to make the distinction explicit. An agent can still grasp the purpose without opening the schema.

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

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

No guidance on when to use this rather than filter_tasks, search_tasks, or get_completion_stats, which are the obvious overlapping siblings. The second clause 'view today's accomplishments' is a restatement, not usage direction, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the listing action but does not explicitly indicate that it is a read-only operation with no side effects, nor does it mention any performance or pagination characteristics.

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 of 9 words, starting with a verb. It is concise and contains no extraneous 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 simple list tool with no output schema, the description is adequate but incomplete; it does not specify that the output is an array of perspective names or objects. The parameter hint at output format partially compensates.

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%; the schema already documents the 'format' parameter with enum values and a default. The tool description adds no extra parameter information, 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 a specific verb 'List' and resource 'all custom perspectives' with context 'in OmniFocus', clearly distinguishing this tool from siblings like 'get_custom_perspective_tasks' (which retrieves tasks within a perspective) and 'list_tags' (which lists tags).

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, such as noting that 'get_custom_perspective_tasks' should be used to fetch tasks within a perspective. The usage context is implied but not explicitly compared to siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies read-only, but nothing is said about default filtering to active projects, result truncation at the limit, or the failure mode of ambiguous folder names — all behaviors an agent needs to interpret the response correctly.

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 sentence with both clauses doing work: the first establishes the operation and filters, the second establishes the discovery/ID purpose. Front-loaded and zero waste.

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

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

For a five-parameter, zero-required list tool with no output schema and no annotations, the description is minimally adequate. It omits that results default to active-only and how many come back by default, which materially affects how an agent interprets an empty or partial list.

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%, including defaults and the folderName ambiguity/failure behavior, so the schema does the heavy lifting. The description only restates that folder and status filtering exist, adding no semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('List projects') and adds the distinguishing scope ('optional folder and status filtering'), plus the purpose of ID discovery. It is clearly separable from get_project_by_id and get_projects_for_review, though it never names a sibling explicitly.

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

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

'The targeted way to discover projects and their IDs' implies the use case (discovery/lookup) but gives no explicit when-not conditions or named alternatives. An agent must infer that get_project_by_id is for a single known project and get_projects_for_review for review workflows.

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

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

With no annotations, the description carries the full burden; 'List' implies a safe read, and it discloses that hierarchy is returned. However, saying it lists tags 'with task counts' overstates the default behavior, since showTaskCounts defaults to false and is a slower path per the schema — a minor inaccuracy that could mislead an agent about cost.

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 filler; every phrase (tags, counts, hierarchy) adds signal.

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

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

For a simple two-optional-boolean read tool with full schema coverage and no output schema, the description conveys what the list contains. The only real gap is the tension between 'with task counts' and the default-off showTaskCounts flag, which an agent should know about.

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 both booleans (includeDropped, showTaskCounts) are already fully documented with defaults. The description adds no parameter detail and does not clarify dropped-tag inclusion or the performance tradeoff, so baseline 3 applies.

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

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

A specific verb (List) plus resource (tags) and scope (defined in OmniFocus), and it notes the payload includes task counts and hierarchy. It is distinguishable from edit_tag and get_tasks_by_tag by the word 'List' and 'defined in', but it never explicitly names a sibling it contrasts with.

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 no when-to-use or when-not guidance and does not mention alternatives such as get_tasks_by_tag (which returns tasks for a tag, not the tag catalog). The agent must infer that this is a discovery/lookup tool.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about what removal actually does — whether the item goes to a trash/recoverable state or is permanently destroyed, whether confirmation exists, or what happens if the id/name matches nothing. It only conveys routing and speed, which are usage guidance rather than behavioral disclosure of a destructive mutation.

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 waste, with the cardinality constraint front-loaded and the alternative plus its rationale in the second sentence. Every clause earns its place.

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

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

For a 3-parameter destructive tool with no annotations and no output schema, the description covers routing well but omits the consequences of the operation (recoverability, failure modes, return value). An agent still lacks enough to predict what happens after a successful or unsuccessful call.

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 id, name fallback logic, and the task/project enum are already fully documented in the schema. The description adds no parameter-level meaning (e.g., precedence between id and name, or error behavior), so the baseline 3 applies.

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

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

States a specific verb ('Remove') and resource ('a SINGLE task or project') with explicit cardinality scope, and names the sibling it is not (batch_remove_items). An agent can distinguish it from the batch sibling without opening either schema.

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

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

Gives an explicit when-to-use-this vs when-to-use-the-alternative rule ('For removing 2+ items, use batch_remove_items instead') and even quantifies why (9x faster). Nothing is left to inference about tool 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?

No annotations are provided, so the description carries behavioral burden. It usefully discloses that matching spans both names and notes and enumerates the supported match modes, but says nothing about result ordering, pagination behavior, or how the default limit of 50 interacts with large result sets. Adequate but with real gaps for a no-annotation tool.

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

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

Three short sentences with zero filler, purpose front-loaded followed by sibling differentiation and supported modes. Every sentence earns its place.

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

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

For a 7-parameter search tool with no output schema, the description covers purpose, text scope, and match modes, and the schema fills in filtering and limit details. Minor gaps remain around result ordering and pagination, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all seven parameters including projectId, projectName, and includeCompleted are already documented in the schema. The description repeats the match modes verbatim rather than adding semantics like default behavior or interaction with searchIn, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Full-text search across task names and notes') with clear scope, and distinguishes itself from the sibling filter_tasks by name. An agent can immediately tell what this tool does and when it differs from the filter family.

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?

Explicitly frames itself as 'Simpler than filter_tasks for finding tasks by text,' which gives clear positive guidance for choosing this tool. However, it doesn't state the inverse condition — when filter_tasks is the better choice — so the routing is only half-specified.

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