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, 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 supplied, the description carries the full behavioral burden, yet it omits the crucial facts for a delete operation: whether removal is permanent or reversible, whether it requires confirmation, and whether tasks carrying the tag are affected. 'Deletes' only implies mutation without disclosing any of the consequences.

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

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

A single short sentence that is front-loaded and free of filler. It is efficient but borders on under-specification rather than true 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 destructive, unannotated tool with one required parameter and no output schema, the description should at least state permanence and side effects. As written, an agent cannot tell what happens to tasks using the tag or whether the action can be undone.

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 there is only one parameter ('name', documented as 'Tag name'), so the schema fully covers the input. The description adds no format or identity detail (e.g., ID vs. name matching) 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 (deletes a tag), which is unambiguous on its own. However, it does nothing to distinguish itself from siblings like rename_tag, merge_tags, or list_tags, which all operate on the same resource.

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 delete a tag versus the closely related alternatives, notably merge_tags, which is often the safer choice when a tag is still in use. No prerequisites or warnings about the destructive nature 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 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?

No annotations are provided, so the description carries the full burden. It discloses what data is returned (id, inbox id, plan, registration) which is genuinely useful, but says nothing about authentication requirements, error behavior when unauthenticated, or whether the call has side effects.

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

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

A single front-loaded sentence with no filler tokens; every listed field is informative rather than 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?

With no output schema and no annotations, the description usefully enumerates the primary return fields, which is the key missing structured data. It stops short of describing auth/error behavior, but for a zero-parameter read of the current principal this is close to sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to compensate for; the baseline of 4 applies. No parameter meaning 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 ('Gets') and resource ('signed-in user') and enumerates the returned fields (id, inbox id, plan, registration info). It is trivially distinguishable from the task/habit/project siblings, though it does not name any sibling explicitly because none overlaps.

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 'signed-in user' — the agent can infer this is the identity/context lookup — but there is no explicit statement of when to call it, no prerequisites, and no mention of alternatives or failure conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via 'Gets', but does not state that it is read-only, has no side effects, or describe authentication or rate limits. It adds some value by listing preference categories but leaves key behavioral traits undisclosed.

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

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

The description is a single concise sentence that is front-loaded with the core action and resource, with waste-free parenthetical examples. It is perfectly sized for a simple getter.

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

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

Given no parameters, no output schema, and low complexity, the description adequately conveys what the tool returns by listing preference types. It could mention that it returns the current user's preferences and whether it is safe to call, but it is largely complete for the tool's scope.

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. The description appropriately does not discuss parameters, as there are none, and the schema is empty.

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 ('Gets') and resource ('user preferences') and gives examples of what preferences include. It is clear but does not differentiate from siblings, though no sibling tool competes directly for this 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?

Usage is implied: the tool retrieves user preferences. There is no explicit guidance on when to call it, no prerequisites, and no alternatives mentioned. For a parameterless getter, the implied usage is adequate but minimal.

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

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

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 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?

No annotations are provided, so the description carries the full burden. It does not disclose that this is a safe read-only operation, whether accounts require auth, or what fields an account record contains. For a zero-parameter list tool the risk is low, but the disclosure is essentially absent.

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 no wasted words and the key information front-loaded. It is appropriately sized for a trivial list tool, though it could carry one more clause of useful context.

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

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

With no output schema, no annotations, and no parameter docs, the description is the only source of information and it says almost nothing. An agent cannot tell what an account entry looks like or how the returned accounts relate to list_calendar_events, so the definition is too thin to be self-sufficient.

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

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

The tool takes zero parameters, so the baseline is 4 — there are no arguments whose meaning the description needs to clarify.

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 ('Lists') and resource ('connected third-party calendar accounts'), so an agent immediately knows what it returns. However, it gives no signal distinguishing it from the sibling list_calendar_subscriptions, which sounds closely related.

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 call this versus list_calendar_subscriptions or list_calendar_events, and no prerequisites or context are stated. Usage must be inferred 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no auth/permission requirements, no statement of what 'connected' implies, no default time range, result limits, ordering, or pagination behavior. For a listing tool with zero structured behavioral hints 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 short sentence with no filler and the verb/resource front-loaded. It is efficient, though its brevity borders on under-specification rather than disciplined 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?

With no output schema, no annotations, and no parameters, the description is the only source of information, yet it does not describe what an event record contains, the time window covered, ordering, or volume. For a list tool whose return shape is entirely undocumented, an agent cannot predict 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 rubric the baseline is 4. The description correctly implies no filtering input is accepted, though it does not explain how results are scoped in the absence of parameters.

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

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

States a specific verb and resource ('Lists events'), which is enough to distinguish it from the task/habit/project siblings. However it offers no differentiation from the closely named siblings list_calendar_accounts and list_calendar_subscriptions, and the phrase 'bound from connected calendars' is slightly ambiguous about what 'bound' means.

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_calendar_accounts or list_calendar_subscriptions, nor any statement of prerequisites or scope (e.g., a required setup step to connect calendars first). The agent is left to infer usage 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 says nothing about read-only semantics, pagination, authentication needs, or return format, offering no context beyond the title.

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 filler. However, it is arguably too terse to be maximally useful for a tool with no other structured documentation.

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

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

Given the tool is a simple, parameterless list operation with no output schema or annotations, the description is minimally adequate to invoke it. It nevertheless omits any behavioral context (read-only nature, return shape, pagination) that would help an agent use it confidently.

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 are no parameter semantics to document. Per the scoring rules, zero params yields a baseline of 4.

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

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

The description gives a clear verb and resource ('Lists calendar subscriptions'), which is specific enough to identify the tool. It does not explicitly differentiate from similarly named siblings like list_calendar_accounts or list_calendar_events, but the resource name is distinct.

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, nor any prerequisites or exclusions. It simply restates the action, leaving the agent to infer context 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 carries the full burden of behavioral disclosure. "Lists" implies a read, but nothing is said about permissions, ordering, pagination, or what happens if projectId is invalid – all relevant for a list tool with zero annotation coverage.

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

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

A single short sentence, front-loaded with the resource and the scope modifier. Nothing wasted and nothing buried.

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

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

For a one-parameter read tool with no output schema and no annotations, the description is minimally adequate but thin: it does not characterize the returned column set, ordering, or the behavior when the project has no columns.

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 projectId field is documented as "Project id; omit for all columns." The description's "optionally scoped to a project" merely restates that, adding no syntax, format, or defaulting detail beyond the schema. Baseline 3 is correct.

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) with its optional scope. No sibling tool operates on columns, so no sibling differentiation is needed, though the description does not say how columns relate to projects or tasks.

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

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

"Optionally scoped to a project" implies the call context but gives no explicit when-to-use guidance, prerequisites, or alternatives. The scoping condition itself is already stated in the schema's projectId description, so little is added.

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 behavioral burden, yet it discloses nothing beyond the verb: no indication of whether all countdowns are returned, how they are ordered, whether results are paginated, or whether any user/permission context is required. For a read-only tool this is low risk, but the disclosure is still absent.

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 no filler and the verb-resource pairing front-loaded. It is efficiently sized, though its terseness is a symptom of under-specification rather than deliberate economy.

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

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

With no output schema, no annotations, and no parameters, the description is the only source of information, yet it says nothing about what a returned countdown looks like or whether the list is filtered or sorted. For a zero-param list tool the description is technically usable but leaves the return contract entirely 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?

The tool takes zero parameters, so there are no parameter semantics to document; per the baseline for 0-param tools this scores 4. Schema coverage is vacuously complete.

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 verb and resource ('Lists countdowns') that an agent can parse, and the Chinese gloss (倒数日) disambiguates the resource as day-countdowns rather than a timer. However, it is essentially the tool name restated, with no scope, ordering, or filtering detail, so it barely clears the minimum-viable bar rather than distinguishing itself from the many sibling list_* tools.

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

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

There is no guidance on when to call this versus alternatives such as list_tasks, list_habits, or list_calendar_events, nor any prerequisite or exclusion. The agent must infer usage purely 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the verb 'lists'. It does not say whether all habits are returned, how they are ordered, whether sections or archived habits are included, or whether results are paginated.

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 zero wasted words. However, its brevity comes from under-specification rather than disciplined conciseness, keeping it 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 trivial zero-parameter list tool this is arguably the minimum viable, but with no annotations and no output schema the agent gets no picture of what a 'habit' record contains or what the list looks like. A brief note on return contents would have closed 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 zero parameters, which sets the baseline at 4 per the rubric. There is nothing for the description to clarify parametrically, so it neither adds nor loses value 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 'Lists habits' essentially restates the tool name with no additional specificity. It gives no scope, ordering, filtering, or relationship to siblings like list_habit_sections or query_habit_checkins, so an agent cannot distinguish its role beyond 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?

There is no when-to-use guidance, no conditions, and no mention of alternatives such as query_habit_checkins or list_habit_sections. Usage is only inferable from the name, which the rules treat as no real 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 technically carries the full burden, but this is a zero-parameter read with no destructive potential, so the disclosure bar is low. The description does not state that it is read-only or describe ordering/pagination, leaving a modest 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 short sentence with the key noun front-loaded after the verb — nothing wasted. It is arguably too terse to be maximally useful, but it is structurally clean.

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 enumeration tool this is minimally complete, but with no output schema and no annotations, the description never says what a 'section' contains or in what form results return, leaving an agent to guess at the shape of the response.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameter meaning is 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+resource ('Lists habit sections') and clarifies the domain term with the parenthetical '(groups)'. It implicitly separates from the sibling list_habits (individual habits vs. their grouping container), but never names that distinction explicitly, 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?

Usage is only implied by the verb 'Lists' — an agent can infer this is a read-only enumeration call with no arguments. There is no statement of when to prefer this over list_habits or query_habit_checkins, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one behavioral trait beyond the schema: results are scoped to the signed-in user. It stays silent on pagination, ordering, and whether archived/deleted projects are included, and never explicitly states the operation is read-only (read-only behavior is only implied by "Lists").

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

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

A single sentence with no filler, front-loading the verb and resource immediately. The parenthetical synonym is the only addition and it earns its place by disambiguating terminology.

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 this is close to sufficient, but with no annotations and no output schema there is no structured data to carry the safety profile or describe what a returned project contains. Pagination and ordering behavior remain unstated, leaving the agent to discover them at call time.

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. There is no parameter semantics for the description to elaborate on, and it correctly avoids inventing filter options that do not exist in 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?

Specific verb + resource ("Lists all projects") with a clarifying synonym that resolves naming ambiguity: projects are the app's lists. It scopes the result to the signed-in user. It does not explicitly differentiate from get_project, but the plural/collective framing makes the contrast obvious.

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?

States no when-to-use condition, no prerequisites, and names no alternative. An agent must infer from the name that this is the bulk-retrieval counterpart to get_project; nothing in the text routes it there.

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 behavioral burden, and it discloses almost nothing beyond the fact that this is a listing operation. It does not state whether results are sorted, paginated, scoped to a user, or what fields each tag contains.

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

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

A single short sentence that is front-loaded and free of padding. It is efficient, though arguably under-specified rather than well-structured prose.

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 zero-parameter read tool this is close to adequate, but with no output schema and no annotations the agent has no idea what the returned tag objects look like or how they are ordered. One clause about the return shape would complete 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 are no parameter semantics to explain; the baseline for a no-parameter tool is 4. Nothing in the description misrepresents the absence of inputs.

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

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

The description states a specific verb and resource ('Lists all tags'), so an agent immediately knows what the tool does. However, it does nothing to distinguish itself from the many other list_* siblings (list_projects, list_habits, list_tasks), which all share the same shape.

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 related tag tools (rename_tag, merge_tags, delete_tag) or other list tools. No prerequisites, no filtering context, no exclusions are given.

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

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

No annotations are provided, so the description 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?

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing. 'Lists' weakly implies a safe read, but there is no information on scope, ordering, pagination, or what a template record contains.

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 no filler and the core action front-loaded. It is efficient, though its brevity reflects under-specification rather than disciplined 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?

With no annotations and no output schema, the description is the only source of context, and it supplies none. An agent cannot tell what a template is in this product, whether results are paginated, or how templates relate to tasks.

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

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

The input schema declares zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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

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

The description states a verb and resource ('Lists task templates'), so the basic operation is clear. However, it is essentially a restatement of the tool name with no differentiation from siblings like list_tasks or list_habits, and it gives no hint about the template domain's scope or contents.

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 preconditions, and no mention of alternatives such as list_tasks. An agent must infer that it is just another list endpoint purely 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?

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?

With no annotations, the description carries the full burden. It implies a mutation but doesn't disclose whether the merge is reversible, what happens to items tagged with the source tag, whether the source tag is deleted, or whether it requires existing tags. For a destructive-style merge operation 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 short sentence that is front-loaded with the verb and resource, with zero padding. It is efficient, though arguably under-specified rather than optimally 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?

For a mutation tool with no annotations and no output schema, the description is too thin: it omits reversibility, side effects on tagged items, and error conditions. An agent can identify the tool but not safely 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%, and the schema already labels 'name' as the tag to merge from and 'toName' as the tag to merge into, matching the description's directional semantics exactly. The description adds no syntax or constraint detail beyond the schema, 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 (merges) plus the resource (tags) and the direction (one tag into another), which distinguishes it from siblings like rename_tag and delete_tag. It's clear but lacks any scope detail such as whether it applies to task tags globally.

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

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

No guidance on when to use this versus rename_tag or delete_tag, and no prerequisites (e.g., both tags must already exist). 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?

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?

No annotations are provided, so the description carries the full behavioral burden. "Queries" implies a read, but nothing states whether the result is paginated, aggregated per habit, capped, or what happens with empty ranges. For a multi-parameter retrieval tool with zero annotation coverage, this is thin.

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. It is efficient, though arguably under-specified rather than genuinely concise given the tool's three required parameters.

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 mean the description must explain what comes back and how results are shaped, and it does neither. For a required-parameter query tool, an agent cannot tell whether check-ins come grouped by habit, as a flat list, or with counts.

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% — from/to carry format examples ("2026-01-01") and habitIds is documented in the schema — so the baseline is 3. The description's "date range" phrasing maps onto two of the three params but adds no syntax or semantics beyond the schema, and never mentions habitIds.

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 clear verb ("Queries") and resource ("habit check-in records") with the scope ("over a date range"). However, it does not distinguish this from any sibling tool — the sibling list contains many list/query tools (list_habits, list_completed_tasks) and nothing routes the agent here versus elsewhere.

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 prerequisites, no alternatives named. The agent must infer from the name alone that this is for retrieving historical check-in data rather than, say, creating check-ins.

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 indicates a mutation but omits permissions needed, collision handling, reversibility, and what happens to tasks already associated with the 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?

The description is a single front-loaded sentence with no wasted words. However, it is so terse that it lacks any structural elaboration beyond restating the operation.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It does not explain error conditions, tag existence requirements, or side effects on tagged tasks.

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 required parameters (name, newName) are documented in the schema. The description adds no parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource: renames a tag. It is distinguishable from sibling operations like list_tags, merge_tags, and delete_tag, but adds no scope details such as what a rename affects.

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 choose rename_tag over alternatives such as merge_tags or delete_tag. The name implies a rename use case, but there are no prerequisites, exclusions, or contextual triggers.

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 behavioral burden; it discloses the delta/incremental model, the full-snapshot trigger, the offline-first purpose, and that a checkPoint is returned. It omits auth/permission requirements and any note on read-only safety, keeping it from a 5.

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 front-loaded sentences with zero filler. The scope and the checkpoint workflow are delivered immediately, and every clause earns its place.

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

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

For a one-parameter sync tool with no output schema, the description supplies the essential mechanics: what is pulled, how checkPoint drives full vs incremental behavior, and that a checkPoint is returned. It does not describe the returned payload shape or edge cases, 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?

Schema description coverage is 100% and already explains checkPoint (default 0 = full snapshot). The description adds only the workflow detail that the returned checkPoint should be reused for incremental pulls, which is a modest addition beyond the schema 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 ('delta pull') and a clearly bounded resource ('the whole account: tasks, projects, tags and columns'). This unambiguously distinguishes it from the per-entity list_*/get_* siblings, so an agent can tell it is a bulk sync tool without reading any schema.

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

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

Explains how to use the tool ('Pass checkPoint=0 for a full snapshot, then reuse the returned checkPoint for incremental pulls') and signals the offline-first sync context. It stops short of explicitly stating when to prefer this over sibling list_tasks/list_projects tools, so it lacks the when-not guidance that would make it a 5.

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

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

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.