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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a useful behavioral consequence: unavailable features cannot be invoked, which sets the expectation that this tool reveals callable capability status. This complements the annotations without contradicting 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?

Two concise sentences with no filler. The first sentence front-loads the action and scope; the second sentence adds a practical implication. 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?

For a zero-parameter, read-only capability tool with an output schema already present, the description is complete. It tells the agent what to expect, warns that unavailable features cannot be invoked, and leaves return structure details to the output 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?

The tool has zero parameters, so the input schema places no burden on the description. The description correctly focuses on the output semantics: implementation and verification status of every operation family. This matches the 0-parameter baseline of 4.

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 ('Read') and names the exact resource ('implementation and verification status of every operation family'). It clearly differentiates this from the sibling tools by focusing on capability/availability rather than individual item operations or health checks.

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 this tool should be used before invoking operations, since unavailable features cannot be invoked. However, it does not explicitly state when to prefer this over things_health or things_request_status, nor does it name any alternatives 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 mark the tool as idempotent and non-destructive; the description adds valuable behavioral context by requiring a unique UUID requestId and disclosing the local write permission requirement, including that it is disabled by default. 'Native verified' also reassures the agent that no emulation or fallback is needed.

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 three short, purposeful sentences with no filler. The main action is front-loaded, followed by the key idempotency requirement and the permission prerequisite.

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 an output schema available and annotations covering idempotency and destructiveness, the description supplies the important operational context: supported kinds, unique requestId, and the local write permission requirement. It is sufficient for correct invocation; only minor details like how to enable the permission are omitted.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for kind ('to-do, project, area, or tag') and requestId ('unique UUID'), but it says nothing about the required title parameter or the optional notes parameter. This is only partial compensation for the missing schema descriptions.

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 clear verb and resource: 'Create a to-do, project, area, or tag.' It enumerates the exact object kinds the tool supports, which also distinguishes it from sibling tools like things_update_item, things_trash_item, and things_move_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 makes the intended use obvious ('Create...') and adds an important prerequisite: local write permission is required and disabled by default. It does not explicitly name alternatives or state when not to use this tool, but the creation-specific wording gives clear 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?

Beyond the readOnly/idempotent/destructive annotations, the description discloses several non-obvious behaviors: trash is excluded unless its list is explicitly requested, notes are omitted unless requested, results are bounded and not a snapshot, and a fresh fetch is needed before editing. This is strong added 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 four tight sentences with no filler. The primary purpose is front-loaded, and each subsequent sentence adds a distinct, useful caveat. 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?

Given the output schema exists and the annotations already establish the safety profile, the description supplies the critical behavioral caveats an agent needs: filterable dimensions, trash/note handling, bounded results, and the pre-edit fetch requirement. Nothing essential for correct invocation or interpretation is missing.

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

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

Schema coverage is 0%, so the description carries the burden of explaining parameters. It effectively maps to parameters: 'type' maps to kind, 'title or notes' to text, 'status' to status, 'built-in list' to list, and 'project/area parent' to parent. It even implies includeNotes. However, it leaves limit, offset, and enum nuances partially implicit, so it is helpful but not exhaustive.

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 ('Find') and resource ('items'), and enumerates the main search dimensions: type, text, status, list, and parent. This clearly distinguishes it from sibling tools like things_get_item, things_create_item, and things_update_item, which perform different 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?

The description makes the search/filter use case obvious and adds workflow guidance with 'Fetch an item before editing,' implying this tool is for discovery rather than mutation. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion 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, idempotentHint=true, and destructiveHint=false, so the safe-read behavior is covered. The description adds useful behavioral context beyond those annotations by disclosing that the response includes the revision, which is important for the editing workflow. No contradiction with annotations.

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

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

One tight sentence with no filler. The core action and resource are front-loaded, and the revision detail is appended efficiently without repeating schema or annotation 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 two-parameter read operation with strong safety annotations and an existing output schema, the description covers the essential workflow: fetch one item by kind and stable id and get its revision for editing. It is slightly short of a 5 because it does not mention not-found/error behavior, but that is a minor gap given the output schema and 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 description coverage is 0%, so the description needs to compensate. It does name both parameters ('kind' and 'stable ID') and adds the useful note that the id is stable. However, it does not elaborate on enum values or id format, though the schema itself provides detailed constraints for those.

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 a specific verb ('Read'), a specific resource ('one Things item'), and the lookup method ('by kind and stable ID'). The phrase 'one item' clearly separates it from sibling search/list tools like things_find_items, and the read action distinguishes it from mutation siblings like things_update_item or things_trash_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 phrase 'including its revision for safe editing' gives clear context: this tool should be used when the agent needs the current revision before performing an edit. It does not explicitly name alternatives or state exclusions, so it falls just 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context by specifying exactly which health dimensions are checked, including the separate Trash permission. There is no contradiction with the annotations.

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

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

The description is a single sentence that front-loads the action and target, with every clause contributing a distinct check. There is no filler or duplication of schema or annotation 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-parameter, read-only, idempotent health check with an output schema available, the description conveys the full scope of the tool. Nothing essential is missing for an agent to understand what this tool covers.

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

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

The tool has zero parameters and the input schema is empty, so there are no parameter semantics for the description to add. The baseline for a no-parameter tool applies.

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

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

The description uses the specific verb 'Check' and enumerates a concrete set of health aspects: connection, timezone, ordinary-write permission, and Trash permission. This makes its purpose distinct from siblings like things_find_items or things_trash_item, though it does not explicitly name an 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?

No guidance is given on when to use this tool instead of things_capabilities or things_request_status, and no prerequisites or exclusions are mentioned. The verb 'Check' implies a diagnostic health check, but the selection logic is left entirely to the agent.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by disclosing specific behaviors: requires the latest revision and write permission, moving projects can affect descendants, and what it does NOT do (reorder items, address headings, or restore Trash). No contradiction with annotations; it enriches them with concurrency, authorization, and side-effect detail.

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

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

Four dense sentences, each earning its place: the first fronts the core action and destinations, the next two state hard constraints, and the last covers requirements and negative scope. No fluff or repetition.

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 tool with 4 required params, nested oneOf destinations, and zero schema descriptions, the description fully specifies the move matrix (valid and invalid), side effects, prerequisites, and exclusions. Since an output schema exists, return-value coverage is not 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?

With schema description coverage at 0%, the description carries the burden and largely delivers: it explains the destination parameter's valid values (project, area, Inbox Today Anytime Someday, detach) and clarifies valid kind/destination combinations. It also gives expectedRevision meaning ('requires the latest revision'). Only requestId semantics are left to the schema/format, a minor gap.

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

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

States a specific verb ('Move') with the resource (to-do/project) and enumerates the valid moves: to-do to project/area/list, project to area, detaching a parent. This is concrete and semantically distinct from siblings like things_trash_item (trash), things_schedule_item (scheduling), and things_update_item (updates).

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

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

The description implies usage context through explicit constraints ('Projects support Today and Someday', 'Project Anytime and direct Logbook moves are unavailable'), which tells an agent what operations are possible. However, it never names alternative tools or states when-not-to-use this tool in favor of a sibling, leaving routing decisions to inference.

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

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

The description adds value beyond the annotations by clarifying that the check is against a 'local receipt,' not a remote system, and by warning that pending/unknown results should halt further writes. This is useful operational guidance that annotations alone do not convey, though it leaves the exact status vocabulary to the 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?

The description is a single, well-structured sentence that front-loads the core action and then provides the important conditional guidance. Every clause contributes meaningful information with no redundancy.

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

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

For a one-parameter, read-only, idempotent status-check tool with an output schema, the description covers the essential purpose, the key semantic of the parameter, and the critical retry guidance. Nothing necessary for correct invocation is missing.

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

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

With 0% schema description coverage, the description must compensate, and it does by explaining that requestId is a mutation request ID tied to a local receipt. This adds meaning beyond the raw UUID format in the schema, even though it does not detail where the ID comes from.

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 ('Check') and resource ('local receipt for a mutation request ID'), making the tool's purpose immediately clear. It is distinct from sibling tools because it is the only one about verifying the status of a previously issued mutation request rather than performing or querying domain 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?

The description gives clear when-to-use context: check the local receipt before further writes, especially when a request is pending or unknown. It also provides an explicit exclusion—do not automatically create a new ID as a retry—but it does not name alternative sibling tools or state when not to use this 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?

Annotations already declare readOnly=false, destructiveHint=true, and idempotentHint=true; the description adds useful behavioral context by specifying Mac-timezone interpretation, the need for the current revision, and the fact that reminders and repeating rules are not set. 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?

Three short sentences, front-loaded with the core operation, then preconditions, then behavioral limitations. Every sentence earns its place and there is no redundant or filler content.

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

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

Given the nested target object, rich annotations, and an output schema, the description covers the core operation, prerequisites, timezone, and non-goals. It is sufficient for correct invocation, though explicitly naming an alternative for reminders or repeating rules would make it more 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?

With 0% schema description coverage, the description compensates by mapping all core parameters to concepts: to-do/project maps to target.kind, current revision to expectedRevision, unique UUID to requestId, and explicit calendar date to date. It adds semantic value beyond the raw schema, though it does not detail every nested field.

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: 'Schedule a to-do or project on an explicit calendar date in the Mac timezone.' This clearly distinguishes the operation from siblings like move/trash, though it does not explicitly contrast it with things_update_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?

Provides prerequisites ('Requires its current revision and a unique UUID requestId') and a limitation ('Does not set reminders or repeating rules'), so an agent has context for when this is appropriate. However, it does not name an alternative tool or give an explicit when-not-to-use condition for scheduling versus updating.

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 the tool as destructive, but the description adds important behavioral nuance: the item is moved to Trash rather than permanently deleted, it includes checklists, and it does not empty Trash or delete projects/areas/tags. It also discloses the separate local Trash grant requirement, going well beyond the annotations.

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

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

The description is tight and front-loaded. The main action appears in the first sentence, followed by prerequisite and exclusion details—each sentence adds meaningful information without redundancy.

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

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

Given the three required parameters, the presence of an output schema, and strong annotations, the description is fully adequate. It covers what the tool does, what it affects, its prerequisites, and its non-effects, so an agent can 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 description coverage is 0%, so the description must compensate. It does: 'latest revision' maps to expectedRevision, 'unique request ID' maps to requestId, and 'one to-do... target' maps to target. It doesn't enumerate all nested target properties, but the schema's const on kind and id pattern fill that gap.

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

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

The description uses a specific verb and resource: 'Move one to-do... to Things Trash on the Mac.' It also clarifies scope with 'including any checklist it contains' and what it does not do ('Does not permanently delete, empty Trash, or delete projects, areas or tags'), which distinguishes it from sibling tools like things_move_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 gives clear preconditions: 'Read it and review the target first' and 'Requires the latest revision, a unique request ID, ordinary write permission, and the separate local Trash grant.' It does not explicitly name alternative tools or state when not to use this one, but the context is sufficiently clear.

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 annotations already marking this as destructive and idempotent, the description adds meaningful behavioral context: partial updates semantics ('Omitted fields stay unchanged'), the special null-clear behavior for deadlines, and the explicit limitation that deletion and arbitrary property editing are not supported. This is consistent with the annotations rather than contradicting 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?

Three concise sentences, front-loaded with the core purpose. Each sentence adds necessary information: what the tool does, how updates behave, and what it explicitly avoids. No wasted words or restatement of schema properties.

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 rich annotations and an output schema, the description covers the important behavioral nuances: revision tracking, requestId uniqueness, partial updates, null clearing, and the no-deletion boundary. The main gap is the incomplete statement of target kinds (area and tag are present in the schema but omitted from the description), plus no explicit mention of behavior on a stale revision, though this is not critical for basic invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the conceptual roles of requestId and expectedReversion ('unique UUID requestId', 'latest revision'), clarifies the changes object semantics ('Omitted fields stay unchanged; deadline null clears it'), and sets safety boundaries around target. It does not enumerate field names or value formats, but the schema provides those details.

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 identifies the tool as an update operation ('Edit supported fields, or complete/cancel/reopen a to-do or project') and distinguishes it from deletion tools by stating 'No deletion or arbitrary property editing.' However, it under-specifies the supported target kinds: the schema allows todo, project, area, and tag, while the description names only to-do or project for status changes, leaving area/tag update support 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?

The description provides operational guidance ('Use the latest revision and a unique UUID requestId', 'Omitted fields stay unchanged') and a boundary ('No deletion or arbitrary property editing'), but it does not explicitly name alternatives like things_trash_item or things_move_item for other operations. Usage timing is mostly implied by the purpose rather than stated as a clear when-to-use vs alternatives rule.

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