TaScan

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

The description adds useful behavioral context beyond the annotations by explaining that subtasks support typed responses and that each completed set stores its value and timestamp for progression tracking. However, it does not disclose side effects such as whether subtasks are appended to existing ones, what happens on invalid task_id, or whether creation is atomic. Given the minimal annotations, these gaps leave some behavioral uncertainty.

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 primary purpose and each subsequent sentence carries useful information about response types and the set-logging use case. The example is valuable but slightly niche and could have been trimmed without losing core clarity. Overall it is appropriately sized 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?

For a bulk-creation tool with a nested subtasks array and six sub-parameters, the description covers the most non-obvious behavior: response_type semantics and the set-logging workflow. It does not describe the return value or error behavior, but no output schema exists and the input schema sufficiently documents the other parameters. An agent would have enough context to invoke this tool correctly in typical scenarios.

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 for this dimension is 3. The description goes beyond the schema by explaining the practical meaning of response_type values ('number' for per-set data, 'text' for notes, etc.) and illustrating with the Bench Press example. This adds genuine semantic value to the response_type parameter that the schema enum 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?

The description opens with a specific verb and resource: 'Add one or more subtasks to a task (bulk).' This clearly differentiates from sibling tascan_add_tasks by specifying subtask scope and the parent task association. The bulk aspect is also explicitly stated, leaving no ambiguity about what the tool does.

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

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

The description provides a concrete set-logging example that implies when this tool would be useful (recording per-set data like reps or weight), but it does not explicitly state when to use this tool over alternatives like tascan_add_tasks or tascan_update_subtask. No exclusion criteria or alternative routing is provided, so an agent must infer usage from the example.

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 are sparse (all boolean hints false), so the description carries the transparency burden. It adds genuinely behavioral guidance beyond the annotations: the IMPORTANT rule for selecting response_type by outcome ('text' for info collection, 'photo' for visual verification, 'checkbox' only for simple confirmations) and the routing warning about the agent's inbox. It stops short of describing side effects or confirmation behavior of a state-changing write, but the delivered guidance prevents the most likely agent errors. 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?

Three sentences, each with a distinct job: purpose, critical decision guidance, and inter-tool routing. The most important operational warning (response_type) is front-loaded immediately after the purpose, and the alternative-tool note is deliberately separated with 'NOTE'. Every sentence earns its place; there is no filler, boilerplate, or meta-commentary.

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 mutating tool with no output schema and a moderately complex input (array of task objects with ten properies), the description covers the highest-risk decisions: correct response_type selection and correct tool routing. Combined with the 100%-covered schema, an agent can invoke it correctly. The remaining gaps — what is returned on success, confirmation/created IDs, prerequisites like the event existing — are not fatal given the informatinal depth of the schema, but they keep it from being 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 the schema itself is unusually rich — the response_type parameter already contains a 'CRITICAL:' note covering text/photo/checkbox/choice semantics, and assigned_to explains UUID validation and worker-portal matching. The description's response_type summary therefore largely distills information alread in the schema rather than adding new meaning. It does provide a one-line memorable heuristic and reinforces the bulk-creation capabilit, which is marginal value over 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 opens with a specific verb-resource-target triplet: 'Add one or more tasks to an event (task list)' and adds a meaningful capability ('Supports bulk creation'). It explicitly distinguishes itself from the closest confusable sibling, tascan_dispatch_to_agent, stating that tool 'routes directly to the agent's inbox' — so an agent can pick the right tool without opening 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 NOTE sentence gives an explicit when-not-to-use condition ('To dispatch tasks to the Claude Code agent running on Mike's PC, use tascan_dispatch_to_agent instead') with a named alternative and its benefit ('zero configuration needed'). The main use case (adding tasks to an event) is implicit in the first sentence. It does not contrast with tascan_add_subtasks, but that gap is minor since the resource names already differ.

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?

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 adds behavioral context beyond the annotations, noting that it 'Inserts a completion record and timer event.' This informs the agent about side effects and persistence, which is especially valuable since annotations only provide booleans like readOnlyHint=false and destructiveHint=false. 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 two sentences, front-loaded with the primary action, followed by side effects and usage. Every sentence contributes value without 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?

Given the tool's simplicity and lack of output schema, the description covers purpose, side effects, and usage adequately. It could mention prerequisites (e.g., task must exist) or return behavior, but these are not essential for a task completion tool with well-defined parameters.

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 does not add significant parameter semantics beyond what the schema already explains; it only reaffirms the role of worker_id ('on behalf of a worker') and hints at response_value via 'simulate,' but these are already covered.

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 what the tool does: 'Complete a task on behalf of a worker' and specifically mentions the side effects: 'Inserts a completion record and timer event.' This distinguishes it from siblings like tascan_update_task or 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?

The description provides clear context for when to use: 'Use this to simulate or record task completions via the API.' It does not explicitly mention when not to use or list alternatives, but the use case is clear enough to differentiate from updating or deleting tasks.

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

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

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?

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?

Annotations establish the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds behavioral consequences beyond those hints: the Site Gate routing mechanism and the enforce_on_list=true zone-lock effect. It stops short of disclosing creation-time side effects like auto_clock_in events or alert emails, but the primary operational behavior is transparent.

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 with the purpose statement front-loaded in the first clause. Compact and readable; the only mild redundancy is the enforce_on_list sentence, which duplicates information already present in the schema.

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

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

For a 22-parameter tool with no output schema, the description conveys the core operational behavior (geofenced routing and list-locking) while the richly documented schema covers parameter detail. It is sufficient for correct invocation, though it offers no return-value signal or duplicate-creation caution (the latter is partially mitigated by idempotentHint=false).

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 22 parameters are already documented and the baseline is 3. The description's only parameter-specific content ('Set enforce_on_list=true to zone-lock the task list') largely restates the schema's own description of enforce_on_list rather than adding new 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?

Opens with a specific verb+resource ('Create a geofenced work zone') and defines the entity's behavior: routing Site Gate workers to the zone's task list when GPS places them inside the radius. This clearly distinguishes it from the create_* siblings such as create_project, create_worker, and create_event 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 it by explaining what zones do (delivery routing from Site Gate), but it gives no explicit when/when-not conditions and never names alternatives such as tascan_update_zone for modifying an existing zone or tascan_list_zones for viewing them. Usage context exists, but decision criteria are 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 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?

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?

The description adds valuable behavioral context beyond the annotations: tasks are 'picked up and executed automatically', routing prefixes are supported, and the default agent is claude-code-local. It also clarifies that no list ID is needed, which is useful. It does not contradict the annotations (readOnlyHint false, non-destructive).

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 tool's primary purpose, using only a few sentences. Each sentence provides actionable information (routing prefixes, agent targeting, no list ID). 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?

Given the tool's simplicity and 100% schema coverage, the description covers purpose, routing, and agent selection. It omits return value details, but there is no output schema and execution results are implicitly covered by 'executed automatically'.

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

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

The schema already provides 100% coverage for all three parameters, so the baseline is 3. The description adds some context for the `agent` param by confirming the default and prompting discovery via tascan_list_agents, but it doesn't meaningfully enhance parameter semantics beyond the schema.

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

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

The description clearly states it is the 'PREFERRED tool for sending work to an AI agent' and describes dispatching a task to the agent's inbox, distinguishing it from sibling tools like tascan_dispatch_instruction. The verb 'dispatches' and resource 'task to agent's inbox' make the action explicit.

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

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

It declares itself as the 'PREFERRED tool' and explains when to use it, along with the note that no list ID is needed, differentiating it from other task tools. It also instructs to use tascan_list_agents to discover available agents, providing a clear usage path. However, it doesn't explicitly mention alternatives to avoid, so it falls 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?

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 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, destructiveHint false, so the read-only behavior is clear. The description adds value by listing the specific data elements returned (status, completions, workers, photos, responses), providing concrete behavioral context 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?

Two sentences: first states the core purpose, second explains the optional parameter. Every sentence earns its place, no wasted words, and 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?

No output schema exists, so the description must compensate. It adequately describes the return contents (status, completions, workers, photos, responses) and the effect of include_responses. Minor ambiguity about whether the report includes all tasks or only completed ones, but overall sufficient for the tool's 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 the structured definitions for list_id and include_responses are already clear. The description reinforces the include_responses parameter with examples ('numbers, text, choices') but adds minimal new meaning beyond the schema description.

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 clearly states the tool retrieves a completion report for a task list (event) with specific data fields: status, completions, workers, photos, and optionally responses. This distinguishes it from sibling tools like tascan_get_event (event details) and tascan_get_task (task details).

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 getting a completion report but does not explicitly indicate when to use this tool versus alternatives like tascan_get_event or tascan_list_tasks. No exclusions or comparative guidance provided, which is a missed opportunity given the many sibling 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 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds the behavioral detail of returning completions, but it does not disclose error behavior, auth requirements, or pagination. Since annotations carry the main safety burden, a score of 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?

The description is a single, front-loaded sentence that immediately states the action and resource. There is no redundancy or filler, earning a perfect score for conciseness.

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

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

For a simple get-by-ID tool with one parameter and no output schema, the description is reasonably complete. It indicates the task details and completions will be returned, but does not mention potential error responses or the exact structure of the output. Given the simplicity, this is a minor gap, hence a 4.

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

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

The schema describes task_id as 'Task ID' with 100% coverage, so the description does not need to add parameter details. The word 'specific' in the description aligns with the single required ID parameter but adds no extra semantic value beyond the schema.

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

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

The description clearly states the action ('Get details') and the specific resource ('a specific task'), distinguishing it from sibling tools like tascan_list_tasks. The addition of 'including completions' clarifies the scope of the retrieved data, making the purpose unambiguous.

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

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

The description implies this tool is for retrieving details of a single task by ID, but it does not explicitly state when to prefer it over alternatives like tascan_list_tasks, nor does it mention any exclusions or prerequisites. The usage context is clear but not elaborated.

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

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.

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 fully covered by structured data. The description adds modest value by disclosing that each row includes completion_count, which hints at return shape, but it doesn't disclose pagination, result limits, or default inclusion of inactive workers. 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?

Two sentences with zero waste: the first front-loads the verb/resource and lists the filter dimensions, and the second discloses the notable output field. Every sentence earns its place and the most decision-relevant information appears first.

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 listing tool with 5 optional parameters fully documented in the schema, the description is nearly complete: purpose, filter capabilities, and one key output signal are covered. The only gap is the absence of an output schema and no mention of result ordering or pagination, which is a minor omission given the annotations already carry the safety profile.

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 loosely mirrors the schema by mentioning name/email/phone substring, contact-info presence, and last-activity date, but it adds no syntax, format, or semantics beyond what the parameter descriptions already provide.

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

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

The description states a specific verb ('List') and resource ('workers (taskees)') and immediately differentiates the tool from sibling list tools like tascan_list_agents and tascan_list_assets by naming the worker resource and its key output field (completion_count). An agent can tell exactly what this tool returns without opening 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 usage context by enumerating supported filters, but it never explicitly states when to choose this tool over alternatives such as tascan_get_worker, tascan_find_duplicate_workers, or tascan_list_tasks. The auditing-after-merge guidance lives only in the schema's include_inactive parameter description, not in the tool description itself, so usage guidance is present but 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, signaling safe read-only behavior. The description adds value by specifying exactly what fields are returned (center, radius, routing target, zone-lock status), which aids the agent in understanding the output. No contradictions with annotations. Could further note ordering or pagination, but it's solid.

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 succinct sentences: the first states the core function and optional filter, the second lists returned fields. Every word earns its place, no fluff. Front-loaded with the primary action, making it easy to scan.

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 this is a simple list tool with one optional parameter and no output schema, the description is fairly complete. It explains what data is returned. However, it does not clarify whether omitting project_id lists all zones across all projects or if there is a default scope. Minor gap but still good.

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 describes the sole parameter (project_id: 'Filter by project') with 100% coverage. The description echoes this ('optionally filtered by project') but adds no new semantic meaning beyond the schema. The description also includes output details unrelated to input parameters. Baseline 3 is appropriate given high 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 tool lists geofenced work zones, specifying the resource and action. It also details the optional filter by project and enumerates the displayed fields (center, radius, routing target, zone-lock status), making it distinct from sibling list tools like list_projects or list_tasks.

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

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

The description implies usage when the user wants to list geofenced zones, optionally filtering by project. However, it offers no explicit guidance on when to use this tool versus alternatives (e.g., list_tasks, list_events) or when not to use it. The context is clear but lacks exclusions or comparative advice.

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 destructiveHint=true and readOnlyHint=false, but the description goes far beyond: it lists the reassignment scope (31 columns across 31 tables), the tombstone mechanism (merged_into + is_active=false), explicitly prohibits hard-deletes, and documents dry-run versus atomic behavior. This is exemplary disclosure for a destructive 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 dense but every sentence earns its place: purpose, scope, tombstone behavior, safety rule. Critical information is front-loaded, and the mandatory dry-run instruction is placed last for emphasis. No filler or repetition of schema details.

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 high-complexity, destructive merge tool with no output schema, this description is remarkably complete. It covers what happens to references, primary fields, points, duplicate records, and the exact execution protocol. The absence of an output schema is mitigated by describing dry_run as 'report reassignment counts only.' Nothing an agent needs to call this tool safely 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 100%, and parameter descriptions already explain primary_worker_id ('canonical worker that survives'), duplicate_worker_ids ('max 20'), and dry_run ('true (default) = report counts'). The description adds context about backfilling and summing but does not materially change parameter understanding 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 opens with a specific verb and resource: 'Merge duplicate worker records into one canonical identity (Patent 4 identity consolidation).' It details the exact scope of the operation, including reassigning references, backfilling contact info, summing points, and tombstones duplicates, which clearly distinguishes it from sibling tools like delete_worker or update_worker.

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 workflow instructions: 'ALWAYS run with dry_run=true first and show Mike the counts; pass dry_run=false only after explicit confirmation.' It also implicitly distinguishes from hard-delete via 'NEVER hard-deletes.' However, it does not explicitly name alternative tools or state when to prefer this tool over a sibling like tascan_delete_worker, so it falls just short of a 5.

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

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

Beyond the annotations (read-only, idempotent, non-destructive), the description reveals important behavioral details: matching via title pattern or exact ID, subtask completions interleaved as 'Task › Subtask', per-set values with their own timestamps, and automatic chronological progression across lists. No annotation contradiction 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 carry distinct, valuable information: the core aggregation behavior, a motivating example, and subtask interleaving details. The final sentence is dense but every clause earns its place; no filler or redundancy warrants a 5.

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

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

With no output schema, the description appropriately explains the return shape as a chronological progression series with interleaved labeled subtasks. It covers the most essential behavioral expectations, though it omits exact response fields and edge-case behavior, which keeps it one step from 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?

The input schema already describes all three parameters at 100% coverage, including the task matching semantics and limit range. The description adds no new parameter-level meaning beyond restating that matching can be by title pattern or ID, 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 states a specific verb ('Query') and precise resource ('one task's submitted responses across every list in a project'), clearly distinguishing it from single-task or single-list tools like tascan_get_task and tascan_list_tasks. The cross-list aggregation and chronological-series behavior make the tool's 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?

Provides a concrete motivating scenario ('same exercise repeated across many workout lists') and frames the result as replacing N report lookups, which signals when this tool is preferable. It does not explicitly name a sibling alternative or state exclusions for single-list queries, so it falls 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?

Annotations are generic (readOnly=false, destructive=false), so the description adds meaningful behavioral context: the recommendation is 'persisted in the AI audit trail' and the tool 'accepts' both text and structured recommendations for auto-dispatch. This clarifies the write side-effect and audit trail integration beyond what annotations state. No contradiction found.

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—three sentences—with the core action and protocol step presented first. Every sentence earns its place: action, parameter flexibility, and persistence behavior. No fluff 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 write-only tool with a nested structured parameter and no output schema, the description sufficiently covers the purpose, optional vs required inputs, and the audit-trail persistence. It could mention response behavior, but the absence of an output schema lowers that burden. The protocol step context further helps the agent decide when to invoke.

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%, giving the baseline of 3. The description adds value by explaining that structured_recommendation contains 'task definitions for auto-dispatch,' which clarifies the semantic purpose of that complex nested parameter beyond the raw format in the schema. This extra context elevates the score.

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 ('Post') and identifies the exact resource ('AI-generated recommendation to an issue thread'), naming it as 'Step 2 of the Closed-Loop Autonomous Operations Protocol.' This makes the tool's role clear and distinguishes it from sibling tools like tascan_analyze_issue or tascan_auto_resolve by focusing on issuing a recommendation rather than analyzing or directly executing.

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 statement 'Step 2 of the Closed-Loop Autonomous Operations Protocol' provides clear contextual when-to-use guidance, implying it follows issue analysis and precedes auto-dispatch. However, it does not explicitly state when not to use this tool or name alternative tools, leaving minor ambiguity.

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 idempotency and non-destructive behavior. The description adds useful behavioral context: the registered agent will appear in tascan_list_agents and can receive dispatched tasks. It does not disclose edge cases like duplicate ID handling or auth requirements, but supplements the annotations well.

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 that front-load the primary action and immediately provide key behavioral outcomes. Every word earns its place, with no unnecessary 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?

The description covers the main purpose and post-registration effects, and the schema fully documents all parameters. It omits error/edge cases such as duplicate IDs or permissions, but given the tool's moderate complexity and good annotations, it is sufficiently complete for effective use.

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%, meaning all 9 parameters are fully documented in the input schema. The description adds no additional parameter-level meaning, so a 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: registering a new AI agent in the agent registry. It further distinguishes itself by noting the agent will appear in tascan_list_agents and can receive dispatched tasks, which is specific and unique among siblings.

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

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

The description provides clear context: 'Self-registration for AI agents joining the TaScan network' implies when this tool should be used. However, it does not explicitly exclude alternatives like tascan_create_worker or mention scenarios where this tool should not be used, 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 that each asset gets a longitudinal condition history with AI scoring and degradation trajectory, adding behavioral context beyond the annotations. Annotations indicate readOnlyHint=false and destructiveHint=false, aligning with a creation operation. The description provides useful outcome details but does not cover authorization or rate limits.

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 verb and resource, and no wasted words. The description is efficient and immediately conveys the tool's 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?

For a registration tool with no output schema, the description explains the outcome (condition history, AI scoring) but lacks details on error handling, idempotency (annotations say idempotentHint=false), prerequisites, or what happens if the asset already exists. The missing parameter documentation for two fields also reduces completeness.

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

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

Schema description coverage is 67% (four of six parameters have descriptions). The main description does not explain individual parameters beyond the schema, and it fails to compensate for the two missing parameter descriptions (project_id, location_description). The description adds general context but not parameter-specific 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 verb 'Register' and the resource 'physical asset in the condition ledger' with examples (equipment, structure, vehicle, machine). This differentiates it from sibling registration tools like tascan_register_agent or tascan_register_tag by specifying the asset focus.

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 before assessment tools ('so it can be assessed over time'), but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No direct comparison with siblings or exclusion criteria is 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?

Annotations already indicate this is a non-read-only, non-destructive, non-idempotent write operation. The description adds useful behavioral context: the routing effect when tapped and the hardware chip requirement (NTAG215, NFC Tools Pro). However, it does not disclose what happens on duplicate registration, validation checks, or whether the operation is reversible.

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

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

The description is extremely concise at two sentences. The first sentence contains the core purpose ('register a physical NFC tag to a project, task list, or specific task'), and the second adds value by explaining the tapping behavior and hardware requirements. There is no unnecessary 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 tool with 7 parameters and no output schema, the description lacks important context: it does not explain what the tool returns (e.g., success status, created registration ID), how to obtain the tag_hardware_id, or whether duplicate hardware IDs are handled. The schema descriptions cover individual parameters, but the overall workflow and error conditions are 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?

The input schema already has 100% description coverage, with clear parameter descriptions for all 7 properties. The tool description does not provide additional meaning for any specific parameter beyond what the schema already contains, so it meets the baseline for a high-coverage 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 action: 'Register a physical NFC tag to a project, task list, or specific task.' It also explains the resulting behavior ('When someone taps the tag, TaScan routes them to the linked resource') and mentions hardware specifics. This distinguishes it from sibling tools like tascan_list_tags.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The only implicit context is that it is for physical NFC tag registration, but no differentiation from other Tag-related tools (e.g., no 'Use this for new tag registrations only' or 'Do not use if the tag is already registered').

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 are minimal (readOnly=false, destructive=false, etc.), so the description carries the burden of behavioral disclosure. It discloses the side effects: 'The org gets pinged; the thread shows in both the worker portal and Simple Mode.' It also explains that the created list is linked into the parent's thread and aimed at the sender. It doesn't mention reversibility or whether the creation is idempotent, but annotations already signal non-idempotent and the description covers the essential side-effect context.

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

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

The description is a single compact paragraph with the core purpose front-loaded and valuable examples included. Every sentence contributes: purpose, mechanics, side effects, and follow-up guidance. It is slightly dense with examples and inline tool references, but avoids fluff and remains scannable.

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 complexity (creating a list with typed tasks, response_config, threading), the description covers the main conceptual pieces: what the tool does, what happens in the UI, how recipients answer (typed tasks), and how to read the answers. No output schema exists, so return format is not described, but the description points to tascan_list_projects/tascan_get_report for reading answers. Minor gaps: no mention of author_name defaults or whether parent_list_id must be a list rather than a project, but overall 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?

Schema description coverage is 100%, so the schema fully documents parameter meanings. The description adds extra semantic value by explaining response_type usage ('date' for scheduling windows, 'text' for info requests, 'choice' needs response_config.options) and providing example titles. It doesn't describe author_name behavior, but the schema already states 'shown in the thread.' The description enhances rather than repeats the structured data.

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

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

The description clearly states the tool's purpose: 'Reply to a task list WITH a task list — the two-way tasking primitive.' It specifies the verb (reply/creates), the resource (a new list linked into the parent's thread), and distinguishes it from siblings by emphasizing it creates a new list aimed back at the sender, not merely adding tasks to an existing list. The examples and direction ('aimed back at whoever sent the original') make the unique role clear.

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

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

The description gives clear usage context: it's for replying to a task list with a task list and explains the resulting behavior (org gets pinged, thread shows in both worker portal and Simple Mode). It implicitly contrasts this with alternative follow-up methods by mentioning 'Use tascan_get_thread-style follow-up via tascan_list_projects/tascan_get_report to read answers,' which guides the agent to use separate tools for reading responses. It does not explicitly name sibling tools for creating normal lists or adding tasks, so exclusion guidance is partial.

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 fully discloses behavioral traits beyond the annotations: it confirms no money moves at pledge time, no card is stored, the payment is direct to the worker with 0% fee, and a Stripe pay link is generated upon verification. This aligns with readOnlyHint=false and destructiveHint=false, adding valuable context about side effects.

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

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

The description is three sentences, each earning its place: the first states the core purpose, the second explains the verification trigger and fee structure, and the third outlines a prerequisite. No redundant or vague language, well 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?

Given the tool has no output schema, the description could explain the API response (e.g., returns a pledge ID). It covers the user-facing outcome (Stripe link sent) but omits what the caller receives synchronously. Still, for a pledged payment creation tool, it provides sufficient context for an agent 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 description coverage is 83% (5 of 6 parameters described). The description reiterates the amount range already in the schema and adds context about the overall flow, but it does not add new meaning for individual parameters like memo, payer_name, or worker_id beyond what the schema provides. The marginal value is limited, keeping the score at 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 the specific verb 'pledge' combined with 'payment on a task list', clearly distinguishing this tool from all siblings. No other sibling tool handles payment pledging, and the description explains the conditional release mechanism, making the purpose unambiguous.

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

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

The description outlines the flow: pledge occurs when the list is verified complete, worker must have completed payout onboarding, and the payer receives a Stripe link. It provides clear context for when to use the tool, though it does not explicitly contrast with alternatives (e.g., direct payment) or state when not to use it.

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 covered. The description adds substantial behavioral context beyond annotations: the discoverability filter, ranking by trust tier and verified completions, the AI-inferred skill provenance, and the explicit privacy guarantee ('never phone, email, or org membership'). This is high-value transparency about what the tool does and does not return.

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 earning its place: the first defines purpose and ranking, the second explains skill provenance, and the third specifies privacy-safe output fields. Key info is front-loaded, and there is no filler or repetition of schema content.

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

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

Despite lacking an output schema, the description covers the essential return contract: sanitized public cards with specific fields and exclusions. It also covers the selection logic, ranking, and all filters. An agent has enough context to call this tool correctly and interpret results without further inference.

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?

Input schema coverage is 100%, so the schema already documents all five parameters well. The description does not add per-parameter detail beyond the schema, but it does provide useful context for how the parameters shape results (e.g., ranking and sanitized output). Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 ('Search'), a specific resource ('cross-org Worker Marketplace'), and precisely defines the population ('workers who opted in (discoverable=true on their passport)'). It also gives unique ranking criteria ('passkey trust tier + verified completion volume'), which distinguishes it clearly from sibling list/search tools like tascan_list_workers or tascan_find.

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 establishes when this tool is appropriate: searching the cross-org marketplace for opt-in workers. It provides filter guidance through examples and constraints, but it does not explicitly name sibling alternatives or state when not to use it, so there is a small exclusion-guidance gap.

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 significant behavioral context beyond the annotations: it discloses the sender identity (A2P or BYOK Twilio), quota impact, automatic 'TaScan:' prefix, and content policy restrictions. These are exactly the side-effect and constraint details an agent needs and that annotations alone do not 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 information-dense yet clearly structured: it opens with the core purpose, then covers the optional list-link behavior, followed by sender/quota constraints. Every sentence contributes useful operational knowledge 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?

The description covers destination selection, optional link behavior, sender infrastructure, quota, prefixing, and content policy. It doesn't explicitly describe the full return value (e.g., an SMS ID), though it mentions the link is returned when include_link is false. Given no output schema, a brief note about the response would make it fully complete, but the current information is largely 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?

With 100% schema coverage, the baseline is 3, but the description adds meaningful semantics: worker_id is preferred over raw phone, list_id appends a tap-to-open link, and include_link controls whether the link is embedded or just returned. This goes beyond the schema field descriptions and clarifies selection and behavior.

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 sends a transactional TaScan SMS to either a worker_id or a raw phone number, which is specific and actionable. It also distinguishes itself from related tools like tascan_send_task_email by focusing on SMS text with optional task-list 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 strong context for when to use this tool: for transactional/work-related SMS to workers or raw numbers, with optional checklist links. It doesn't explicitly name alternatives or exclusion conditions, but the 'transactional only, no marketing' rule and BYOK/quota details help an agent decide when this is appropriate.

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