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

No annotations are present, so the description bears the full burden of behavioral disclosure. It only states 'Archive', and omits whether the operation is reversible, what state changes occur, whether the task remains viewable, or any return value.

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

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

The description is one concise sentence with no redundant wording. It is narrowly scoped and front-loaded, though it still lacks contextual guidance that would make it a more complete definition.

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, this description is under-specified. It doesn't clarify the effects of archiving, how success or failure is conveyed, or how the `id` parameter is consumed beyond schema-level identification.

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 already documents the single parameter `id` with 'Task id', giving 100% schema coverage. The description adds no extra meaning about the id's origin, format, or behavior if invalid, 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 clearly identifies the action ('Archive') and the resource ('a Super Productivity task'), which is distinct from sibling tools like delete_task and restore_task. It doesn't describe the effect of archiving, so it falls short of maximum clarity.

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

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

The description gives no guidance on when to use this tool versus alternatives such as sp_delete_task or sp_restore_task. There is no mention of whether archiving is meant to non-destructively hide tasks or what conditions favor this action.

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 of behavioral disclosure, but it only states that a task is created. It does not disclose whether the operation is idempotent, what side effects occur, whether certain fields are required in practice, or what happens on success or failure. The description is not misleading, but it is far too thin to be transparent about behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and immediately states the core purpose, though it is arguably too terse to carry much informative weight.

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 has 11 parameters, no annotations, no output schema, and many sibling tools, the one-sentence description is not complete enough. It does not explain return values, required fields, or how this creation flow interacts with projects, tags, or subtasks. The schema provides some richness, but the description itself leaves significant gaps for an agent deciding how to invoke the tool correctly.

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

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

The description adds no parameter-level meaning beyond what the input schema already provides. Schema coverage is 73%, which is moderate, and the schema itself contains useful descriptions for many fields, but the tool description does not compensate for the remaining undocumented parameters or clarify relationships between them.

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

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

The description clearly states the action ('Create') and the resource ('a new task in Super Productivity'), making the tool's primary purpose immediately understandable. It does not explicitly differentiate from sibling tools like sp_update_task or sp_delete_task, but the verb 'create' is unambiguous enough to avoid confusion.

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

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

The description provides no guidance on when to use this tool versus alternatives such as sp_update_task or sp_start_task. It does not mention prerequisites, constraints like parentId cannot be combined with projectId, or any context that would help an agent decide between creating a task and using another task-related tool.

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

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

Without annotations, the description carries the burden of disclosing behavioral traits. It states the core behavior (deletion) but fails to disclose important consequences such as irreversibility, whether related data (e.g., subtasks, comments) is also deleted, or any confirmation steps. Given no annotations, a score of 3 is appropriate because it covers the basic action but lacks depth on side effects.

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

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

The description is one short sentence that is front-loaded with the action and object. It is concise and to the point, but could be slightly improved by adding a brief note about irreversibility or a cross-reference to archive for alternatives, giving it a 4 rather than 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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain the effect of deletion on related entities, the irreversibility, or any confirmation expectations, which an agent needs to know to call it safely. The presence of a sibling like sp_archive_task makes the lack of guidance on when to delete versus archive a notable 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 schema already provides 100% coverage with a clear description for the 'id' parameter ('Task id'). The tool description adds no extra detail about the format or semantics of the id beyond what the schema says, so the baseline score of 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?

The description 'Delete a Super Productivity task' clearly states the verb (delete) and the resource (Super Productivity task), making the purpose unambiguous. It distinguishes from siblings by the specific action of deletion, as opposed to create, update, list, or archive.

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

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

The description provides no guidance on when to use this tool versus alternatives like sp_archive_task, which might be a less destructive alternative. It does not mention any prerequisites, such as the task existing or whether the user needs to be the owner, nor does it warn about irreversibility, which would be crucial for a deletion operation.

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 behavioral burden. The word 'Get' implies a read-only operation, and 'if any' correctly signals that an absence of an active task is a legitimate outcome. It does not describe error or none-return format, but there are no side effects obvious for this zero-parameter getter.

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

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

One tight, front-loaded sentence states the resource, the operation, the system context, and the nullable outcome. There is no filler or repetition of the tool name.

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

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

For a zero-parameter getter, this description is largely complete: an agent knows exactly what to call and what it gives. It would benefit from explicitly stating the return value when no task is active (e.g. 'null'/'empty'), but the phrase 'if any' already covers most of the ambiguity.

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

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

The input schema has no properties, so parameter coverage is trivially complete. The description validly needs to provide no parameter-level details. Baseline 4 for zero-parameter tools applies.

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

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

The description names a specific verb ('Get') and a specific resource: the currently active/running task in Super Productivity, with 'if any' signaling a possible absence. This clearly separates it from siblings like sp_get_task, sp_list_tasks, and sp_set_current_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?

Usage is implied by the purpose: call this when you need the current running task. However, it does not explicitly say when not to use it or name alternatives like sp_get_task for a specific task or sp_list_tasks for all tasks.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It states that the operation returns current task and task counts, implying a read-only operation, but it does not clarify what status data is included or whether any side effects occur.

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 wasted words. It front-loads the verb and resource, making the purpose immediately understandable.

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

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

For a zero-parameter status tool, the description is mostly complete: an agent knows what to expect ('current task and task counts'). Slight ambiguity remains about what the task counts represent, but this is a minor gap given the tool's simplicity.

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

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

The tool has zero parameters, so parameter semantics are largely irrelevant. The baseline of 4 applies because no param documentation is needed for correct invocation.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource (Super Productivity) and the returned information (current task and task counts). It is clear, though it does not explicitly differentiate itself from the sibling sp_get_current_task beyond adding 'task counts.'

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

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

The description provides no guidance on when to use this tool instead of siblings such as sp_get_current_task, sp_health, or sp_list_tasks. An agent must infer its use case from the name and brief description.

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

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

No annotations are provided, so the description carries full responsibility. It implies a read operation but doesn't explicitly mention that it doesn't modify anything. It also doesn't describe what happens if the id is invalid, but for a simple getter, the behavior is fairly obvious.

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 verb and resource. No fluff, easy to parse.

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 get-by-id tool with one fully documented parameter and no output schema, the description is adequate. It doesn't explain return values, but since the output schema is absent and it's a standard getter, this is not critical. However, it doesn't mention error behavior or edge cases, which might be useful.

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 parameter 'id' is fully described in the schema as 'Task id', and the description says 'by its id', so there is high redundancy. The schema already carries the meaning, and the description adds little beyond confirming the id is used for lookup.

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

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

The description clearly states the tool gets a single task by its id, which is specific and matches the name. However, it does not differentiate from other retrieval tools like sp_get_current_task or sp_list_tasks, though the phrase 'by its id' helps distinguish from list operations.

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

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

The description implies usage for retrieving a single task when you have its id, but it does not explicitly state when to use this over alternatives like sp_get_current_task or sp_list_tasks. There is no mention of when not to use it, but the context is clear enough for a simple get-by-id tool.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It conveys that the tool is a read-only reachability/readiness probe, which is useful, but it does not disclose what happens when the API is unreachable, what the response format is, or what 'ready' means precisely. The behavior is implied but not detailed enough for fully confident invocation.

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 redundancy. Every word earns its place, specifying the verb, resource, and criterion ('reachable and ready') without padding.

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

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

For a parameterless health probe, the description covers the core 'what' adequately, but because there is no output schema, the agent is left to wonder what the response will look like and how failure is signaled. A brief line about return format or error behavior would meaningfully improve completeness.

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

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

The tool takes zero parameters, so there is no parameter semantics to clarify; the baseline of 4 applies. The description correctly implies no inputs are needed by focusing purely on the reachability check.

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

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

The description uses a specific verb ('check') and identifies the resource ('Super Productivity Local REST API') and target state ('reachable and ready'). It clearly conveys this is a health-check probe, though it does not explicitly distinguish itself from sibling sp_get_status, which could plausibly be selected for similar health/status queries.

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 tool versus alternatives such as sp_get_status, which could serve an overlapping 'status' role. The description gives no context about preconditions, expected usage scenarios, or exclusions, leaving the agent to infer when a health probe is appropriate.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'List' and 'optionally filtered by title' convey that the operation is read-only and that the query restricts results, but the description does not disclose return format, pagination, errors, or access requirements. Basic behavior is clear, but fuller transparency is 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?

The description is a single sentence with no filler: it front-loads the action and resource and states the optional filter in a compact clause. Every word earns its place, and the structure is easy for an agent to parse quickly.

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 low complexity — one optional parameter, no nested objects, and no output schema — the description is minimally adequate for selecting and invoking the tool. However, the lack of annotations and output schema leaves unspecified details about response shape and operational behavior. The description could be more complete without adding much length.

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 sole parameter, query, is fully described in the schema as a case-insensitive substring match on title, giving 100% schema description coverage. The description adds only the phrase 'filtered by title,' which does not go beyond the schema. Baseline 3 is appropriate since the schema handles parameter semantics.

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 ('List') and a specific resource ('Super Productivity projects'), and adds the optional title filter. It clearly distinguishes this from sibling tools like sp_list_tasks and sp_list_tags by naming the resource directly. There is no ambiguity about what the tool 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 no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. An agent must infer from the tool name and sibling context that this is the right tool for project listing. Explicit routing such as 'use this for projects, not tasks/tags' is missing.

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

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

No annotations are provided, so the description must disclose behavior. It only states the action and optional filter; it does not mention that this is a read-only operation, whether authentication is required, or any potential side effects. For a list tool this is a notable gap, as even minimal disclosure of non-mutation would be expected.

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 that front-loads the action and resource, with zero superfluous words. It communicates the core functionality and the optional filter without distraction.

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 one optional parameter and no output schema, the description is adequate. It covers the key functionality and filter. However, the lack of any explicit statement about side effects or return format is a minor omission given the tool's simplicity, so it does not warrant a perfect score.

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

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

The schema already provides a complete description of the query parameter ('Filter by title, case-insensitive substring match'), achieving 100% coverage. The description's 'optionally filtered' adds no new semantic beyond what the schema implies by the parameter being optional. Baseline of 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('Super Productivity tags'), and the optional filter is noted. This distinguishes it from siblings like sp_list_tasks and sp_list_projects, as the tool name and description make the resource explicit.

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

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

The description implies usage: use this tool when you want a list of tags. However, it does not explicitly mention alternatives or conditions when not to use it. The context is clear but not elaborated with routing to other tools, leading to an implicit rather than explicit guideline.

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?

There are no annotations, so the description carries the transparency burden. It signals a read-only 'list' operation but does not state side effects explicitly, nor does it mention result shape, pagination, ordering, or the default active/non-done behavior that affects output. The schema provides defaults, but the description itself discloses almost no behavioral context beyond listing.

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

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

One well-structured sentence that front-loads the operation and then gives the optional filters. No filler or repetition of schema details. It earns its place while remaining minimal.

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 annotations and no output schema, the description is adequate but thin: it tells the agent what the tool does and the filter dimensions, but does not mention default source/archived semantics, includeDone behavior, or return expectations beyond 'tasks'. Since the schema covers the parameters, this is not critically incomplete, but it could be more useful for correct invocation.

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

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

Schema description coverage is 100%, so parameters are already documented with names, types, defaults, and enum values. The description only summarizes those filters without adding any syntax, constraints, or cross-parameter behavior. Baseline 3 applies.

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

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

The description identifies a specific operation (list tasks), the resource (Super Productivity), and the optional filter dimensions. It is immediately distinguishable from sibling tools like sp_get_task, sp_list_tags, or sp_list_projects. It does not name an alternative, so it stops short of the strongest sibling-aware phrasing.

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, exclusions, or alternative routing appears in the description. An agent must infer that this is the tool for obtaining multiple tasks and has no guidance on when sp_get_task or sp_list_tags would be more appropriate. This is effectively no usage guidance beyond 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. 'Restore' conveys an operation, but the description does not disclose success/failure behavior, return values, idempotency, permissions, or side effects such as whether restored tasks retain their tags, projects, or timing data.

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

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

One sentence with the verb and resource front-loaded, and no filler. It is concise without becoming a tautology.

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

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

For a single-parameter tool this is near-sufficient, but because there are no annotations and no output schema, an agent gets no information about return values, error conditions, state transitions, or requirements. A little more behavioral context would make it fully self-contained.

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

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

The schema already documents the only parameter, id, with 100% coverage and describes it as 'Task id'. The description adds no additional parameter meaning, 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 action ('Restore'), a specific resource ('Super Productivity task'), and a scope condition ('previously archived'). This clearly identifies the tool as the inverse of sp_archive_task and distinguishes it from the other task-related sibling 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?

The description implies the usage context: it should be used when an archived task needs to be brought back. However, it does not explicitly mention alternatives, exclude other states, or name sp_archive_task as the inverse operation, so the guidance remains inferred rather than explicit.

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

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

No annotations are present, so the description must carry behavioral disclosure. It reveals the state-changing nature and the null-to-clear behavior, but does not mention side effects such as whether setting a new current task stops the previous one, whether time tracking is affected, or what the operation returns.

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

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

One short sentence, front-loaded with the primary action and a compact parenthetical for the null case; no filler or redundancy.

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

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

For a one-parameter setter this is nearly sufficient, but the lack of any note about its relationship to sp_start_task/sp_stop_current_task and the effect on time-tracking state leaves a moderate gap, especially with no annotations or output schema.

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

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

Schema coverage is 100%, so the schema already documents taskId and the null special value. The description's '(or clear)' reinforces that behavior but adds no new syntax or format information.

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

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

The description uses a specific verb ('Set') and a precise resource ('currently active task'), including an explicit '(or clear)' branch for the null case. It is unambiguous on its own, though it does not explicitly differentiate itself from siblings like sp_start_task or sp_get_current_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 statement about when to choose sp_set_current_task over siblings such as sp_start_task or sp_stop_current_task. The description only defines what the tool does, leaving the selection context to inference.

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

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

With no annotations, the description carries the full burden of disclosure. It states the basic action but does not disclose potential side effects such as what happens to the previously active task, whether the operation fails if the task is already active, or whether any validation occurs. The description is a minimal restatement of the name with no additional behavioral context.

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

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

The description is a single, concise sentence that is front-loaded with the core action and scope. It contains zero filler and requires no restructuring.

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 simplicity of the tool (one required parameter, no output schema), the description covers the basic operation but omits usage context entirely, such as when to use it vs. siblings or any side effects. It is minimally adequate but not complete for a tool with no annotations.

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

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

The schema describes the single 'id' parameter with 100% coverage, so the description does not need to add parameter details. The description correctly implies the id identifies the task to start, but it adds no supplementary semantic value beyond the schema.

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

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

The description clearly states the tool starts a task and sets it as current/active, with a specific verb and resource. However, it does not distinguish itself from the sibling sp_set_current_task, which likely performs the same action, so it lacks 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?

No guidance is provided on when to use this tool versus sp_set_current_task or other alternatives. The description does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core effect and the no-current postcondition, but it does not mention behavior when no task is active, whether the task is completed or merely paused, or whether the operation 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 sentence that front-loads the action and uses a parenthetical to add the essential postcondition. There is no wasted wording.

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?

Adequate for a simple zero-parameter command, but it omits edge-case behavior such as what happens when no task is currently active, and it does not describe return or error semantics. With no annotations or output schema, these gaps are not filled elsewhere.

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

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

The tool has zero parameters and schema coverage is 100%, so there is no parameter information for the description to add. Per the baseline for zero-parameter tools, this is adequate.

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

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

The description uses a specific verb ('Stop') and a clear resource ('currently active task'), and the parenthetical 'no task remains current' states the postcondition. This distinguishes it from sp_start_task and sp_set_current_task, which would leave a task current.

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 clearly conveys when to use the tool: when the currently active task should be stopped. It does not explicitly name alternatives or exclusions, but the 'no task remains current' clause implies it is not for switching to another 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 provided, the description carries the full burden of behavioral disclosure. It only states 'Update' and the immutability of two fields, but does not explain whether the update is partial or full, whether it returns the updated object, or any side effects. The lack of detail on mutation semantics is a significant gap for an agent.

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

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

The description is extremely concise: two sentences with no waste. The constraint note is front-loaded and useful, and the overall structure is ideal for an update tool.

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 has 11 parameters, no output schema, and no annotations, the description is incomplete. It fails to clarify whether unspecified fields are left unchanged or reset, what the tool returns, and any prerequisites like authentication. An agent could not fully anticipate the tool's behavior from this description alone.

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 only 36% (4 of 11 properties have descriptions). The description adds no parameter-specific information beyond the note about parentId and subTaskIds, which are not even in the schema, potentially causing confusion. It does not compensate for the undocumented parameters, so the agent gains little clarity on parameter expectations.

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

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

The description clearly states the tool updates an existing task, using the verb 'update' with the resource 'task'. It also mentions a specific constraint about parentId and subTaskIds. However, it does not explicitly distinguish itself from sibling tools like sp_create_task or sp_delete_task, though the verb implies the intended difference.

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 a constraint (parentId and subTaskIds cannot be changed) but does not clarify when to use this tool over alternatives. There is no explicit 'use this when' guidance, though the purpose implies it's for modifying existing tasks. The note is a usage caveat rather than a full guideline.

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