TaScan

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

The description discloses meaningful runtime behavior beyond annotations: it explains that each completed 'number' set 'stores its value and timestamp, giving per-set timing for progression tracking' and clarifies response_type semantics. Annotations only say the call is not read-only and not destructive; the description adds the important data-capture behavior. It doesn't cover idempotency or bulk edge cases, but the safety profile is already covered.

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

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

Three sentences, front-loaded with the core action, then the typed-response taxonomy, then a worked example. No filler; the example earns its place by making the response_type semantics concrete.

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 only two required parameters and a fully described schema, the description plus schema is enough to construct a correct call: task_id, subtasks with title, optional sort_order/description/response_type/response_config. It lacks an explicit note about the return value or bulk limits, but no output schema exists and the interactions are simple, so 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 has 100% coverage with descriptions for task_id and subtasks, so baseline is 3. The description adds value by giving concrete examples of response_type values ('number' for per-set data like reps/weight/distance, 'choice' for options) and illustrating the set-logging scenario, which goes slightly beyond the bare 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 clear verb+resource: 'Add one or more subtasks to a task (bulk)' – specific and distinct from tascan_add_tasks and other sibling mutation tools. It also names the key domain feature (typed responses), further narrowing the 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?

Provides a concrete use case (set-logging with Bench Press / Set 1/2/3 and response_type 'number') that tells an agent when bulk subtask creation is the right pattern. It doesn't explicitly state when not to use alternatives like tascan_update_subtask or tascan_delete_subtask, but gives clear context for the primary scenario.

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

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

Annotations only mark the operation as non-read-only and non-idempotent; the description adds crucial runtime behavior: permission requirements (agent:dispatch, with agent:dispatch:code variant), refusal without permission, and bulk-creation capability. There is no contradiction with the readOnlyHint=false/destructiveHint=false annotations.

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

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

The description is compact and front-loaded: purpose first, then bulk capability, then the highest-risk parameter guidance, then sibling routing and permission warning. Each sentence earns its place and the IMPORTANT/NOTE formatting highlights the critical parts.

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

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

The tool has a rich schema and no output schema; the description covers the main decision points (response_type, dispatch alternative, permissions) but does not describe the return value or failure modes beyond refusal. For a bulk creation tool this is a minor gap, so it is near-complete rather than fully complete.

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

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

Schema description coverage is 100% and already contains detailed response_type guidance nearly verbatim (text for info collection, photo for proof, checkbox for confirmations). The tool description restates and emphasizes that guidance but does not add new meaning beyond the schema, so it stays at the high-coverage baseline of 3. The permission note is about authorization, not 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 opens with a specific action and target ('Add one or more tasks to an event (task list)') and notes bulk creation, so the agent knows exactly what the tool does. The note routing AI-agent dispatch to tascan_dispatch_to_agent also distinguishes this tool from a closely related 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?

It gives an explicit when-not instruction: 'To dispatch tasks to an AI agent use tascan_dispatch_to_agent instead.' It also warns that writing into an agent inbox list requires agent:dispatch permission and that the call is refused without it, giving clear conditions for use. This is strong routing guidance beyond the schema.

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

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

Annotations already indicate idempotent, non-destructive, and readOnlyHint false. The description adds valuable context by disclosing that server_side_ai triggers a POST to the Anthropic API, explaining why the tool is not purely read-only and highlighting potential external side effects. No contradiction with annotations exists.

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

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

Three sentences each contribute useful information: protocol context, retrieval details, and the server-side AI capability. It is efficient, though the protocol framing at the start delays the core verb; overall it is appropriately sized and structured.

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

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

With no output schema, the description gives a reasonable summary of the returned data (worker info, message thread, project history, similar issues) and explains the behavior for both default and server_side_ai modes. It covers the tool's complexity well, though exact response formatting is not detailed.

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 baseline is 3. The description reinforces the server_side_ai parameter's behavior (raw data vs. direct AI analysis) but does not introduce new semantic meaning 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?

The description explicitly states the tool retrieves full issue context, listing specific data types (worker info, message thread, project history, similar issues), and also mentions the server-side AI analysis option. It clearly distinguishes itself from sibling tools like list_issues or auto_resolve by framing it as Step 1 of the Closed-Loop Autonomous Operations Protocol.

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 usage context by labeling it as 'Step 1 of the Closed-Loop Autonomous Operations Protocol' and states its intended purpose ('Use this data to reason about the root cause and generate a remediation plan'). However, it does not explicitly mention alternatives or when not to use this tool, so it lacks full exclusion guidance.

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

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

Annotations already indicate this is a non-readOnly, non-idempotent, non-destructive operation. The description adds that it 'adds all template tasks', confirming an additive effect, but it does not disclose potential duplication on re-application or error behavior. Little is added beyond the annotations.

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

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

The description is a single, concise sentence that is front-loaded with the verb and clearly states the action and target. No unnecessary words or repetitions.

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 annotations and full schema coverage, the description is mostly complete. It clearly communicates the core functionality but could add context about whether existing tasks are preserved or if applying twice duplicates tasks. However, the non-destructive hint partially covers this.

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?

Both parameters are fully described in the schema (list_id and template_slug) with examples in the template_slug description. The tool description reinforces their role but does not add additional semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the action 'apply' with a specific resource 'pre-built template to a task list' and the outcome 'adding all template tasks'. This distinguishes it from sibling tools like tascan_add_tasks, which focus on adding tasks individually rather than through a template.

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 tool is used when a template_slug is available, but it does not explicitly state when to use this tool over alternatives (e.g., tascan_add_tasks) or mention any prerequisites like listing templates first. Usage is inferred but not directly guided.

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

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

The description adds behavioral context beyond the annotations by explaining that the model uses 'the asset's full assessment history in context' and returns specific outputs (delta score, defects, wear indicators, recommendations, trajectory). It does not contradict the annotations (readOnlyHint=false, destructiveHint=false) and provides meaningful insight into how the tool operates.

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

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

The description is two sentences long, with the first sentence front-loading the core purpose and the second efficiently describing the return values and behavioral context. There is no redundant or unnecessary information; every phrase 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?

With no output schema, the description carries the burden of explaining return values, which it does thoroughly (delta score, defects, wear indicators, recommendations, trajectory). It also explains the use of historical context. However, it does not address edge cases (e.g., no previous assessment) or response format specifics, leaving a small gap. Overall, it is nearly complete for a tool of this complexity.

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 input schema. The description adds some contextual relationship (e.g., history context for asset_id) but does not provide additional parameter-level details beyond what the schema offers, resulting in a baseline score of 3.

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

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

The description clearly states the tool's function: 'Run an AI condition assessment of an asset from a photo.' It goes beyond a simple statement by specifying unique outputs like 'Condition Delta Score' and 'degradation trajectory,' which distinguishes it from sibling tools like tascan_condition_history or tascan_recommend_fix.

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 clear context for when to use the tool: when you need a photo-based AI condition assessment with historical context. It implies the use case but does not explicitly name alternatives or exclusions, which prevents a 5. However, the context is clear enough for an agent to select it appropriately.

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

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

The description adds behavioral context beyond the annotations by detailing the server-side AI analysis, creation of a task list, and dispatch to a worker, including physical-world instruction delivery. This complements the annotations (readOnlyHint=false, destructiveHint=false) and provides a clear picture of the multi-step side effects without contradicting them.

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

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

The description is three sentences and not overly long, but it contains marketing-like phrasing such as 'FULL Closed-Loop Autonomous Operations Protocol' and a patent claim reference that may be unnecessary for practical understanding. The core behavior is present but could be stated more directly and front-loaded.

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

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

There is no output schema, yet the description does not explain what the tool returns or the outcome after dispatch, such as a confirmation, task list, or status update. It also omits prerequisites like the issue being in a resolvable state, leaving the agent without a full understanding of result handling.

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 covers issue_id with 100% description coverage, so the schema documents the parameter adequately. The description does not add extra meaning about the parameter format, source, or constraints, leaving the baseline score of 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 clearly indicates the tool performs a full autonomous resolution workflow: analyzing the issue, generating remediation tasks, creating a task list, and dispatching to a worker. This goes beyond simply saying 'auto-resolve' and distinguishes it from sibling tools like tascan_analyze_issue or tascan_add_tasks by emphasizing the complete closed-loop behavior.

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 when full autonomous resolution without human intervention is desired, but it does not explicitly state when to use this tool versus alternatives. It lacks exclusions or a direct comparison with sibling tools, such as suggesting tascan_analyze_issue for only analysis or tascan_dispatch_instruction for only dispatch.

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

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

Beyond the annotations, the description discloses that non-pending rows are refused with 409 and that sent messages cannot be recalled. This adds meaningful behavioral context to the destructiveHint and idempotentHint annotations. It does not contradict any annotation.

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

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

Two concise sentences deliver the action, the precondition, and the key error condition without repetition or filler. The most important information is front-loaded.

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

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

For a single-parameter mutation with no output schema, the description covers the valid target state, the invalid states, the error behavior, and the fundamental limitation. Combined with the annotations, an agent has everything needed 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?

Schema coverage is 100% and the single id parameter is already fully described as the scheduled_sms row id from tascan_schedule_sms / tascan_list_scheduled_sms. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description names the exact operation (cancel) and the target resource (a scheduled text/SMS row) and specifies the relevant state (pending). This clearly distinguishes it from scheduling, sending, and generic deletion tools in the sibling list.

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

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

It states an explicit precondition — the text must be pending — and explicit forbidden states: sending, sent, failed, or cancelled. It also makes the hard limitation clear with 'a sent text cannot be recalled,' so an agent knows exactly when to use this tool and when not to.

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

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

Annotations already indicate a non-read-only, non-idempotent operation. The description adds valuable behavioral detail beyond this: each completion is timestamped, per-set durations are derivable from consecutive completions, and the returned progress includes the all_subtasks_complete flag. This helps the agent understand the timing semantics and downstream implications.

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

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

The description is three focused sentences with no wasted words. The core action is first, then the optional parameter behavior, then progress/return behavior and the related parent-completion step. Important operational details are front-loaded.

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

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

The description adequately covers the operation's purpose, optional behavior, return key, and next action. While an output schema is absent, the description provides the most relevant return information (all_subtasks_complete and timestamping). Some details like error behavior or what happens when all_subtasks_complete is false are not spelled out, but are reasonably inferable.

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 all parameters. However, the description enriches response_value by explaining its purpose with a concrete example ('weight or reps') and indicating it applies to number/text/choice subtasks. This goes beyond what the schema alone communicates.

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 specific action ('complete a subtask') and the optional response_value for typed data. It also distinguishes the tool from tascan_complete_task by explicitly mentioning that completing the parent task is a separate step once all subtasks are complete.

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 clear usage context: use this tool to complete a subtask and optionally record a typed response value. It also gives explicit guidance on the next step after completion (calling tascan_complete_task when all_subtasks_complete is true), which is a direct alternative-routing instruction.

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

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

The description discloses concrete side effects beyond the annotations: it inserts a completion record and a timer event. It also reveals the 403 refusal behavior for coordination-cycle tasks, which is valuable behavioral context not available from annotations or schema.

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

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

The description is three sentences long, front-loaded with the primary action, and every sentence contributes useful information: action, side effects, usage context, and exclusions. It is dense but not bloated.

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 output schema, the description covers the essential context: what the tool does, what side effects it causes, and when it fails. The only minor gap is that it does not describe the return value or post-completion state, but this is not critical for 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 the schema already documents all parameters. The description adds some context (such as 'on behalf of a worker' clarifying worker_id), but it does not meaningfully elaborate on response_value or notes, 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 states the tool's action: completing an ORDINARY task on behalf of a worker. It also distinguishes this from coordination-cycle tasks, which are explicitly excluded, and from subtask completion by using the phrase 'ORDINARY task' and the 403 refusal conditions.

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 explicitly says when to use the tool ('simulate or record task completions via the API') and when not to use it (coordination-cycle tasks, builds/reviews, decisions). It even names the alternative completion paths for excluded cases, making the routing decision 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds value by detailing the output: score trend, grades, deltas, findings, and assessor. This goes beyond the annotations by describing the return structure. It does not mention edge cases (e.g., empty history) or response limits, but the annotations cover the core behavior adequately.

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

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

The description is two sentences with zero filler. The first sentence is front-loaded with the verb and resource, then lists specifics. Every word earns its place; no redundancy or fluff.

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 one parameter and no output schema, the description covers the core purpose and return contents. However, it lacks details on response ordering (chronological?), pagination (if many assessments), and error handling for missing assets. The annotations (openWorldHint=false) hint at limited results, but completeness is adequate but not fully fleshed out.

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 one parameter (asset_id) with description 'Asset ID', and schema coverage is 100%. The description does not add type or format details for asset_id (e.g., is it a UUID or serial number?), but the phrase 'per-serial-number condition ledger' weakly implies asset_id corresponds to a serial number. This adds marginal meaning beyond the schema, keeping the score at baseline 3.

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

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

The description uses a specific verb ('Get') and explicitly identifies the resource ('asset's longitudinal condition history'), detailing what it returns: score trend, assessments with grade, delta, findings, and assessor. It distinguishes itself from sibling tools like tascan_get_scan_history and tascan_get_report by focusing on condition history, and the 'per-serial-number condition ledger' clarifies scope by serial number.

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 clear context by specifying 'longitudinal condition history' and listing the contents (grades, trends, findings), so an agent knows to use this when needing historical condition data. However, it does not explicitly state when not to use it or name alternative tools (e.g., tascan_get_report for summaries). The context is strong enough for a 4.

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

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

Annotations only mark read/write/idempotent/destructive hints; the description far exceeds that by disclosing side effects (minting tasks, parking cycles, revision limits), duplicate-prevention behavior, preflight limitations (unchecked[]), and error codes. No statement contradicts annotations.

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

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

The description is front-loaded with the core action, but it is a single extremely dense paragraph with long parenthetical enumerations of validation codes and edge cases. It earns its place content-wise, yet poor visual structure makes it harder 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?

Despite no output schema, the description covers side effects, preflight validation, failure modes, duplicate handling, revision/review behavior, optional panels, permissions, and tracking. A caller has the information needed to decide on dry_run versus a real create and to interpret the cycle afterward.

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 baseline applies; the description largely repeats semantics already present in the schema (kind=review_only, dry_run, artifact_bytes, idempotency_key). It adds protocol-level context like build_ref sha256 and DUPLICATE root_id, but not enough new per-parameter meaning to rise above the high-coverage 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?

Opening sentence names a specific verb and resource: 'Start an unattended build-review-decide cycle' and immediately spells out concrete behavior (queues T1 CODE:/T2 REVIEW:). This clearly distinguishes it from the many create_* and list_* siblings; it is unmistakably the cycle-creation tool.

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

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

The description gives clear invocation context: dry_run performs a PREFLIGHT-only validation, a real run queues multiple tasks, and tracking is routed to tascan_get_cycle_report(root_id). It also states the required permission (REQUIRES agent:dispatch:code), though it does not explicitly enumerate when-not-to-use alternatives.

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

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

The description adds mode semantics and the rule that team_mode and multi_instance cannot both be true, which is not available from annotations. It does not contradict the annotations. Some side effects, like worker assignment moving, are only hinted in the schema param note rather than the description.

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

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

Two sentences with no filler. The core action is front-loaded, and the mode explanation follows naturally in compact form.

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

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

The main purpose, project placement, mode semantics, and the key constraint are present, and all parameter details are covered by the schema. It is silent on return behavior or what happens after creation, which is a minor gap given there is no 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% for all 6 parameters, so the baseline is 3. The description adds extra value by elaborating what team_mode and multi_instance mean and exposing the exclusivity constraint beyond the schema's one-line property descriptions.

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

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

The description states a specific verb (Create), resource (event/task list), and scope (within a project). It also names the two mode flags, which distinguishes it from project/worker/zone creation siblings even without naming them.

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

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

It provides useful context for when multi_instance is valuable ('surveys, onboarding, info collection') and notes the mutual-exclusion constraint. However, it does not mention alternatives like tascan_update_event or tascan_create_project, nor give explicit when-not 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?

It goes well beyond the annotations by revealing non-obvious behavior: auto lines come only from VERIFIED work, lists with no completions are skipped, billing is quarter-hour from first to last verified completion, and single-list invoices also mint a linked Service Report. Annotations only supply read/destructive/idempotent hints, so the description carries the behavioral burden and succeeds.

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

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

Three sentences, front-loaded with the core purpose, and every clause earns its place — including the illustrative line format. It is dense but not padded.

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

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

Despite 17 parameters and no output schema, it names the key decision inputs and the return package (invoice number, totals, url, work billed). The remaining parameter details are already in the schema, so nothing needed for a correct call is missing.

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

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

With schema coverage at 88%, the schema documents individual fields, but the description explains parameter interactions: line_items bypasses auto-billing, project_id/task_list_ids plus hourly_rate or flat_rate_per_list drives generated lines, and attach_service_report behavior is exposed. This adds meaning the schema alone does not convey.

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

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

Opens with an explicit action and resource — 'Create a client invoice and get its shareable link' — and immediately distinguishes the two billing paths. This differentiates it from sibling update/list/request tools even without naming them.

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 explicit conditional guidance for choosing explicit line_items vs project_id/task_list_ids auto-billing, including the rate options. It does not explicitly route to sibling tools such as tascan_update_invoice, so it stops short of full alternative guidance.

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

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

Annotations already indicate a non-read-only, non-destructive, non-idempotent operation. Description adds no additional behavioral context such as permissions, uniqueness constraints, or return behavior. It merely restates the create action.

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 concise sentence, front-loaded with the action and resource; no unnecessary words.

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 create operation with complete schema and annotations, the description provides enough context by explaining the project is a top-level container for events. It does not mention return values, but the absence of an output schema lowers the requirement.

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 provides 100% coverage with descriptions for 'name' and 'location'. Tool description adds no parameter 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?

Description uses specific verb 'Create' with resource 'TaScan project' and clarifies its role as 'top-level container for events', distinguishing it from sibling tools like tascan_create_event.

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?

Description does not explicitly state when to use this tool over siblings; it only implies usage via the project concept. No alternative tools or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds the 'taskee' alias and organizational scope, but does not disclose any additional behavioral traits such as validation rules, uniqueness constraints, or required permissions. It is consistent with annotations.

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

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

The description is a single focused sentence with no filler, front-loading the operation ('Create') and resource ('worker'). It 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?

While the schema is well-documented and annotations cover the safety profile, the description lacks information about return values (no output schema) or any preconditions. For a simple create operation, this is a minor gap, but it's not fully complete.

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

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

Schema description coverage is 100% (name, email, phone each have descriptions). The description adds no additional meaning beyond the schema, which meets the baseline for 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?

The description uses the specific verb 'create' and resource 'worker' (with alias 'taskee'), clearly distinguishing from sibling tools like tascan_update_worker and tascan_list_workers.

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 states what the tool does but gives no explicit guidance on when to use it vs alternatives (e.g., tascan_register_agent may be an alternative for adding agents, or tascan_list_workers to check existing). Usage is implied by the action 'create' but no exclusions 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?

Beyond the annotations, the description discloses that zones perform GPS-based task-list routing and that enforce_on_list locks the task list to workers inside the radius. It does not cover return values or auth, but annotations already establish this as a non-read-only, non-idempotent mutation. There is no contradiction with the annotations.

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

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

The description is two sentences with the core action first and the enforcement option second. It avoids repeating schema content and contains no filler. The geo.html URL detail is specific but earns its place by clarifying the routing mechanism.

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 22-parameter creation tool, the schema carries most of the burden, and the description supplies the essential zone-routing mental model plus a key behavioral toggle. It does not state the return value, but no output schema exists and the annotations already convey the side-effect profile. This is sufficiently complete for an agent to call 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 schema already documents all 22 parameters with 100% coverage, so the baseline is high. The description adds meaning by connecting lat/lng/radius/task_list_id to the routing behavior and by explaining why a caller would set enforce_on_list=true. It does not document parameter syntax, but the schema already does that thoroughly.

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

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

The description opens with 'Create a geofenced work zone,' a clear verb-direct object pair that identifies the resource and distinguishes this from other create_* tools. It then adds the zone's routing behavior, so an agent knows what a zone is for. No ambiguity about what this 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 explains what created zones do and highlights the enforce_on_list behavior, giving useful context. However, it never explicitly says when to use this tool versus update_zone or list_zones, and it offers no exclusions or alternatives. The selection cue is mostly carried by the tool name and the verb 'create.'

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds critical context: the cascade deletion of tasks/completions and irreversibility, which are not inferable from annotations alone. It doesn't contradict annotations.

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

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

Two sentences with no redundancy. Every phrase adds value: the resource, cascade scope, and irreversibility.

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 simple one-parameter schema and no output schema, the description adequately covers purpose, effect, and irreversible nature. It is complete enough for an agent to select and invoke 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 only parameter list_id is fully described in the schema as 'Task list (event) ID to delete' (100% coverage). The description does not add additional parameter-level details, 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?

The description clearly states the action (delete), the resource (event/task list), and the scope (all tasks and completions), distinguishing it from sibling delete tools for tasks and projects.

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 lacks explicit 'when to use' guidance or named alternatives, but the scope 'all its tasks and completions' implies a cascading delete, differentiating it from tascan_delete_task. It provides clear context but no exclusions or alternatives.

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

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

Annotations already mark this as destructive, but the description adds crucial behavioral details: it cascades to events, tasks, and completions, and is irreversible. This goes beyond the structured hints and informs the agent about the full impact of the 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 two concise sentences. The first states the action and scope, the second emphasizes irreversibility. Every word adds value, with 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 simple delete tool with one parameter, the description adequately covers the behavior (cascade deletion) and consequence (irreversible). No output schema exists, but delete operations typically return simple success indicators. The description is complete 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 input schema already provides 100% coverage for the single parameter project_id with a description 'Project ID to delete'. The tool description adds no additional semantic detail 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 clearly states the action (delete), the resource (a project), and the scope (all its events, tasks, and completions). It distinguishes itself from sibling delete tools like tascan_delete_event and tascan_delete_task by specifying the project-level cascade.

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 clear context for when to use this tool: when removing an entire project and its associated data. It does not explicitly name alternatives or state when not to use it, but the scope is unambiguous and the context is sufficient for an agent to select it appropriately.

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

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

The description adds that the deletion cascades to completions and is irreversible, which is valuable beyond the annotations' destructiveHint and idempotentHint. It does not contradict the provided annotations and gives clear context about what gets destroyed.

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, direct sentences contain all essential information. The primary action is front-loaded and the irreversibility warning is immediate, with no unnecessary content.

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

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

For a simple destructive operation with one clearly documented parameter, the description sufficiently covers the object being deleted, the cascading effect, and permanence. It does not describe return values, but there is no output schema and the tool's purpose is straightforward.

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

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

With 100% schema description coverage, the schema already fully describes the single 'subtask_id' parameter. The description does not add parameter-level details, but none are needed given the schema's clarity.

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 the specific action 'Delete a subtask and its completions' with a clear verb and resource, and explicitly notes the irreversible nature. It clearly distinguishes itself from sibing delete_task by targeting subtasks and their associated completions.

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

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

No explicit guidance on when to use this tool instead of alternatives such as tascan_update_subtask or tascan_complete_subtask. The resource name implies the usage, but the description does not state conditions, exclusions, or alternative selection criteria.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds value beyond annotations by explicitly noting the cascade effect ('and its completions') and the irreversible nature of the operation, which is not fully captured by the annotations alone.

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

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

The description is two short sentences that immediately state the primary action and a key consequence. Every word is purposeful, with no redundancy or fluff.

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 small parameter surface, the lack of an output schema, and the presence of annotations (destructive, idempotent), the description covers the essential functional context. It explains what is deleted and the irreversible nature, which is sufficient for an agent to invoke it correctly. It could mention edge cases like non-existent tasks, but that is not critical.

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 provides 100% coverage for the single parameter 'task_id' with a clear description. The tool description does not add additional parameter-level context, 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 uses a specific verb 'Delete' with a clear resource 'a specific task and its completions', which distinguishes it from sibling delete tools for events and projects. The additional note that the action is irreversible further clarifies the scope.

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 implicitly indicates when to use this tool (when deleting a task) but does not explicitly contrast with alternatives like deleting events or projects. No exclusions or prerequisites are mentioned, so usage guidance is minimal but not misleading.

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?

Even though annotations already mark the tool as destructive, the description adds meaningful behavioral detail: it is a soft delete (is_active=false), it refuses under certain conditions, and it never hard-deletes. This goes well beyond the annotations and clarifies exactly what 'delete' means.

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 compact and front-loaded, with the core operation stated first, followed by the key exception and the correct alternative. Every sentence adds value; there is no filler.

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

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

For a single-parameter tool with no output schema, the description covers the operation, the safety guardrail, the alternative path, and the soft-delete behavior. Nothing essential is missing for an agent to decide whether and how to invoke it.

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

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

Schema description coverage is 100%, and the worker_id parameter is already described as 'Worker ID to delete.' The description reinforces that the target is a worker record but does not add significant new semantics beyond the schema, so a baseline score 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 ('Tombstone a worker record'), identifies the exact resource, and clarifies the operation sets is_active=false. It also distinguishes itself from tascan_merge_workers, so an agent can tell which tool handles which scenario.

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

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

It explicitly states the condition under which the tool refuses ('any task/subtask completions or payments') and names the alternative tool to use in that case (tascan_merge_workers). This gives clear when-to-use and when-not-to-use 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?

Beyond the annotations (which only mark it a non-read, non-destructive write), the description discloses concrete side effects ('Mints a completed task + completion under the Chief of Staff worker and a dispatcher_action ledger event on the root'), the auth requirement ('Requires agent:dispatch'), and a conditional path for kind=deploy. This is exactly the behavioral context the rubric credits.

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 core purpose is front-loaded and every clause earns its place — kinds, side effects, deploy exception, auth. However, it is a single dense multi-clause sentence mixing protocol jargon ('protocol v0.2 D6'), conditional logic, and side effects, which makes parsing slightly harder than a structured two- or three-sentence form would.

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

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

For a complex mutation tool with no output schema, the description covers purpose, kinds, side effects, auth, and the deploy-specific composition. The remaining gaps are the unauthorized branch of the deploy path ('when the root is authorized' but no behavior stated for the unauthorized case) and no indication of the response shape.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning beyond the schema: it ties kind=deploy to evidence.deploy_id as a required conditional, and maps root_id to the cycle root via the endpoint path. The per-parameter descriptions in the schema already carry the format details, but the description frames the kind/evidence interplay.

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 ('Record'), resource ('chief-of-staff dispatcher action on a coordination cycle'), and outcome ('as a receipt'), then enumerates the seven valid kinds. It distinguishes itself from siblings by citing the POST endpoint and explicitly clarifying its relationship to coord_record_integration ('one call that does both records').

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

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

The description gives clear context for use — recording dispatcher actions as receipts, with the seven kinds enumerated — and explicitly flags the deploy case where it composes coord_record_integration. However, it does not explicitly state when not to use it or contrast it with the dispatch siblings (tascan_dispatch_instruction, tascan_dispatch_to_agent), so it stops short of a 5.

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

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

The description discloses the tool's multi-channel effects (thread message, notification, feed update, SMS, task creation), which goes beyond the annotations that only indicate non-read-only and non-destructive. This gives the agent critical context about side effects such as SMS delivery and optional task creation, enhancing behavioral transparency.

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

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

The description is two sentences, front-loaded with the purpose and then detailing the specific channels. Each element earns its place; the channel list is necessary and concise. No filler.

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

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

For a 7-parameter dispatch tool with no output schema, the description covers the main behavior and side effects. It lacks information about return values or error conditions, but these are not typically required in a tool description. The protocol context adds completeness, though it could explicitly mention what happens after dispatch.

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?

All 7 parameters have descriptions in the schema (100% coverage), so the baseline is met. The tool description adds context about remediation_tasks ('optional remediation task list creation') and send_sms ('SMS if phone on file'), but these are also covered in the schema descriptions. The description does not significantly clarify parameter formats or relationships 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 dispatches remediation to a worker via multi-channel delivery, with a specific verb and resource. It distinguishes from sibling tools like tascan_dispatch_to_agent by explicitly specifying 'to the worker' and listing concrete delivery channels.

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 context as 'Step 3 of the Closed-Loop Autonomous Operations Protocol,' implying it is used after analysis and recommendation, but it does not explicitly state when to use it over alternatives like tascan_dispatch_to_agent or tascan_send_task_email. No exclusions or alternatives are mentioned, so guidance is implied rather than explicit.

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

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

Goes substantially beyond the annotations: describes automatic pickup/execution, exact routing behavior, cloud agent refusal of CODE/SHELL/PLAN/MCP, default fallback when the local PC agent is dead, and the requirement for agent:dispatch permission. These are non-obvious behaviors an agent must know before invoking.

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?

Dense but well-structured: purpose first, then permissions, routing, fallback, agent targeting, and tracking. Every sentence carries load-bearing operational information; there is 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 3-parameter tool with no output schema, this description is remarkably complete: it covers invocation, permissions, routing rules, error behavior, default agent, and how to monitor the dispatched task via tascan_get_task. An agent has everything necessary 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 coverage is 100%, so the baseline is 3. The description adds high-value semantics beyond the schema: the full routing-prefix system, the default agent value, permission nuances per task type, and the pointer to tascan_list_agents for valid agent IDs. This pushes it above baseline.

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

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

States a specific verb and resource: dispatches work to an AI agent's inbox for automatic execution. The 'PREFERRED tool for sending work to an AI agent' framing and routing details clearly set it apart from sibling tools like tascan_dispatch_instruction and tascan_send_task_email.

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

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

Provides clear operational context: when to target an agent, how routing prefixes select the destination, permission requirements, and how to discover agents or track progress. It does not explicitly state when NOT to use this tool versus alternatives like tascan_dispatch_instruction, so some exclusion guidance 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?

Beyond the annotations, the description discloses important behavioral nuance: it is one route with two methods, action=set has two distinct modes (author vs. pin), and it adds concrete validation rules such as require being a non-empty array and min_count constrained to require.length. It also clarifies what action=get evaluates. This adds substantial context beyond the idempotent/destructive hints.

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 dense and front-loaded with the core purpose before expanding into action-specific detail. It is longer than the average tool description, but the length is earned because the tool genuinely has two operations and nested parameter semantics. Some protocol route detail could arguably be trimmed, but it remains relevant to explaining why one tool covers two methods.

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

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

For a complex five-parameter tool with a nested object and no output schema, the description covers most invocation concerns: action semantics, pinning vs authoring, validation constraints, and what get evaluates. It does not describe the response shape or error behavior, which would have made it fully complete given the absence of an output schema, but the core usage is well specified.

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?

Although schema coverage is 100%, the description adds meaning beyond the schema by explaining the behavioral difference between providing and omitting definition, the pinning workflow, the version-ignored-when-pinning rule, and the validation constraints on definition fields. This goes well above the baseline 3 for fully covered schemas.

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

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

The description opens with a specific verb and resource: 'Read or author a task's evidence policy.' It then separates the two operations into action=get (evaluate) and action=set (author/pin), which distinguishes this combined read/write tool from the many sibling get/update tools. This is far from a tautology and gives an agent a precise mental model.

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 explains when each action applies: use action=get to evaluate the pinned policy; use action=set to author/update or pin. It also gives conditional guidance for definition omission versus provision. It does not explicitly name sibling alternatives or exclusions, but the dual-action structure makes the intended usage contexts clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns 'ids and parent context to disambiguate,' which is useful but does not detail pagination, result limits, or exact output format. Given the annotations cover the core behavioral traits, a 3 is appropriate.

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 core purpose. The second sentence provides immediate usage guidance. No wasted words; every sentence earns its place.

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

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

The description covers the tool's purpose, entity types, and usage context. It hints at the return format ('ids and parent context') but without an output schema, a more explicit description of the result structure would improve completeness. Still, for a search tool with 2 parameters and 5 entity types, it is largely adequate.

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%—both parameters have descriptions in the schema. The description adds 'by name' which aligns with the schema's 'case-insensitive substring' but does not provide additional meaning beyond what the schema already states. 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?

The description uses a specific verb ('find') and resource ('projects, task lists, tasks, workers, or condition assets'), lists all entity types, and explicitly contrasts with the alternative of walking the hierarchy. This clearly distinguishes the tool from sibling list and get 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 explicitly states when to use this tool: 'instead of walking projects→lists→tasks or guessing ids from display names.' It implies the alternative (sequential browsing or ID guessing) but does not provide explicit when-not-to-use scenarios, such as when IDs are already known. Still, it offers clear guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context beyond these annotations: it discloses that matches are candidate-level, that detail is per-signal, and that the output is a candidate list intended for the merge process. This goes beyond simply restating the annotations.

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

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

The description is two sentences with the core function front-loaded and the workflow significance in the second sentence. It is appropriately sized, though the parenthetical 'Patent 4 §6.25(b)' reference is cryptic and adds little agent-facing value; the text is still concise overall.

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 read-only, idempotent tool with fully documented optional parameters, the description covers the essential context: what it finds, what signals it uses, and how the output relates to the merge workflow. It does not spell out the exact return shape, but the absence of an output schema and the 'per-signal match detail' phrasing provide sufficient orientation.

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

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

Schema coverage is 100%, and the schema descriptions already explain each parameter well, including the preferred worker_id anchor, the threshold default, and the orphan flag behavior. The description does not add much parameter-level detail beyond the schema, 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 opens with a specific verb and resource: 'Find candidate same-person worker records', which is much more specific than a generic list or search. It also names the concrete signals (phone reuse, name similarity, GPS pattern correlation) and explicitly positions the tool as feeding the merge workflow, distinguishing it from merge_workers and list_workers without needing to open schemas.

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 clear context for when this tool is appropriate: it surfaces duplicate candidates for identity resolution and feeds the merge workflow. It does not explicitly name alternatives or state when not to use it, but the workflow cue is strong enough for an agent to infer the intended usage.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds the worker-scanning context but does not disclose output format or side effects beyond generating a QR code. It adds some value without contradicting annotations.

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

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

A single sentence with no unnecessary words. The key information is front-loaded: action, resource, and purpose.

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

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

Given the tool's low complexity (one param, no output schema), the description adequately covers purpose and usage. It does not explain the return value, but the lack of an output schema makes that omission less critical.

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

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

Schema description coverage is 100% for the sole parameter list_id, which the description echoes ('task list (event)'). The description does not add syntax or format details 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?

The description clearly specifies the action 'Generate' and the resource 'QR code for a task list (event)', with the purpose 'workers can scan to access tasks'. This distinguishes it from sibling tools, as no other tool mentions QR codes.

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 when to use it: when workers need to access tasks via a scannable QR code. It does not explicitly name alternatives or exclusions, but the context of physical scanning is clear enough relative to siblings like tascan_send_task_email.

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

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

Annotations already convey idempotency and non-destructiveness, and the description adds useful behavioral context beyond them: links are stable, evidence reports require admin sign-in to view, service acknowledgments file into the list thread, and SMS delivery is optional. Nothing here contradicts the annotations.

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

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

The description is information-dense and front-loaded with the core action and output. The colon-delimited type list is readable, and every clause contributes meaning, though it is a single long paragraph and could theoretically be tightened without losing value.

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

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

With no output schema, the description still tells the agent the outcome ('get its link') and covers the main decision points: choosing a report type, required IDs, service customization, and optional SMS delivery. It does not exhaustively describe all 9 parameters, but the high schema coverage compensates, and the core calling decision is fully supported.

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 high (89%), so the schema already documents most parameters. The description adds value by explaining what each report type semantically contains, clarifying that list_id vs project_id depends on type, and describing the purpose of service report branding and acknowledgment behavior beyond raw parameter names.

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

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

The description opens with a specific verb-resource pair: 'Mint a shareable report and get its link.' It then enumerates four distinct report types with concrete contents, making the tool's purpose unmistakable and differentiating it from sibling get/list report 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 gives clear context for when each report type is appropriate (completion, service, project, evidence) and states which ID each requires via the schema and prose. It does not explicitly name alternatives like tascan_get_report, but the 'Mint a shareable report' framing strongly implies generation rather than retrieval, and no exclusions are needed beyond the type prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the manifest is truncated at 12000 chars, computing build_ref (sha256 over the manifest), and that binary or over-cap files only store the sha. It also clarifies the discovery semantics, which goes beyond annotations. No contradiction.

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, dense paragraph that packs essential information: purpose, content, computation, truncation, and sibling distinction. Every sentence adds value, front-loading the semantic difference from file reads. No fluff or repetition.

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

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

Given the tool's single parameter, clear annotations (read-only, idempotent), and that the output schema is not provided (but the description describes what the manifest contains), this is complete. An agent can call it correctly, understand what it returns, and know to use tascan_get_build_file for file content. The truncation limit and read semantics are 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?

Schema description coverage is 100%, so the schema already documents build_ref's format (sha256:<64 hex>). The description adds context that build_ref is a SHA256 over the manifest and how to obtain it (from tascan_get_task or tascan_get_cycle_report), which is additional meaning beyond the schema. Slight deduction for not fully detailing the manifest's structure beyond what's listed, but it's adequate for a single parameter.

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 'Manifest of a stored build bundle by build_ref' and details what the manifest contains (files with sha256, byte length, text content status), which precisely identifies the resource and scope. It distinguishes itself from siblings by specifying it is metadata/discovery, not a file read, and explicitly names the sibling for reading a file.

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

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

Explicitly provides usage context: 'Use tascan_get_build_file to read a file', and clarifies that 'Reading the manifest is discovery, not a read of any file'. It explains the protocol version and that build_ref is derived from tascan_get_task or tascan_get_cycle_report, giving clear when-to-use guidance and when-not-to.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds valuable detail: the call is refused if build_sha256 does not match the artifact's stored hash, storing replaces the file's full content going forward, and agent:dispatch permission is required. No contradiction with annotations.

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

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

The description is dense and front-loaded with the core action. Every clause carries useful context, though the long parenthetical about protocol internals and the repeated 'only writes one' could be trimmed without losing meaning.

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

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

For a write-only tool with no output schema and 7 fully documented parameters, this description covers what the tool does, why it exists, its validation rule, its destructive side effect, the lack of any read-back path, and its required permission. An agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100% and each parameter already has a precise description. The prose adds the high-level constraint that build_sha256 must equal the stored artifact hash and repeats that the tool never computes a diff, but it does not materially extend the per-parameter meaning already present 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?

Opens with a specific verb and resource: 'Store an already-computed diff for one file of a build bundle against a base commit.' It also anticipates the misleading tool name by explicitly stating the route is write-only and that no GET path reads a stored diff back, distinguishing it from tascan_get_build/tascan_get_build_file.

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

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

The description gives clear context: the parser has no GET for this path, the deployer precomputes the diff, and this route only validates and stores it. It explicitly says there is no REST route that reads the stored diff back and that this tool only writes one, providing a firm when-not. It does not name alternative tools, but the endpoint references imply them.

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?

Adds substantial behavior beyond the readOnly/idempotent annotations: per-call character cap, offset/limit paging with next_offset, sha256 and byte-length return values, truncation behavior for binary/over-cap files, and the binding semantics of header lines. An agent knows exactly what will happen on repeated or partial reads.

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?

Dense but purposeful: the first clause names the operation, the middle explains limits and output, and the final sentence gives operational guidance for paging and record-binding. No filler; every sentence adds information needed to call or interpret the tool correctly.

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?

Even without an output schema, the description covers the return payload, paging mechanics, sha256/byte-length metadata, binary/over-cap edge cases, and the reviewer-binding semantics. An agent has enough contextual detail to invoke the tool and handle partial or empty results 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 coverage is 100%, so the baseline is 3. The description adds useful semantic context by framing limit/offset as paging over characters, explaining that truncated reads return next_offset, and emphasizing that path must refer to the exact build-listed artifact. This goes slightly beyond the bare schema definitions.

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 action ('Read one file'), a precise resource ('stored build bundle'), and the selection keys ('by build_ref and path'). It also differentiates itself from a working-tree read and from the related tool tascan_get_build, so an agent can tell exactly what this tool is for.

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

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

Gives clear context: this is the read tier for exact executor-produced build artifacts and is what the independent reviewer reads. It implicitly excludes working-tree reads and other list-style build tools, though it does not spell out a formal when-to-use vs. when-not-to-use against each alternative.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses important behaviors: 'Read tier,' default summary-only behavior, the effect of full=true, the 12000-char cap on the complete JSON, and the fact that a computed summary is returned first. These details significantly help an agent anticipate response size and shape without an output schema.

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

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

The description is dense but every clause contributes: scope, contents, summary-first behavior, full mode, size cap, read tier, and notification uniqueness. The main purpose and identifier are front-loaded, and there is no filler or repetition within the description itself.

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

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

With no output schema, the description carries the burden of explaining what the agent will receive, and it does so thoroughly: it lists all report sections, the computed summary fields, the full-JSON option, the size cap, and the root_id resolution path. An agent has enough context to select and invoke the tool correctly even without knowing the exact JSON keys.

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 full and root_id well. The description reinforces the same semantics, including the root_id provenance and the full=true behavior, but does not add substantial new parameter-level meaning beyond the schema. 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?

The description uses a specific verb-plus-resource framing: 'audit report of one coordination cycle by its root task id' and enumerates the exact contents (tasks, runs, completions, verdicts, decisions, ledger events, hash-chain verdicts, spend). It clearly differentiates this from general report/list tools by scoping it to a single cycle and calling it 'the ONLY per-cycle notification surface.'

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

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

The description gives clear context for when to use the tool: when a per-cycle audit report or notification surface is needed. It also provides concrete invocation guidance for root_id: 'returned by tascan_create_cycle; a non-root cycle task returns its root_id in the error.' It lacks an explicit named alternative or when-not-to-use statement, but the 'ONLY per-cycle notification surface' claim effectively rules out sibling notification tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context that an 'event' is a 'task list' and that the response includes its tasks. This goes beyond the annotations to clarify the response scope.

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 clear sentence that is front-loaded with the action and resource, and it includes the key behavioral note about including tasks. There is zero redundant content.

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

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

For a simple read-only operation with one fully documented parameter, rich annotations, and no output schema, the description sufficiently indicates what the tool returns (details plus tasks). No additional context is needed to use it effectively.

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 single parameter list_id is fully documented in the schema ('Task list (event) ID') with 100% coverage. The description only reiterates the 'event/task list' relationship without adding syntax, format, or parameter-specific details 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 verb ('Get'), the resource ('specific event'), and adds the crucial parenthetical '(task list)' to clarify terminology. It also notes 'including its tasks', which distinguishes it from siblings like tascan_list_events (listing many events) and tascan_get_task (fetching a single 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?

The phrase 'specific event' implies this is for fetching one event by ID, but there is no explicit guidance on when to use this versus tascan_list_events for enumeration or tascan_get_task for a task's details. Usage context is implied, not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no extra behavioral context beyond restating the read-only nature. No contradictions with annotations.

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

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

The description is a single concise sentence with no filler words. It directly states the tool's purpose without redundant information.

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

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

For a simple get tool with one parameter and rich annotations, the description is adequate. It does not explicitly define what 'details' includes (e.g., whether it returns tasks within the project), but the low complexity and clear scope make this an acceptable 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 coverage is 100% with the 'project_id' parameter clearly described as 'Project ID'. The description does not add additional meaning beyond the schema, so it relies on the structured definition.

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 resource ('project'), and clearly scopes to a single project via the project_id parameter. It distinguishes from sibling tools like tascan_list_projects (list all) and tascan_get_task (different 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?

The usage is implied by the tool name and parameter: use when you need details for a specific project. However, there is no explicit guidance about when to prefer this over tascan_list_projects or any alternatives, nor any exclusions.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description aligns with these (read operation). It adds significant behavioral context: explains the return contents (summary, JWS, verify URL), verification methods (offline/online), the distinction between outcome and verification.result, and the security caveat about not treating outcome=completed as success without a policy verdict. This goes beyond annotations to disclose how the tool behaves and what the results mean.

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 information-dense but not overly long. It front-loads the primary purpose and source of the required parameter, then covers verification, outcome interpretation, and the profile variant. While comprehensive, it is somewhat dense and could be slightly more scannable, but every sentence provides necessary context. Slight reduction could be made, but it remains focused.

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 read-only tool with rich annotations and fully described parameters, the description covers the essential aspects: what is returned, how to verify, the meaning of key fields, and the security caveat. It even references protocol sections for deeper context. Given no output schema, the description provides sufficient guidance on the return structure and interpretation. It is complete for an agent to use 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 schema already provides descriptions for both parameters with 100% coverage. The description adds value by explaining the completion_id source (from tascan_get_task -> completions[].id) and elaborating on the profile enum's full vs. public distinction, clarifying the public profile's privacy implications. This enriches beyond the schema's own descriptions, though the schema already carries most 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 clearly states the tool fetches a signed Action Receipt for a completed task by completion_id, with a specific identifier source (tascan_get_task -> completions[].id). It distinguishes its purpose from siblings by focusing on receipt retrieval for completed tasks, not creation, listing, or other 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 explains when to use it (for a completed task's receipt) and how to obtain the completion_id, but does not explicitly contrast it with alternative tools for similar purposes (e.g., get_task). It provides context on the profile parameter and the protocol sections referenced, but no direct 'when not to use' guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context the annotations lack: the signed URLs are short-lived (~1h), and include_responses inflates the payload ('default false — keeps the payload light'). This helps an agent reason about freshness and response size.

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 core get action, then the optional flag's effect. Dense but every clause (photo evidence, signed URLs, ~1h lifetime, payload weight) carries information; minor length cost from the parenthetical depth.

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 nested objects, the description carries the return-value burden and does it adequately by listing report contents and the extra fields unlocked by include_responses. It could be more complete on pagination or report scope (all workers vs filtered), but nothing critical is missing 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 coverage is 100%, so baseline is 3, but the description goes beyond the schema by spelling out what include_responses actually returns (submitted numbers, text, choices plus a per-task photo list with fetchable signed URLs) rather than merely restating the field name.

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

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

States a specific verb+resource: 'Get completion report for a task list (event)' and enumerates report contents (task status, completions, workers, photos). It does not explicitly differentiate from close siblings like tascan_generate_report or tascan_list_reports, 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 resource mentioned; there is no when-to-use/when-not or explicit alternative named against tascan_generate_report, tascan_list_reports, or tascan_get_event. The one piece of real guidance is the conditional 'Set include_responses to also return...', which is a parameter-level rather than tool-selection cue.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by enumerating returned fields (GPS + IP + channel, scanner identity, scan→start delta) and explaining the 'sign-in-and-vanish' metric. No contradiction with annotations.

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

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

The description is information-dense and front-loaded with the core purpose, then structured into two clear modes. However, it reads as a single long run-on sentence with many nested parentheticals, which slightly hurts scannability. No wasted words, but the structure could be cleaner.

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?

Since there is no output schema, the description correctly carries the burden of explaining return data, and it does so well: timestamp, GPS+IP, channel, scanner identity, and the delta metric. It does not explicitly state whether combining tag_id with task_list_id/project_id is invalid, and it omits ordering/pagination behavior, but the schema covers limit and filters, making this adequate for a read-only tool.

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

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

Schema description coverage is 100%, so the parameters are already self-documenting. The description adds some meaning by linking tag_id to mode 1 and task_list_id/project_id to mode 2, but this largely mirrors the schema's own parameter descriptions. It does not materially deepen parameter understanding 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?

The description names a specific resource (scan accountability data) and immediately breaks it into two concrete modes: NFC tag scans and QR/link page-open stamps. It distinguishes itself from sibling tools by detailing the exact data returned (GPS, IP, channel, scanner identity, scan→start delta), so an agent can tell it apart from history/listing variants.

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 two-mode structure gives clear selection guidance: pass tag_id for registered NFC tag scans, or task_list_id/project_id for page-scan data. It does not explicitly name alternatives or state when not to use this tool, but the mode differentiation is strong enough for an agent to select correctly.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add context beyond them. It does: it discloses the exact status values the agent should expect (queued/sent/delivered/undelivered/failed) and the presence of carrier error codes, which helps an agent interpret results. This is non-redundant, useful behavioral information consistent with the annotations.

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

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

Two tight sentences with zero filler. The first sentence front-loads the action and key selection criterion; the second enumerates the return states. Every clause earns its place, including the parenthetical that ties the SID to its source 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?

This is a simple single-parameter read-only lookup with 100% schema coverage and full annotations. The description covers what the tool does, how to identify the target message, what outcomes to expect, and that carrier error codes accompany failures. Nothing an agent needs to invoke it correctly is missing; an output schema is not required to explain a flat status list.

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

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

Schema description coverage is 100% — the schema already documents twilio_sid as 'Twilio message SID (SM...) from tascan_send_sms'. The description reinforces that same provenance but adds no new semantic 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?

The description opens with a specific verb and resource ('Check delivery status of a previously sent TaScan SMS'), then narrows the scope by identifying the exact lookup key (Twilio SID) and its source (tascan_send_sms). This makes it immediately distinguishable from the only plausible sibling, tascan_send_sms, without any ambiguity.

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

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

The description establishes clear usage context: this tool is for checking status after sending, and the SID it requires comes specifically from tascan_send_sms. It names the producing sibling, which effectively routes the agent to use this tool only after a send. It stops short of explicitly stating when not to use it or naming competing alternatives, but the pairing with tascan_send_sms makes the intended workflow clear.

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

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

Beyond the readOnly/idempotent annotations, the description importantly clarifies that a completion with status 'completed' does NOT mean acceptance, and that agent policy nuances exist. It discloses the photo URL semantics (stable vs ~1h signed URL) and where failures are reported. This is substantial behavioral context that an agent needs to interpret results correctly, and it does not contradict the annotations.

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

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

The description is dense and front-loaded with the main purpose, and nearly every sentence carries critical caveats or semantics. However, it is a very long single paragraph with nested nuances that could have been structured with bullets or shorter sentences. This is still strong, but not maximally 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?

Even with no output schema, the description covers the essential interpretational pitfalls: the distinction between recorded completion and accepted result, the agent block's failure reporting role, and photo URL lifetimes. It also references specific protocol sections and policy version caveats. For a get-details tool with complex domain semantics, this is complete enough for an agent to act 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 only parameter, task_id, already has 100% schema description coverage via 'Task ID.' The tool description does not add meaningful new detail about the parameter beyond that. Given the high schema coverage, 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?

The description clearly states a specific verb and resource: 'Get details of a specific task including completions and subtasks.' It distinguishes itself from sibling tools like tascan_list_tasks by emphasizing the specific-task scope and its unique contents. The added detail that the agent block is 'the only place agent failures are reported' further reinforces what this tool uniquely provides.

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

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

The description gives clear context for when to use this tool: when you need detailed task details, photo evidence, or agent failure information. It also notes this is the only place agent failures are reported, which is strong usage guidance. It lacks an explicit 'use tascan_list_tasks instead' or when-not-to-use statement, so it doesn't reach the top score.

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?

Although annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds meaningful behavioral details: it returns at most 100 entries, newest last, in reading order, and explains protocol/endpoint context. It also clarifies the kind filtering behavior and the note/discussion alias. This goes well beyond what the annotations provide.

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 compact and information-dense: it covers the action, resource, content type, limit, ordering, filtering, read semantics, and the relevant sibling in two sentences. It is front-loaded with the core purpose and every clause contributes useful information without redundancy.

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

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

For a read tool with rich annotations and fully documented parameters, the description is complete: it identifies required task_id, optional kinds, response contents, ordering, limit, and read-tier safety. It even names the sibling for writes. With no output schema required, the agent has enough context to call this 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?

Schema description coverage is 100%, and the schema already explains both task_id and kinds, including the comma-separated filter and the note/discussion alias. The description reinforces these meanings but does not add significant new parameter-level information 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 opens with a specific verb and resource: 'Read a task's trail messages.' It then specifies the message kinds, ordering, and limit, and explicitly contrasts itself with tascan_post_message via the 'Read tier' note. This makes the tool's purpose unmistakable and distinct from both posting and other task-read tools like tascan_get_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?

The description clearly states the tool is for reading (when to use it) and explicitly routes write operations to tascan_post_message ('Post with tascan_post_message'). It also explains when the optional kinds filter is relevant. This gives the agent explicit context for choosing this tool over its direct sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'Ungated' meaning no special access controls, and 'plain read' clarifying it returns basic fields rather than computed analytics. This goes beyond annotations by specifying the ungated nature and the limited scope of 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?

The description is a single, well-structured sentence that conveys purpose, scope, and sibling differentiation with zero wasted words. It is front-loaded with the most critical information: 'Ungated, plain read of one worker row'.

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 only one required parameter and no output schema, the description is nearly complete. It tells the agent what the tool does, what fields it returns, and how it differs from a rich stats sibling. A small gap is that it doesn't specify what happens if the worker_id doesn't exist (e.g., error or null), but this is minor for a read tool.

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

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

Schema coverage is 100% (one required parameter worker_id with a description). The description does not add parameter-level detail, but with only one parameter and full coverage, the baseline is 3. It earns a 4 by naming the specific fields returned (name, contact, org, points, streaks, timestamps), which helps the agent understand the output shape without an output 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 this tool reads a single worker row and enumerates the fields returned (name, contact, org, points, streaks, timestamps). It also contrasts itself with tascan_get_worker_passport, which provides the 'rich stats view,' making the purpose distinct from a sibling tool.

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 explicitly calls out that this tool is 'Ungated, plain read' and contrasts it with tascan_get_worker_passport ('the rich stats view; this is the boring lookup'), giving the agent clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: data is 'computed from real completion data (not self-reported)', which aids trust and understanding of data provenance. This goes beyond what annotations provide, justifying a 4.

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

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

The description is two sentences, front-loading the primary purpose and listing key output elements without any redundant or filler content. Every sentence adds value, making it efficient and 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?

Despite having no output schema, the description thoroughly explains what the tool returns: task counts, lists worked, photos, GPS hours, points, streaks, badges, and a shareable profile URL. For a simple single-parameter retrieval tool, this covers all essential aspects an agent needs to understand the output.

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

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

Schema description coverage is 100% for the single parameter 'worker_id' (described as 'Worker ID'). The description does not add any further meaning or format details for this parameter, meeting the baseline for high coverage but not exceeding 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?

The description clearly specifies the verb 'Get' and the resource 'worker's verified work passport', listing specific contents such as task counts, photos, GPS hours, and badges. This distinguishes it from sibling get tools for events, projects, etc., and uniquely identifies what this tool retrieves.

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 comprehensive worker passport but does not explicitly state when to use this tool versus alternatives like getting raw task or event data. No 'when not to use' or direct comparisons to siblings are provided, leaving the agent to infer 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?

The description discloses the full consent flow: TaScan texts from its own number, the exact SMS wording, the YES/NO/silence outcomes, the 7-day expiry, and the privacy guarantee that declined workers remain unknown. This goes well beyond the sparse annotations.

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

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

The purpose is front-loaded, and the rest is a tight sequence of consent mechanics, outcomes, and source guidance. The quoted SMS text is illustrative without bloating the description.

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?

Even with no output schema, the description covers the workflow, timing, privacy boundary, and expected aftermath for both the worker and the inviter. An agent has enough to call the tool correctly and understand its consequences.

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. The description adds value by tying worker_id specifically to tascan_search_marketplace and revealing how the optional message is prepended to the consent text.

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

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

The description opens with a specific verb and resource: 'Invite a marketplace worker to a task list.' The phrase 'the consented intro' distinguishes this from direct worker creation or plain SMS tools, making its purpose unmistakable.

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

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

It explicitly says to use 'the worker_id from tascan_search_marketplace,' which provides clear sourcing guidance. It does not explicitly state when not to use it or point to alternatives for existing org workers, but the context strongly implies it is specifically for marketplace-worker invitations.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which tells the agent this is a safe read operation. The description adds that it lists 'all' agents and includes specific fields (capabilities, inbox IDs, status), but does not disclose additional behavioral traits such as pagination, ordering, or authentication requirements. With annotations covering the safety profile, the description adds some value but not extensive contextual detail.

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

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

The description is only two sentences. The first sentence states the action and output; the second provides a memorable metaphor and usage context. Every clause earns its place; there is no redundant filler.

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

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

For a zero-parameter, read-only list tool with no output schema, the description sufficiently covers what the tool returns (capabilities, inbox IDs, status) and its intended use (discovering agents before dispatching). With annotations covering safety and idempotency, the combined metadata is complete enough for an agent to invoke this 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 tool has zero parameters, and the input schema is empty. The description reinforces the lack of filters by saying 'all registered agents,' which aligns with the schema. Since 0 parameters earns a baseline of 4 and there is nothing else to document, this score 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 opens with a clear verb+resource: 'List all registered AI agents' and specifies the output fields ('capabilities, inbox IDs, and status'), distinguishing it from sibling list tools like tascan_list_tasks or tascan_list_workers.

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 context for when to use the tool: 'before dispatching work' (supported by the second sentence). It does not explicitly exclude alternatives or name alternate tools, so it stops short of a 5, but the usage context is clear enough.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context by noting it returns 'latest condition scores' and implies the presence of asset_id fields, which helps the agent understand the return payload. It does not contradict annotations.

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

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

The description is two sentences, front-loaded with the main action and purpose, followed by concrete usage guidance. Every word contributes value, with no repetition or fluff.

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

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

Given the tool's simplicity (one optional param, no output schema), the description is thorough: it explains what is listed (registered condition-ledger assets with scores), the use case (recovering asset_id), and the optional filter is documented in the schema. It provides sufficient context for an agent to invoke 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% for the only parameter (project_id), with a clear description 'Filter by project'. The tool description does not mention parameters, but since the schema fully covers semantics, it meets the baseline of 3.

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

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

The description clearly states the tool's function: 'List registered condition-ledger assets with their latest condition scores.' It uses a specific verb ('List') and resource ('condition-ledger assets'), and distinguishes from sibling list tools by mentioning the specific domain and the inclusion of latest condition scores.

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 explicitly provides usage context: 'Use to recover an asset_id for tascan_assess_condition or tascan_condition_history.' This tells the agent exactly when to use this tool, effectively distinguishing it from other list tools and guiding tool selection.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description's addition of 'Read tier' reinforces safety without redundancy. It adds useful behavioral detail beyond annotations: the specific return fields, the ordering 'newest first', and the protocol/endpoint (v0.2, GET /coord/cycles). No side effects are implied, consistent with annotations.

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

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

The description is a single dense sentence that front-loads the core purpose and lists fields, filters, and follow-up. While packed, every clause earns its place—endpoint, fields, ordering, filters, permission note, and next step—so it is efficient rather than verbose. No fluff.

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 read-only list operation with three optional parameters and no output schema, the description fully equips an agent: it lists all returned fields, specifies ordering, mentions the permission model, and points to a sibling tool for deeper detail. Nothing critical is missing 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?

The input schema provides 100% description coverage for all three parameters (limit, status, project_id), so the schema already explains them. The description only repeats the filter capability ('Filter by project_id and/or status') without adding new meaning or syntax details. Per the rubric, baseline 3 is appropriate when schema carries the load.

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), the resource (coordination-cycle roots), and the scope (in the organization). It enumerates the exact fields returned (root id, title, status, etc.) and ordering (newest first), and distinguishes itself from siblings like tascan_create_cycle and tascan_get_cycle_report by its listing nature and follow-up reference.

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 explicitly states filtering options ('Filter by project_id and/or status') and provides a clear alternative: 'Follow up with tascan_get_cycle_report root_id=... for the full audit trail.' It also clarifies the permission context ('a reviewer's read-only key can call this too'), so an agent knows when this tool is appropriate and when to use a sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context that events are 'task lists' and that they are scoped to a project, but does not disclose pagination, ordering, or return-format behavior. No contradiction with annotations.

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

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

The description is a single, clear sentence that front-loads the verb and resource. Every word contributes meaning, with 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 simple list operation with one required parameter and strong safety annotations, the description adequately conveys purpose and scope. It does not specify return fields, but no output schema exists and the tool's behavior is sufficiently implied for an AI agent.

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

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

The schema fully documents the single parameter project_id with 100% coverage. The description adds no additional parameter semantics beyond the implicit project scoping, 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 uses a specific verb ('List') with a clear resource ('events (task lists)') and scope ('within a project'), making the tool's purpose immediately understandable. It also distinguishes from the singular tascan_get_event and other list tools by explicitly stating it lists all events.

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 use case is implied: use this tool to list all events in a project. However, there is no explicit guidance on when to prefer this over alternatives like tascan_get_event or tascan_list_tasks, and no when-not-to-use conditions are stated.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail beyond that: accepted invites include the worker's name and phone, forming a consent boundary, while pending and declined invites never expose that data. This is important context about data sensitivity and response contents.

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 with no wasted words. The core verb and resource are front-loaded, followed by status enumeration and the consent-boundary caveat. Every sentence earns its place.

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

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

Given the low complexity (one optional parameter), rich safety annotations, and no output schema, the description is complete enough for an agent to use the tool correctly. It covers the resource, the filtering concept, the status values, and the key behavioral caveat about PII. No critical information is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It repeats the enum values (pending / accepted / declined / expired / failed), which helps, but it does not explicitly explain that the optional 'status' parameter filters results or what omitting it returns. The meaning is partially conveyed but not fully specified.

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

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

The description uses a specific verb ('List'), a precise resource ('marketplace invites you have sent'), and enumerates the status categories. This clearly distinguishes it from siblings like tascan_invite_worker (sending) and tascan_search_marketplace (searching). An agent can immediately understand what the tool does and what it does not do.

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 when to use the tool: whenever you need to see the status of invites you have sent. However, it does not explicitly name alternatives or state when not to use it, such as 'use tascan_invite_worker to send invites instead.' The context is clear but the exclusion guidance is left 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond that: it specifies the sort order ('newest first') and enumerates the returned invoice fields, which helps an agent set expectations for the output. It does not mention pagination or result limits, but those are minor for this kind of read-only list.

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

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

The description is a single, well-structured sentence that leads with the core action and resource, then provides output fields and filter options. Every part is useful and there is no redundancy with the schema or annotations.

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

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

For a simple read-only list tool, the description covers the essential details: what is returned, the ordering, and the available filters. There is no output schema, so the explicit field list is valuable, though pagination and result-size behavior are not mentioned. This is a minor gap given the low complexity of the 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 0%, so the description bears the burden of explaining parameters. It adds meaning by stating that invoices can be filtered by status or project and by repeating the status enum values, but it does not explain the project_id format, required fields, or how filters interact. Overall it partially compensates for the schema gap but leaves room for more detail.

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

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

The description clearly states the verb ('List'), the resource ('invoices'), the scope ('for the org'), and the ordering ('newest first'). It also lists the returned fields and available filters, making it easy to distinguish this tool from create/update invoice tools and other 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?

The description implies usage through the tool name and 'List invoices for the org,' and the filter options clarify what the tool accepts. However, it does not explicitly state when to prefer this over related list tools such as tascan_list_payments or tascan_list_projects, nor does it give any when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds behavioral context beyond this by stating the scope ('all issues'), the statuses included (open, acknowledged, resolved), and the fields returned (severity, type, category). This is meaningful, though it does not cover pagination or authorization.

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

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

The description is two sentences, front-loaded with the action and resource, followed by a useful downstream-use note. Every sentence earns its place with no redundancy or filler.

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

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

For a simple one-parameter read-only tool with rich annotations, the description fully covers what the tool does, what it returns, and why it is used (to feed into tascan_analyze_issue). It is well-suited to guide an AI agent in selecting and invoking the tool.

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

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

Schema coverage is 100%, with list_id described as 'Task list (event) ID'. The description repeats this term but does not add further parameter-level details. Therefore, the schema carries the parameter semantics, and the description adds no extra value beyond the baseline.

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

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

The description uses a specific verb-resource pair ('List all issues for a task list (event)') and clearly distinguishes from siblings like tascan_list_tasks (tasks vs issues) and tascan_list_events (events only). It further specifies the returned data (open, acknowledged, resolved issues with severity, type, category), making the purpose unmistakable.

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 a clear usage context: 'Use this to discover issues that need AI analysis via tascan_analyze_issue.' This implicitly guides the AI to use this tool before analysis. It lacks explicit exclusions or alternatives, but the intended workflow is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining the lifecycle statuses (e.g., 'awaiting_completion' means pledged, work not verified), giving the agent behavioral context beyond the safe read operation. No contradictions with annotations.

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

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

The description is a single, front-loaded sentence that efficiently states the purpose, explains lifecycle statuses, and notes filtering options. Every word serves a purpose, with no redundancy or verbosity.

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

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

For a simple read-only list tool with 2 optional parameters and no output schema, the description adequately covers the purpose, status meanings, and filtering. It could mention potential limitations like pagination or result size, but overall it provides sufficient context for an agent to use the tool effectively.

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 both parameters ('status' and 'task_list_id') already clearly documented in the schema. The description merely restates that filtering is by task list or status, adding no additional meaning beyond what the schema provides.

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

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

The description clearly states the tool lists gig payments and explains their lifecycle statuses with specific meanings. It uses a specific verb ('List') and resource ('gig payments'), and distinguishes itself from sibling list tools (e.g., list_tasks, list_workers) by specifying 'payments' and detailing statuses.

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 listing payments but provides no explicit guidance on when to use this tool vs alternatives like tascan_list_tasks or tascan_request_payment. There are no exclusions, conditions, or comparative context given, leaving the agent to infer from the purpose 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds organizational scope ('in the organization') but does not disclose behaviors like pagination, ordering, or return format. This adds some value beyond annotations but not rich detail.

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

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

The description is a single concise sentence with no filler or redundancy. It states the verb, resource, and scope efficiently, earning every word.

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

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

For a zero-parameter list tool with strong annotations (read-only, idempotent, non-destructive), the description is largely complete. It clarifies scope ('all ... in the organization') and implies the return of a list of projects. Without an output schema, it could specify return value structure, but the low complexity makes this 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 has zero parameters, so there is nothing about parameters that needs explanation. The baseline for 0 params is 4, and the description makes this explicit by stating it lists all projects without filters.

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

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

The description uses the specific verb 'List' and names the exact resource 'TaScan projects' with an explicit scope ('in the organization'). This clearly distinguishes it from sibling tools like tascan_get_project (single project) and tascan_create_project.

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 need all TaScan projects in the organization. However, it does not explicitly state when not to use it or mention alternatives such as tascan_get_project for retrieving a single project.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral details beyond annotations: results are 'newest first' and include 'client acknowledgment status for service reports'. It could additionally state what happens when neither parameter is provided, but it does not contradict the annotations.

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

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

A single, information-dense sentence that front-loads the action and resource, then adds scope, ordering, and return-content details. Every phrase earns its place and no filler is present.

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

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

With no output schema, the description appropriately conveys what the return contains: report links, ordering, and acknowledgment status. It is reasonably complete for a read-only listing tool, though a note about parameter requirements or behavior when both IDs are absent would make it fully 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 schema provides only bare string property names with no descriptions, so the description must compensate. It does so by explaining that the tool operates 'for a list or project', mapping directly to list_id and project_id. While it does not discuss the no-required-parameters case or mutual exclusivity, the two parameters are simple and the description gives adequate meaning.

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

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

The description uses a specific verb ('List') with a clear resource ('existing report links'), and precisely scopes the operation to a list or project with report categories. It clearly distinguishes itself from siblings like tascan_get_report and tascan_generate_report, which would retrieve or create reports rather than list existing links.

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

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

The description gives clear contextual guidance: use this when you need report links for a list or project, and it even enumerates report types. It does not explicitly name alternatives or state when not to use it, but its context is strong enough for an agent to infer the appropriate use case.

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

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

Annotations already establish readOnly, idempotent, non-destructive behavior. The description adds valuable behavioral context by revealing default status filtering, chronological ordering, and the exact row fields (send_at, status, attempts, Twilio sid, last error). No contradiction with annotations exists.

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

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

The description is two tight sentences with no filler. The most important operational detail (default statuses and ordering) is front-loaded, and the output fields are listed compactly in the second sentence.

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

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

For a simple read-only list tool with one optional parameter and no output schema, this description is complete: it covers the default behavior, how to access history, ordering, and the relevant fields in each row. Nothing essential is missing 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?

The schema already documents the status parameter with 100% coverage, but the description adds meaning beyond it by explaining that status=sent|failed|cancelled reveals history and by clarifying the default behavior of pending + sending. This helps an agent choose the right parameter value without needing to infer semantics from the enum alone.

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

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

The description uses a specific verb and resource ('List your org's scheduled texts') and clearly differentiates this from siblings like tascan_schedule_sms, tascan_send_sms, tascan_get_sms_status, and tascan_cancel_scheduled_sms. It also conveys the default scope and the kind of data returned, leaving no ambiguity about what this 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 provides clear context on when to use the default view versus when to pass status=sent|failed|cancelled to see history. It does not explicitly name alternative tools or state when not to use this tool, but the guidance is sufficient for a simple read-only list 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?

The annotations already establish this as read-only, idempotent, and non-destructive. The description adds meaningful context beyond those annotations by disclosing the kind of data returned: completion state, stored response values, and per-set completion timestamps. There is no contradiction between the description and the readOnlyHint.

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, tightly worded sentence that front-loads the primary action and resource, then appends relevant output details. Every part of the sentence adds information, with no filler or repetition.

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

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

For a simple, one-parameter read-only tool with rich annotations, the description covers the main purpose and key returned fields. The phrase 'per-set timing' and 'stored response values' are somewhat ambiguous, and there is no output schema to clarify them, but overall the description is sufficient for an agent to correctly invoke the tool and interpret the result at a basic level.

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 only one parameter, task_id, and the schema already describes it as 'Parent task ID' with 100% coverage. The description does not add additional parameter details beyond what the schema provides, but it does not need to because the schema fully documents the parameter's meaning.

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

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

The description uses a specific verb and resource: 'List the subtasks of a task.' It also enumerates what is included (completion state, stored response values, completion timestamps), which clearly distinguishes it from similar tools like tascan_list_tasks or tascan_get_task. An agent can immediately tell what this tool does without needing to open the schema.

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

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

The description implies when to use the tool: whenever you need the subtasks of a given task. However, it does not explicitly compare with alternatives or state when not to use it, such as when listing top-level tasks or querying response history instead. The usage guidance is adequate through implication but not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the content of the output (linked projects/task lists, scan counts). This extra context helps an agent understand what data to expect beyond the safety profile.

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

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

The description is a single sentence that efficiently communicates the tool's purpose and the key additional information provided. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool has no parameters and no output schema, the description sufficiently covers what the tool does and what the response contains (list of tags with linked project/task list info and scan counts). There are no gaps for this simple read 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?

The tool has zero parameters, and the input schema coverage is 100% (vacuous). Per guidelines, baseline for 0 parameters is 4. The description adds no parameter semantics because none are needed, and that absence 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 it lists all registered NFC tags, specifying the included details (linked projects/task lists and scan counts). This distinguishes it from sibling tools like tascan_register_tag and other 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?

The description does not provide explicit guidance on when to use this tool versus alternatives. While the name and purpose are clear, there is no mention of suitable contexts or exclusions, leaving selection 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the event/task list scoping, but doesn't disclose any further behavioral details such as output shape or pagination. With annotations present, the added value is modest.

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 that states the action and scope with no filler. 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 one well-documented parameter and strong annotations, the description is largely complete. It clearly identifies the target resource and scope, though it might ideally mention that it returns a list of task records. No output schema exists, so the description carries that burden, but the intent is unambiguous.

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 fully documents list_id as 'Task list (event) ID' with 100% coverage. The tool description merely echoes this relationship ('in an event (task list)') and adds no new semantic information 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 'List all tasks in an event (task list)' uses a specific verb (List) and resource (tasks in an event/task list), clearly distinguishing it from sibling tools like list_events or get_task. The parenthetical clarifies the scoping.

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 implies when to use this tool (when you need all tasks within a specific event/task list), but it doesn't explicitly state alternatives or situations where another tool should be used. This is clear context without exclusions.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds little beyond confirming it lists templates; it does not disclose additional behavioral traits like pagination, ordering, or result format, which is acceptable given the annotations.

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

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

The description is a single sentence that is concise, front-loaded with the action, and contains no redundant information. Every word adds value.

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

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

For a simple list tool with no output schema and only one optional parameter, the description provides sufficient context. It clarifies that both built-in and saved templates are included, which covers the key aspect of what the user receives.

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 only parameter 'category' is fully described in the schema with a description and example values (100% schema coverage). The tool description adds no additional parameter semantics, 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 states the verb 'List' and the resource 'task templates', specifying scope as 'built-in and saved'. This distinguishes it from sibling tools like tascan_list_tasks or tascan_apply_template, which serve different resources or actions.

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 templates but does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of alternatives such as tascan_apply_template, leaving usage guidance implied rather than explicit.

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