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

No annotations, so the description carries the behavioral burden. It discloses bulk mutation and a 403 gating condition for some accounts, but omits atomicity/partial-failure behavior, maximum batch size, and exact permission requirements.

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

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

Two sentences, front-loaded with the operations and followed by a useful caveat. Every sentence earns its place with no redundancy.

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

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

No output schema and no annotations. For a batch mutation tool, the description should ideally explain response shape, partial success handling, and limits; it covers operations and gating but leaves these important gaps.

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

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

Schema description coverage is 100%, with add, update, and delete documented, so baseline 3. The description adds no syntax or item-shape detail beyond what the schema already 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?

Names three operations (creates, updates, deletes), the resource (tasks), and the batch scope (many tasks in one request), clearly distinguishing it from the single-task CRUD siblings.

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?

Implies use when handling multiple tasks at once, but does not explicitly say to prefer it over create_task/update_task/delete_task for single records. The 403 gating note adds a usage constraint but no alternatives 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?

No annotations are provided, so the description carries full behavioral burden. It states the resulting status code (status=2), but does not disclose whether the action is reversible, what permissions are required, what side effects occur, or how errors are handled for a mutation operation.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It communicates the core effect efficiently without unnecessary elaboration.

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 mutation with full schema coverage, the description is minimally sufficient to invoke the tool correctly. However, the absence of annotations means it should provide more behavioral context about side effects, reversibility, and error conditions, which it does not.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('Task id' and 'Project id, or "inbox"'). The description adds no additional meaning or syntax beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ('Marks a task as completed') and includes the resulting status code, which is enough to distinguish it from most sibling tools. However, it does not explicitly differentiate itself from similar siblings like update_task or uncomplete_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?

There is no guidance on when to use this tool versus alternatives such as update_task or uncomplete_task. The intended context is implied by the name, but no explicit when-to-use or when-not-to-use conditions are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a critical auth constraint ('API-token mode only') and that the operation creates a record, but it does not describe side effects, required permissions beyond token mode, idempotency, or failure behavior.

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

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

The description is two short, front-loaded sentences with no filler. The primary purpose is stated first, followed immediately by the key environment constraint.

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 create tool with a freeform nested body, no annotations, and no output schema, the description is too thin. It does not tell the agent what fields to supply, what the created record includes, or how to interpret the response, leaving significant gaps for correct invocation.

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

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

Schema description coverage is reported at 100%, so the baseline is 3. However, the single body parameter is a freeform object with no defined properties, and the description adds no field-level guidance beyond saying it is a focus (pomodoro) record.

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: 'Creates a focus (pomodoro) record.' This clearly distinguishes it from the sibling list_focus tool, which lists rather than creates records. It does not explicitly name or compare against any sibling, so it falls just short of the top 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 phrase 'API-token mode only' is an important precondition, but it is not guidance on when to use this tool versus alternatives. There is no mention of when a focus record should be created, what prerequisites exist, or which related tools to consider.

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 only implies a mutation via 'Creates'. It does not disclose permission requirements, side effects, idempotency, or what happens to the project on failure.

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 single sentence is front-loaded and has zero waste, but its brevity reflects under-specification rather than effective conciseness. It is not padded, but it also does very little work.

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

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

For a mutation tool with four parameters, no annotations, and no output schema, the description is too thin. It omits required-field expectations (only 'name' is required), default behavior for kind/viewMode, and any behavioral context an agent would need.

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

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

Schema description coverage is 100%, with all four parameters (kind, name, color, viewMode) documented in the schema, including enum values. The description adds nothing beyond the schema, 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?

States a specific verb and resource (creates a project), and the parenthetical clarifies that a project is a list in this app. However, it offers no differentiation from siblings like create_task or list_projects beyond the noun, and the purpose is essentially a restatement of the tool name.

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 tool versus alternatives such as create_task, list_projects, or update_project, and no prerequisites or context are given. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden, yet it only confirms that a creation occurs. It omits permissions, side effects (notifications, recurrence, reminders), default values like projectId "inbox", and whether the new task is returned, which is significant for a 15-parameter mutation tool.

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

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

The single sentence is front-loaded and free of waste, but it is undersized for a tool with 15 parameters. Concision here comes at the cost of missing structural detail rather than being appropriately sized.

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

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

For a mutation tool with 15 parameters, no annotations, and no output schema, one sentence is far from complete. It does not explain required fields beyond their names or what the caller receives, leaving the agent to rely solely on 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 priorities, recurrence, reminders, and nesting via parentId is already documented in the schema. The description adds no parameter meaning beyond that baseline, which is acceptable given the high 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?

"Creates a task in a project" states a specific verb and resource, so an agent can tell this creates a task rather than lists or updates one. It does not differentiate from siblings like batch_tasks or create_project, but the core purpose is unambiguous.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as batch_tasks for multiple tasks or update_task for existing ones. The agent must infer the context entirely.

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

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

With no annotations provided, the description carries the full burden, and it does disclose the two highest-value behavioral facts: the operation is destructive and not reversible. However, it omits critical operational context such as whether contained tasks are also deleted or trashed, whether confirmation is required, and what happens on failure for a non-existent project id.

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

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

Two short sentences with zero filler, and the destructive warning is front-loaded immediately after the purpose statement. 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 one-parameter delete tool with full schema coverage and no output schema, the description covers the essential safety fact but leaves the main ambiguity unresolved: whether deleting a project cascades to its tasks/columns. An agent deciding whether to call this would benefit from knowing the blast radius, which is not stated.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents projectId. The description adds no format, source, or lookup detail (e.g., where to obtain the id) beyond the schema, 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 ('Deletes a project'), which is unambiguous and clearly distinct from the other delete siblings (delete_task, delete_tag) by resource. It does not, however, explicitly differentiate itself from those siblings or describe scope of deletion, 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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or required permissions, and no suggested precursor such as verifying the project via get_project. The only advisory element is the destructive/irreversible warning, which is a caution rather than usage direction.

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

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

With no annotations, the description carries the full behavioral burden. It says nothing about irreversibility, whether the delete is permanent or trashable, permission requirements, or what happens to tasks already tagged with it. 'Web mode only' is the sole behavioral detail offered.

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

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

Two terse sentences, front-loaded with the action and followed by the environment constraint. No waste, though it is so short that brevity shades into under-specification for a destructive 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?

For a destructive, annotation-less tool with no output schema, the description is too thin: it omits reversibility, side effects on tagged items, and permission needs. The schema covers the input, but the behavioral envelope an agent needs before deleting data is absent.

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

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

Schema coverage is 100% and the single 'name' parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no value about the name parameter (e.g., exact-match vs case-insensitive lookup), but nothing is missing from structured data.

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 ('Deletes a tag'), which is unambiguous and distinct from siblings like rename_tag, merge_tags, and list_tags. It lacks any sibling-differentiating conditional (e.g., when to delete vs merge), so it falls short of a 5.

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

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

'Web mode only' is a real usage constraint that tells the agent this tool is unavailable in other modes, which is more than nothing. However, it gives no guidance on when deletion is the correct action versus merge_tags or rename_tag, and no preconditions or warnings.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the important trait that deletion is soft by default (moves to trash) and only permanent when opted in, plus a precondition on the permanent path. It omits permission requirements, effects on subtasks/dependencies, and how the permanent path fails if the task isn't trashed.

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 compact sentences, front-loading the default behavior and then the opt-in exception. Every clause carries information; nothing is redundant with the name or schema.

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

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

For a mutation tool with no annotations and no output schema, the description covers default vs permanent behavior and the key precondition. It is nearly complete but leaves out recoverability (restore_task), permission needs, and any cascading effects on related entities.

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 baseline is 3, but the description adds meaning beyond the schema: the schema only says forever means 'permanently delete instead of moving to trash', while the description adds the non-obvious constraint that the task must already be trashed to use it.

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

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

States a specific verb and resource ('Deletes a task') and the resource noun cleanly separates it from siblings like delete_project, delete_tag, and delete_column. The added trash-vs-permanent distinction further sharpens what the operation actually does.

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

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

The description gives the condition that selects the permanent variant ('set forever: true') and a precondition ('must already be trashed'), which is clear usage context. It stops short of naming alternatives such as restore_task for undoing a soft delete, so it is not a full when/when-not routing statement.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the returned fields differ by auth mode (web vs API-token), which is a genuine, non-obvious trait. However, it omits whether the call is read-only, what happens on unauthenticated/failed calls, and any permission requirements.

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 tightly-scoped sentences with the core purpose front-loaded and the mode-dependent detail following. No filler 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?

No output schema exists, so the description must describe returns, and it does so for both auth modes (id, inbox id, plan, registration info; time zone preference). It is nearly complete for a no-arg read tool, with only the read-only nature left implicit.

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 clarify and the baseline of 4 applies. No parameter information is needed or missing.

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

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

States a specific verb and resource ("Gets the signed-in user's profile") that is unambiguous and clearly distinct from siblings like get_preferences or get_task. An agent immediately knows this retrieves the authenticated user's own identity data.

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 by the name and first sentence, but there is no explicit when-to-use guidance or named alternative (e.g., get_preferences, which is the nearest sibling and could be confused with user profile). The web-vs-API-token framing hints at context but does not instruct 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. 'Gets' implies a read, and 'Web mode only' is a useful environment constraint, but nothing is said about permissions, whether the call is safe/idempotent, or what the response contains. Minimal disclosure for an annotation-free 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?

A single tight sentence with the core purpose front-loaded and the mode constraint appended. No wasted words, though the parenthetical examples are slightly loose.

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 parameters, no output schema, and no annotations, the description is the only source of information, and it gives only a high-level summary. For a simple read tool this is close to adequate, but the agent cannot know the structure or scope of what 'preferences' returns.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no arguments are needed; there is nothing further to document.

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 ('Gets user preferences') and gives examples of what is included (matrix rules, quick-add). It does not need to distinguish from siblings since no other tool reads preferences, but it also doesn't enumerate the full contents due to the vague 'etc.'

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?

'Web mode only' is a real usage constraint telling the agent when the tool is callable, which is more than most getters offer. However, there is no guidance on when to reach for this versus reading preferences through other means, and no exclusions beyond the mode restriction.

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 does not state what happens for an unknown id (error vs null), the return shape, or any permission requirements. For a lookup tool with zero annotation coverage this is a notable gap.

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 wasted words. It is efficient, though the minimalism borders on under-specification rather than tight conciseness.

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

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

For a simple single-record getter with one fully documented parameter, the description is adequate. The absence of an output schema means the return value is unexplained, but the tool is simple enough that this is a minor gap.

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

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

Schema description coverage is 100% and the single projectId parameter is documented in the schema. The description's 'by id' adds no format or source detail beyond what the schema already conveys, 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 (gets), resource (project), and scope (single, by id). This clearly distinguishes it from list_projects without naming it explicitly. It stops short of the 5 reserved for explicit sibling differentiation.

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

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

The phrase 'a single project by id' implies you already have an id and want one record, contrasting implicitly with list_projects. No explicit when-to-use, prerequisites, or named alternatives 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 carries the full behavioral burden. It discloses the payload contents (tasks and columns), but says nothing about authentication, behavior when the projectId is invalid, how deep the expansion goes, or whether tasks/columns are full objects or summaries.

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 with the verb front-loaded and zero filler. It is appropriately sized for a one-parameter getter, though it is terse enough to feel under-specified rather than efficiently concise.

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 a single required parameter and no output schema, the description is close to sufficient, and it usefully hints at the return shape (project plus tasks and columns). It is still missing any failure/edge behavior for an expansion-style read, leaving a modest gap.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents projectId. The description adds no format, source, or constraint detail for it. Baseline 3 applies when the schema does the heavy lifting.

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 ('Gets a project') and adds the payload scope ('with its tasks and columns'), which distinguishes it from the bare get_project sibling by implication. It never names get_project, list_tasks, or list_columns explicitly, so the differentiation is inferred 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?

No when-to-use guidance is given. The description does not say to prefer this over calling get_project plus list_tasks plus list_columns, nor when a lightweight get_project would suffice. The agent must infer the use case from the name alone.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Gets' implies a read operation but does not mention permissions, error behavior for missing tasks, or the special 'inbox' project value.

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

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

The single sentence is brief and front-loaded with the core action. It is appropriately compact for a simple getter, though the wording is so terse that it slightly underspecifies the required identifiers.

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 retrieval tool, the description still omits that projectId is required and does not explain error behavior when a task is not found. With no annotations and no output schema, more context is needed to call it correctly in edge cases.

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

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

Schema description coverage is 100%, so the schema already documents both taskId and projectId. The description only says 'by id' and does not clarify the required projectId or the 'inbox' option, adding little 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 ('Gets a single task'), distinguishing it from list_tasks and search_tasks. However, 'by id' only accounts for taskId even though projectId is also required, so the scope is slightly imprecise.

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 tool versus alternatives like list_tasks, search_tasks, or get_project. It also omits prerequisites such as whether a project context is required.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one genuine constraint ("Web mode only") and implies a read-only listing, but says nothing about authentication requirements, pagination, or what happens in non-web contexts beyond the exclusion itself.

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

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

Two sentences, no filler, with the core purpose front-loaded and the platform constraint second. 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 list tool this is nearly sufficient: purpose, scope, and the web-mode constraint are all present. The only omission is any hint about the shape of the returned account list, which no output schema supplies.

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 the baseline is 4; there is nothing about parameter meaning the description could add or omit.

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 ("Lists connected third-party calendar accounts"), which is more precise than a bare "list accounts." It never names the adjacent siblings (list_calendar_subscriptions, list_calendar_events) whose scopes an agent must distinguish it from.

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 by the name and the "Web mode only" qualifier tells the agent when the tool is callable, but there is no explicit when-to-use or when-not-to-use guidance versus list_calendar_subscriptions or list_calendar_events.

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 whole burden. It does contribute one real behavioral constraint (web mode only) and the verb "lists" implies a non-mutating read, but it says nothing about the time window returned, pagination, or ordering, which matters for an events listing.

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, purpose first, constraint second, with no filler. Every clause carries information.

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

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

For a parameterless read tool with no output schema and no annotations, the definition is roughly adequate but leaves open what event set is returned (all connected calendars? what date range?) and what the results look like. A brief note on scope or the default range would close the main gap.

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

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

The tool takes zero parameters, so there is nothing for the schema to describe and no semantic gap for the description to fill; baseline 4 applies. The description does not invent parameter behavior that does not exist.

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: "Lists events bound from connected calendars." It is distinguishable from siblings like list_calendar_accounts and list_calendar_subscriptions by returning events rather than accounts/subscriptions, though it never names those siblings 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?

"Web mode only" tells the agent where the tool is available, but not when to choose it over list_calendar_accounts or list_calendar_subscriptions, nor what prerequisites (e.g., a connected calendar) must hold. No alternatives 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?

With no annotations, the description carries the full burden. It discloses one real behavioral trait — the web-mode-only restriction — and "Lists" implies a non-mutating read, but it says nothing about pagination, ordering, result size, or auth. For a zero-parameter tool this is thin but not empty.

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

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

Two short sentences with the resource named first and the mode constraint immediately after. No filler, no restatement of the title, nothing to trim.

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

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

For a trivial zero-param list tool this is minimally adequate, but with no output schema and no annotations an agent still does not know what a "calendar subscription" object contains or whether results are paged. The web-only note partially offsets this but does not close the gap.

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

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

The tool takes no parameters, so per the baseline rule the schema does the heavy lifting and no parameter explanation is required. There is simply nothing for the description to clarify 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?

The description states a specific verb and resource ("Lists calendar subscriptions"), which cleanly separates it from siblings such as list_calendar_accounts and list_calendar_events. It does not explicitly call out the differentiation, but the resource is specific enough that an agent can route to it without 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?

"Web mode only" is a genuine eligibility constraint that tells the agent when this tool is callable, which is more than no guidance. However, it names no alternatives and gives no conditions for choosing between this and the other list_* siblings, leaving usage largely 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 exist, so the description carries the full burden. 'Lists' implies a safe read, but the description does not state read-only behavior, pagination, ordering, or return shape. For a trivial list tool the gap is small but real.

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 zero waste; the scoping qualifier is appended compactly rather than 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 one-parameter list tool with no output schema, the description plus schema fully cover what an agent needs to invoke it. The undefined term 'web mode' is the only minor gap.

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

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

Schema description coverage is 100%, so the schema already documents that omitting projectId returns all columns. The description's parenthetical merely restates that, adding no syntax or format detail beyond the schema — 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 ('Lists') and resource ('kanban columns') plus the scoping condition (per-project vs. all in web mode). No sibling tool covers columns, so there is nothing to disambiguate against, but the operation is immediately clear.

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 parenthetical implies when to omit projectId ('all columns in web mode'), giving implicit branching guidance. There is no explicit statement of when to use this versus other list tools, but the single-parameter scope is narrow enough that little inference is needed.

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 completion filter and project scoping, but says nothing about ordering, default result limits, pagination, or timezone handling for the date range.

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 resource and scope are stated immediately and nothing is wasted.

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

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

For a five-parameter read-only list tool with no annotations and no output schema, the description covers the core scope but omits result-shaping behavior (limit interaction, ordering, date-range semantics) that an agent may need 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 the schema already documents all five parameters including formats, defaults, and the inbox sentinel. The description's 'one project or across all projects' merely restates the projectId/allProjects relationship, adding no syntax or edge-case detail 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+resource ('Lists completed tasks') with scope qualifiers (date range, one project or all). The 'completed' filter implicitly distinguishes it from list_tasks, but no sibling is named explicitly, 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?

The scope (date range, project vs all projects) implies when the tool applies, but there is no explicit when-to-use, when-not-to-use, or routing statement versus list_tasks/search_tasks. Guidance is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether results are paginated, what fields a countdown contains, whether the call is read-only, or what the two "modes" imply for output; "Works in both modes" is an unexplained hint rather than disclosed behavior.

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

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

The definition is short and front-loaded, which suits a zero-parameter list tool. However, the trailing sentence "Works in both modes" consumes space without conveying meaning an agent can act on, so it does not fully earn 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 simple parameterless list tool with no output schema, the description still needs to convey what a countdown listing yields and what the "modes" distinction means. Both are absent, leaving the agent unable to predict the response or the contextual relevance of the 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?

The tool takes zero parameters, which is the baseline-4 case: there is no argument syntax the description could meaningfully elaborate. Nothing in the description contradicts the empty 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?

"Lists countdowns" is a clear verb+resource and countdowns are not covered by any sibling, so the agent can place it in the toolset. But the second sentence, "Works in both modes," introduces an undefined concept rather than sharpening the scope, leaving the purpose only minimally distinguished.

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

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

There is no statement of when to call this versus other listers, no prerequisites, and no note on ordering or filtering. "Works in both modes" gestures at a usage condition but never says what the modes are or how they change behavior, so the agent gains nothing actionable.

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 supplied, so the description must carry the behavioral burden. It does disclose one meaningful trait — that the tool only works in API-token mode — but says nothing about read-only nature, pagination, date scoping, or what subset of focus records is returned.

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

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

Two short sentences with no filler and the core purpose front-loaded. It is efficient, though the second sentence is doing only minimal work and more behavioral detail could have been added without bloat.

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

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

For a zero-parameter list tool with no output schema and no annotations, the description is adequate but thin: it never indicates the shape or scope of what is returned (e.g. all focus sessions, filtering behavior). An agent can invoke it but knows little about 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 per the baseline a 4 is appropriate. There is no parameter surface for the description to clarify or compensate for.

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

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

States a specific verb and resource: 'Lists focus (pomodoro) records', which clearly separates it from the sibling create_focus. It does not explicitly name or differentiate against other list_* siblings, but the resource is unambiguous.

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

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

The phrase 'API-token mode only' tells the agent a precondition for the tool to work, which is real guidance. However, there is no statement of when to use this versus alternatives (e.g. list_tasks, list_habits) or any exclusion criteria beyond the auth-mode constraint.

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, and it delivers almost nothing: it omits whether results are paginated, scoped to a user, ordered, or what "both modes" means. The single behavioral hint is unexplained, leaving an agent to discover behavior at runtime.

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 short and front-loads the actual operation, which is good. However, the second fragment "Works in both modes" is cryptic filler rather than an earned sentence, so the brevity comes at the cost of meaning.

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 annotations, no output schema, and no parameters, the description is the only source of information, yet it says nothing about what a returned habit contains or what the two modes imply. For such a simple tool the bar is low, but this still falls short.

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 the schema-coverage baseline of 4 applies. There is nothing for the description to clarify about inputs, and it does not misrepresent the empty parameter set.

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?

"Lists habits" gives a clear verb+resource, but the follow-up "Works in both modes" is undefined and does nothing to distinguish this from other list_* siblings. An agent can guess the operation, but not what makes it distinct from list_habit_sections or query_habit_checkins.

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 when-to-use guidance, no condition selecting this over siblings like list_habit_sections, and no prerequisites stated. The phrase "both modes" gestures at context but never explains what the modes are or when each applies.

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. "Works in both modes" hints at a behavioral property but never defines the modes, so it adds ambiguity rather than disclosure. Nothing about ordering, completeness, or scope is stated.

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 no filler. The second sentence is terse to the point of being opaque, slightly undermining the conciseness win.

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 list tool with no output schema the description could be adequate, but it leaves the fundamental question of what a "section" is and what "both modes" refers to unanswered. The undefined mode reference is a real gap for an agent trying to decide whether to call 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter details are missing because none exist.

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 ("Lists habit sections") and parenthetically clarifies that sections are groups, which disambiguates the term. However, it does not differentiate itself from the sibling list_habits or explain the relationship between sections and habits.

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 call this versus list_habits or list_project_groups, no prerequisites, and no indication of what "both modes" means. The agent gets no routing help.

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

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

With no annotations provided, the description carries the full burden, and it does disclose one meaningful behavioral constraint: the tool is restricted to API-token authentication mode. It says nothing about pagination, ordering, or whether groups are returned across all workspaces.

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 purpose front-loaded and the auth constraint second, so every word earns its place. It is arguably terse to the point of under-specifying, which keeps it just short of a 5.

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

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

For a zero-parameter read tool with no output schema and no annotations, the definition covers the essentials but omits what a 'project group' actually is and what the response contains. An agent can invoke it safely, but cannot predict the 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?

The tool takes zero parameters, so the schema imposes no semantic burden and the description cannot add parameter meaning. Baseline 4 applies; nothing is missing or misleading on this dimension.

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 (Lists) and resource (project groups), which is distinguishable from the sibling list_projects at the resource level. It does not explicitly clarify how 'project groups' differ from 'projects', leaving a small ambiguity an agent must resolve by inference.

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

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

The phrase 'API-token mode only' is a genuine usage constraint that tells the agent when this tool is callable, which is more than most definitions offer. However, it names no alternatives and gives no positive context for when to prefer this over list_projects.

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

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

With no annotations, the description carries the full behavioral burden, and it does add two real facts: results are scoped to the signed-in user, and the tool works in both cookie and API-token auth modes. It says nothing about result shape, ordering, or pagination for large project lists, so meaningful gaps remain.

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

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

Two short sentences with zero waste, and the core action plus scope is front-loaded ahead of the secondary auth-mode note. Nothing is repeated from the schema since there is no schema content.

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

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

For a zero-parameter listing tool with no annotations and no output schema, the description covers who the results belong to and the auth modes that work. It could still mention ordering or result shape, but the agent has enough to 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?

The tool takes zero parameters, so the schema cannot carry or obscure any parameter meaning; there is nothing for the description to compensate for. The baseline for a 0-param tool applies.

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

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

States a specific verb+resource ("Lists all projects") and usefully disambiguates the domain term by equating projects with "lists", which distinguishes it from list_project_groups and the single-project get_project. It does not explicitly name a sibling to route against, 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?

Usage is only implied: an agent can infer this is the enumeration call for the current user, and "for the signed-in user" scopes it. There is no statement of when to prefer it over get_project_with_data or list_project_groups, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read operation but never states read-only safety, return shape, ordering, or pagination. 'Works in both modes' gestures at behavior but is undefined, so it cannot be acted on.

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 very short sentences with the core action front-loaded and no padding. The second sentence is brief but under-specified rather than wasteful.

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 list tool with no output schema, the description is nearly sufficient, but it omits the return content (names, ids, colors?) and leaves the 'both modes' claim dangling, which is the one piece of complexity this tool appears to have.

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 clarify beyond what the empty schema already conveys. Baseline 4 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 ('Lists all tags'), which is enough to distinguish it from sibling tag mutators like rename_tag, merge_tags, and delete_tag. However, 'Works in both modes' is opaque — the modes are never identified, leaving a scope claim the agent cannot act on.

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 guidance and no alternatives named. The agent is not told, for example, whether this is preferred over get_project_with_data or list_tasks when tags are needed in context, nor whether any prerequisite exists.

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 only the inbox-targeting trick and says nothing about ordering, pagination, result limits, or whether completed tasks are excluded by default — the last of which it only implies indirectly.

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

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

Two short sentences, front-loaded with the core purpose followed by the one non-obvious usage tip. Nothing is padded or redundant.

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

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

For a two-parameter read tool with no output schema, the description covers the basics, but it never addresses ordering/pagination or the relationship to sibling list_completed_tasks. The schema covers the parameters, so only the behavioral surface is left thin.

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 parameters are already documented, including the inbox sentinel and the includeCompleted default of false. The description merely repeats the projectId sentinel and adds no syntax or semantics 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+resource ('Lists the tasks in a project'), which is unambiguous on its own. However, it does not distinguish itself from the sibling list_completed_tasks or clarify how includeCompleted interacts with that sibling.

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

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

The description gives one concrete usage hint (use projectId "inbox" for the signed-in user's inbox), which is helpful. But it offers no guidance on when to prefer this tool over list_completed_tasks or search_tasks, leaving the routing decision to inference.

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

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

With no annotations, the description must carry the behavioral burden. It discloses the 'web mode only' constraint, which is genuinely useful context an agent cannot derive from the empty schema, but says nothing about pagination, permissions, or what the listing returns.

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

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

Two short clauses, zero filler, and the purpose is front-loaded ahead of the mode constraint. 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 no-parameter list tool this is close to sufficient, and there is no output schema to explain. Still, the agent is left unaware of what the templates contain, whether results are paginated, or whether further calls are needed to use a template.

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, which is the baseline 4 case. The description correctly implies no inputs are needed, aligning with the empty 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 ('Lists task templates'), so an agent immediately knows the operation. There is no template-related sibling to distinguish from, so sibling differentiation is not required here, though the description does not scope what a 'task template' contains.

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 qualifier 'Web mode only' gives an implicit usage condition — it signals the tool should not be called in non-web contexts. However, it offers no explicit when-to-use guidance, prerequisites, or alternatives to consider.

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 full behavioral burden. 'Lists' implies a read-only operation, but the description does not disclose pagination behavior (limit), default type behavior, return format, or any other behavioral traits.

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, waste-free sentence. It is appropriately sized for a simple list tool and 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 simple list tool with two optional parameters and full schema coverage, the description is minimally adequate. However, with no output schema, it does not explain what the returned list contains (e.g., fields, ordering), and it omits usage context.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides, which is the baseline expectation when schema coverage is high.

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

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

The description states a clear verb+resource: 'Lists trashed tasks.' It distinguishes trashed tasks from active tasks (list_tasks) by the word 'trashed,' but does not explicitly differentiate from siblings like restore_task or list_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 when-to-use, when-not-to-use, or alternative guidance is provided. The agent must infer that this tool is for viewing trashed tasks, with no mention of related tools such as restore_task.

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, and it discloses almost nothing: it does not say whether the source tag is deleted, whether the target tag absorbs its assignments across tasks, or whether the merge is reversible. 'Web mode only' is the one genuinely useful behavioral constraint offered.

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

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

Two short sentences with zero waste; the core operation is front-loaded and the platform constraint is attached as a compact second sentence.

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

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

For a mutation tool with no annotations and no output schema, the description omits the outcomes an agent needs: fate of the source tag, effect on tasks holding it, and reversibility. The schema and description together still leave the tool's side effects unspecified.

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 both parameters are documented in the schema, so the baseline of 3 applies. 'One tag into another' aligns with the name/toName direction but adds no format, ID-vs-name, or edge-case detail 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 ('merges one tag into another'), which an agent can distinguish from sibling rename_tag and delete_tag. No explicit differentiation from those siblings, but the operation itself is unambiguous.

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

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

Only implied usage guidance; the 'Web mode only' note is a useful precondition but there is no statement of when to prefer this over rename_tag or delete_tag, nor prerequisites like permissions.

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutating tool. It does not say whether the move preserves task metadata, whether 'inbox' behaves as a special destination (only the schema hints at this), what permissions are required, or whether the move is reversible.

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

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

A single tight sentence with the verb and both endpoints front-loaded; nothing is wasted. It is arguably under-specified rather than over-long, but as a structure/concision matter it is efficient.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin: it omits side effects, permission needs, and what happens to the task's other fields on relocation. The fully documented schema covers inputs but not the behavioral context an agent needs before invoking a write.

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 three parameters are already documented in the schema, including the 'inbox' special value. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (moves) and resource (task) with the scope of the operation (one project to another). It is unambiguous, though it does not differentiate itself from the sibling update_task, which could plausibly also relocate a 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?

No when-to-use guidance, no statement of prerequisites, and no mention of how this differs from update_task. The agent must infer that this is the dedicated relocation path.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one real behavioral trait — a dual-mode interface where the API-token path ignores all parameters — but says nothing about auth requirements, result limits, ordering, or pagination for a query endpoint.

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 compact sentences, front-loaded with purpose, then the mode/argument mapping. No filler.

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

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

There is no output schema and no annotations, so the description should carry more: return shape, ordering, and any result limits are unstated. For a three-optional-parameter read tool it is adequate but leaves real gaps.

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

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

Schema coverage is 100% and each parameter already carries its own '(web mode)' description, so the description adds little beyond restating the grouping. Baseline 3 applies; no further syntax or format detail is added.

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 ('Queries habit check-in records') and adds a mode distinction. It doesn't name a sibling alternative, but no other sibling covers check-ins, so differentiation isn't a real hazard here.

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 signals that behavior depends on mode (web vs API-token) and which argument set each mode expects, which is genuine usage context. However it never says when to prefer this tool over list_habits or any other read tool, and it gives no exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds one genuinely useful operational constraint (web mode only), but omits whether the operation is destructive, whether it requires specific permissions, and what happens if newName collides with an existing tag.

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

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

Two short sentences, zero filler, with the action front-loaded and the environment constraint second. Every sentence carries information the agent needs.

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

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

For a mutation tool with no annotations and no output schema, the description is thin: it does not cover naming conflicts, reversibility, permission requirements, or tag-usage side effects. Only the mode constraint is supplied.

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 parameters ('name' as current tag name, 'newName' as new tag name) are already documented in the schema. The description adds no format, casing, or uniqueness constraints beyond that, 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?

States a specific verb and resource ('Renames a tag'), which is unambiguous on its own. However, it does not differentiate itself from the related tag mutations merge_tags and delete_tag, so the agent must infer scope from the name alone.

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 only contextual guidance is the 'Web mode only' constraint, which restricts where it can run but does not say when to rename versus merge or delete tags. No prerequisites or alternative-selection conditions 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 exist, so the description carries the full behavioral burden. It states the source state ('from the trash') but says nothing about required permissions, whether the restore is reversible, what happens if the task is not in the trash, or where the task is restored to. For a mutation tool, this is a significant gap.

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, which is efficient. However, it may be too terse for a mutation operation with no annotations, so it's not a perfect 5.

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 annotations, no output schema, and only two documented parameters, the description is missing key context an agent needs: the effect of the restore, required permissions, error conditions, and whether any value is returned. It covers only the bare operation.

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 parameters are already documented. The description adds no additional meaning about taskId or projectId beyond what the schema provides, which deserves the baseline of 3 when the schema does the heavy lifting.

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 ('restores') and resource ('a task from the trash'), which clearly distinguishes it from siblings like delete_task, complete_task, or update_task. It does not explicitly name an alternative, but the trash scoping is unambiguous.

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

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

The phrase 'from the trash' implies the task must already be trashed, but there is no explicit when-to-use guidance, no mention of prerequisites, and no reference to sibling tools like list_trash for finding candidates. An agent must infer the workflow entirely.

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 indicates that search spans tasks, comments, and other content, but says nothing about read-only safety, result limits, pagination, permissions, or ranking behavior.

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

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

The definition is a single front-loaded sentence with no wasted words. It immediately communicates the operation and scope without unnecessary elaboration.

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 tool with full schema coverage, the description is minimally viable. However, with no annotations and no output schema, it leaves gaps around result behavior and when to prefer search over listing tools.

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

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

Schema description coverage is 100%, and the single 'query' parameter is already documented as 'Search text.' The description adds no extra parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource scope: full-text search across tasks, comments, and other content. This distinguishes it implicitly from list_tasks and get_task, though no sibling is named explicitly. The phrase 'other content' is slightly vague but does not undermine the core purpose.

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

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

There is no guidance on when to use this tool versus list_tasks or other retrieval siblings. The only implied usage is that it is a search operation, but no conditions, exclusions, or alternatives are provided.

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

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

With no annotations, the description carries the full burden. It usefully discloses the 'web mode only' constraint and the stateful checkpoint/reuse pattern, which are real behavioral traits. It stops short of covering auth/permission needs, rate limits, or failure behavior.

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

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

Two sentences, front-loaded with the scope and ending with the operational instruction. Every clause adds information; nothing is padding.

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

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

For a single-parameter tool with no output schema, the description covers scope, mode restriction, and the pagination/checkpoint contract including the returned value. Missing only edge behavior (what happens outside web mode, error cases), which is minor here.

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 already defines checkPoint, but the description adds genuine workflow meaning beyond the field doc by pairing checkPoint=0 with full snapshot and explaining that the returned value should be reused. That goes past 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?

States a specific verb+resource ('delta pull of the whole account') and enumerates the payload (tasks, projects, tags, columns). This clearly separates it from the many single-resource siblings like list_tasks and list_projects, since it is the only bulk account-state sync.

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 usage workflow: pass checkPoint=0 for a full snapshot, then reuse the returned checkPoint for incremental pulls, plus a mode restriction ('web mode only'). It does not, however, state when to prefer this over the per-resource list_* 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 are provided, so the description carries the full behavioral burden. It discloses the target status value but nothing about permissions, whether the reopen is idempotent, what happens to completion dates or subtasks, or any error behavior on an already-open task.

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, front-loaded with the verb and resource, with zero padding. Nothing needs trimming.

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 mutation with a fully documented schema and no output schema, the description is minimally sufficient to call the tool. However, with no annotations it should at least state whether a completed precondition exists and what the operation affects.

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 both parameters, including the 'inbox' special value for projectId, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond that 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?

Gives a specific verb ('Reopens') and resource ('a completed task'), plus the resulting status value, so the agent can distinguish it from complete_task and delete_task. It stops short of naming the sibling it is the inverse of, but the action is unambiguous.

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

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

Usage is implied (undo a completion), but the description never states when to prefer this over the adjacent siblings restore_task or update_task, nor any precondition such as the task currently being completed. The agent must infer the routing.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it says only 'Updates'. It does not disclose whether this is a partial or full update, what happens to fields omitted from the request, that closing a project is a state change, or whether the operation is reversible. For an unannotated 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?

A single efficient sentence with the verb and resource front-loaded and no wasted words. It is arguably under-specified rather than verbose, which is the more forgivable failure for conciseness.

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

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

For a seven-parameter mutation tool with no annotations and no output schema, the description is too thin: it omits the 'closed' flag (a state-changing operation), sortOrder, and any statement of partial-update semantics or required projectId. An agent can call it, but not confidently predict its behavior.

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

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

Schema description coverage is 100% with all seven parameters documented in the schema (including enum values for kind and viewMode), so the baseline is 3. The description names four of the seven fields, adding nothing the schema does not already state, and silently omits 'closed' and 'sortOrder'.

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 (Updates) and resource (a project) and enumerates the mutable fields, so an agent can distinguish it from delete_project or create_project. It does not, however, mention the sibling update_task or note how this differs from other project mutations, and it omits several schema fields (closed, sortOrder, projectId).

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 guidance on when to use this tool versus delete_project, get_project, or list_projects, nor any prerequisites such as required permissions or whether the project must exist. The only implied usage is 'when you want to change a project field', which is bare minimum inference.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one genuinely useful trait beyond schema: partial-update semantics ('Only the supplied fields change'), so unspecified fields are preserved. It remains silent on permissions/auth, whether the task must pre-exist, error/not-found behavior, and whether the update is idempotent.

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

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

Two short sentences, zero filler, with the mutation semantics front-loaded immediately after the purpose statement. Nothing is repeated from structured fields and 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 16-parameter mutation tool with no annotations and no output schema, the description is thin: it omits permissions, failure modes, and what a successful update returns. The partial-update note is the key missing piece it does supply, and full schema coverage compensates for the parameter detail gap, but an agent still lacks operational context.

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

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

Schema description coverage is 100%, so all 16 parameters (formats, enums like priority, RFC 5545 recurrence, date formats) are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('Updates fields on an existing task'), making it clearly distinct from create_task, move_task, and complete_task by naming the existing-resource mutation. It does not explicitly contrast itself with sibling mutators such as move_task or batch_tasks, which would be needed for 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 implied by the verb (edit an already-existing task) and the partial-update note signals the intended pattern of supplying only changed fields. There is no explicit guidance on when to prefer this over move_task, complete_task, or batch_tasks for bulk edits, and no stated prerequisites.

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