mcp-coreclaw

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

Annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds useful behavioral details: it aborts the current user's most recent run, returns a success envelope (often null), and should be called after checking the run is active. No contradiction with annotations; the workflow context augments 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 well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is appropriately concise. The Chinese translation duplicates the English but adds multilingual accessibility; the WHEN NOT TO USE content is slightly generic and could be more focused on the tool itself, but overall it is efficient.

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

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

For a parameterless tool with no output schema, the description covers the essential context: what it does, when to use it, a workflow dependency, and what it returns. The guidance to call after get_last_worker_run confirms activity is a valuable completeness detail that prevents misuse.

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 are zero parameters, and the schema is empty. Per the baseline rule for 0 params, a score of 4 is appropriate. The description does not need to add parameter semantics since there are none to document.

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

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

The description clearly states 'Abort the current user's most recent CoreClaw worker run' with a specific verb and resource. It distinguishes from sibling abort tools by specifying 'current user's most recent' and 'CoreClaw', which is more specific than the sibling names.

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections provide context, including a Chinese translation and a workflow tip to call after get_last_worker_run confirms the run is active. However, the WHEN NOT TO USE section is generic and not directly tied to competing abort tools, so it does not fully clarify when to prefer this tool over abort_worker_run or abort_worker_last_run.

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 provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: it states 'RETURNS: JSON success envelope data, often null' and a workflow prerequisite. It does not contradict annotations and gives additional insight into side effects (canceling a run) and return shape.

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 well-organized with clear section labels (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is appropriately sized for the tool. The Chinese trigger phrase adds some redundancy and vagueness, but the overall structure is effective.

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 a single parameter, no output schema, and modest annotations, the description covers purpose, usage conditions, return type, and a workflow prerequisite. It is nearly complete, but it does not explicitly address how this tool differs from similarly named abort/rerun siblings, which would make it 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 has 100% coverage for the single parameter worker_id, including an example and how to obtain it. The description does not add any extra meaning 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 opens with a clear action and target: 'Abort the most recent run for a specific CoreClaw worker.' This is specific and not a tautology. However, it does not explicitly differentiate from sibling tools like abort_last_worker_run or abort_worker_run, so it stops short of a 5.

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

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

The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, plus a workflow condition ('Call after get_worker_last_run confirms the run is active'). It covers when to use and when not to use, but does not name alternative sibling tools, so it lacks the full 'alternatives' element for 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 indicate not read-only, not destructive, and idempotent. The description adds useful context by stating the return envelope ('often null') and the precondition workflow ('Call after get_worker_run confirms status is ready or running'). 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 well-structured with labeled sections, but it contains a broad Chinese trigger line (查询、运行、重跑、停止、导出或查看) that applies to many operations, not just abort, and a WHEN NOT TO USE sentence about web search that seems globally scoped. These reduce clarity and waste space.

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

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

For a one-parameter tool with no output schema, the description covers purpose, usage, return format, and workflow. It is sufficiently complete for an agent to understand when and how to call it, though it could mention sibling abort tools for disambiguation.

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 the only parameter run_id, which includes a description, example, and source instructions. The description adds no additional parameter meaning, 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 opens with a specific verb+resource: 'Abort a specific CoreClaw worker run by run_id.' It clearly distinguishes this tool from siblings like abort_last_worker_run and abort_worker_last_run by emphasizing 'specific' and 'by run_id.'

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 explicit WHEN TO USE ('Use when the user wants to cancel a known running run') and WHEN NOT TO USE (no public web search or code search for private data, no excluded internal APIs). It also gives a workflow hint referring to get_worker_run, but it does not explicitly mention alternatives like abort_last_worker_run, 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?

Annotations only show all hints as false, providing minimal safety context. The description adds value by disclosing the return format (results[] with per-item queue_ref and success) and the workflow prerequisite (call after list_run_queue_items confirms waiting status). This gives useful behavioral context beyond annotations, though failure modes are not fully detailed.

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 well-organized with sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and each part serves a purpose. However, the Chinese trigger phrase is somewhat redundant and broad, adding unnecessary length and potential confusion.

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 purpose, usage conditions, return format, and workflow, which is complete for a simple one-parameter tool. No output schema exists, but the RETURNS section compensates by describing the JSON structure.

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

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

The schema already provides a detailed description for queue_refs, including example and how to obtain the values. The tool description adds no further parameter information, so it meets the baseline of 3 but does not exceed 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 first sentence, 'Activate one or more waiting CoreClaw Run Queue items so they start executing,' uses a specific verb and resource, clearly distinguishing it from siblings like list_run_queue_items or release_run_queue_items. This is a precise statement of the tool's function.

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?

Includes explicit 'WHEN TO USE' ('previously queued runs via queue_worker_run and now wants to start them') and 'WHEN NOT TO USE' sections. However, the Chinese trigger phrase broadens the context to any CoreClaw operation, which could confuse an agent, so it's not perfectly 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 indicate this is not read-only, idempotent, or destructive. The description adds useful behavioral context: the task is 'saved', returns JSON with a slug, and should be followed by run_worker_task using the returned worker_task_id. It lacks auth/error details but provides meaningful extra 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?

Section labels (WHEN TO USE, RETURNS, WORKFLOW) provide structure, but the Chinese trigger sentence lists many actions (query, run, rerun, stop, export, view) unrelated to creation, and the WHEN NOT TO USE includes boilerplate about internal APIs that adds noise. Reasonably sized but not 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?

With 11 parameters and no output schema, the description covers purpose, return value, and next workflow step, which compensates for the missing output schema. It doesn't cover error/auth behavior, but given the schema's parameter coverage, the description is sufficiently complete for a create 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?

Input schema covers all 11 parameters with descriptions (100% coverage), so the description adds little beyond 'input and optional schedule.' The schema does the heavy lifting, and the description does not introduce new parameter semantics. 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 first sentence states a specific action ('Create') on a specific resource ('new saved CoreClaw worker task') with clear scope ('with input and optional schedule'). This clearly distinguishes it from siblings like update_worker_task and run_worker_task.

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

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

The description includes both WHEN TO USE and WHEN NOT TO USE sections, advising use when saving a reusable, scheduled task. It references run_worker_task in the workflow but does not explicitly name alternative tools like update_worker_task for editing existing tasks, so it stops short of full 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 include destructiveHint=true, so the destructive nature is known. The description adds value by specifying the return format ('JSON success envelope data, often null') and the recommended workflow order, which provides operational 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?

The description is organized into clear sections, but it contains an irrelevant and misleading Chinese trigger sentence that lists unrelated operations ('query, run, rerun, stop, export, view') rather than deletion. This adds noise and could confuse the agent, detracting from conciseness and structural clarity.

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 tool with one parameter and no output schema, the description covers purpose, usage context, return type, and workflow. It lacks explicit permission requirements or irreversible consequences, but these are partially implied by 'permanently remove' and the destructiveHint annotation. The off-topic Chinese line is a minor completeness flaw.

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 parameter 'worker_task_id' already includes a clear description with example and source ('Obtain from list_worker_tasks'). The tool description does not add additional parameter semantics, 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 clearly states the specific action: 'Delete a saved CoreClaw worker task.' The verb 'Delete' and the resource 'saved CoreClaw worker task' are precise and distinguish this from sibling tools like update_worker_task, run_worker_task, or get_worker_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 WHEN TO USE section explicitly states the trigger: 'when the user wants to permanently remove a saved task.' It also provides a workflow prerequisite, advising to call list_worker_tasks or get_worker_task first to confirm existence. However, it does not explicitly name alternatives or exclusions among sibling tools, only generic guidance about not using web search for private data.

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 description's safety profile is covered. The description adds value by specifying the return format (JSON with temporary download_url) and a workflow dependency (call after get_last_worker_run indicates success), which are behavioral traits beyond 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 well-structured with sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is mostly concise. However, the inclusion of Chinese trigger text and some repetition slightly detract from conciseness, earning a 4.

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 sufficiently explains return value (JSON with download_url). It also provides workflow and format details, making the tool fully understandable for correct invocation.

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

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

The input schema has 100% coverage with clear descriptions for format (enum, default csv) and filter_keys (comma-separated fields). The description reinforces the parameter usage indirectly but doesn't add new meaning beyond the schema. Baseline 3, but the schema coverage is high so a slight credit for clarity yields a 4.

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

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

The description clearly states 'Export the current user's most recent CoreClaw run results' with a specific verb and resource, and the title 'Export Last Worker Run Results' reinforces this. It distinguishes from sibling tools like export_worker_last_run_results by specifying 'current user' and 'most recent' 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 provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, including examples like user requests to download/export as CSV/JSON, and exclusions for public web search or internal APIs. This gives clear guidance on appropriate contexts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns a JSON with a temporary download_url and that it should be called after a successful run. This adds useful 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?

Description is concise with 6 lines of text split into sections. Front-loaded with purpose. No fluff or 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?

Given no output schema, description mentions return type (JSON with temp download_url) and workflow prerequisite. With 3 params, 100% schema coverage, no nested objects, it's fairly complete. Could mention error conditions but acceptable.

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%, but description adds extra context: for worker_id, 'Obtain from list_store_workers or list_workers'; for filter_keys, 'Leave empty to export all fields'; and explains format enum. This adds value beyond 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 exports results from the most recent run of a specific CoreClaw worker. Uses specific verb 'export' and resource 'worker last run results'. Distinguishes from siblings like export_worker_run_results which export results from a specific run, not just the last.

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 explicit WHEN TO USE and WHEN NOT TO USE sections. Tells when to use (user asks to download latest output for known worker, with Chinese trigger). Also says not to use public web search or internal APIs. Suggests workflow: call after get_worker_last_run shows succeeded.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description does not contradict. The description adds value by mentioning the return of a temporary download_url and the prerequisite of a successful run, providing useful 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?

The description is concise with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is front-loaded with the purpose. The inclusion of a Chinese trigger phrase may be unnecessary for English-centric agents, but overall it is well-structured and efficient.

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

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

Given the tool has 3 parameters with 100% schema coverage and no output schema, the description provides sufficient context: it indicates the return type (JSON with temporary URL), the prerequisite (successful run), and the workflow. It does not explain limitations like data size or rate limits, but these are not critical for basic usage.

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 tool description does not add any additional meaning to the parameters beyond what is already in the input schema. It does not elaborate on parameter usage or provide examples.

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 'export' and resource 'result data for a specific CoreClaw worker run'. It distinguishes from sibling tools like 'export_last_worker_run_results' by specifying 'specific...' and providing a workflow that requires a known run.

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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance. It specifies to use when the user asks to download or save output, and warns against using public search or internal APIs. Also provides a workflow: call after get_worker_run shows success.

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 clear. The description adds value by specifying return fields ('balance and balance_expiration_at') and workflow context ('Terminal call or preflight before run_worker'), but does not disclose additional behavioral traits beyond 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 concise, with structured sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence serves a purpose, and the information is front-loaded for quick comprehension.

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

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

Given no parameters, rich annotations, and multiple sibling tools, the description fully covers purpose, usage guidance, and return information. It is complete for an agent to understand when and how to use this 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?

There are no parameters (input schema has no properties), and schema description coverage is 100%. The description adds meaning by explaining what the tool returns, which is especially valuable given the absence of 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 'Get the current user's CoreClaw account balance and traffic quota,' using a specific verb and resource. It uniquely identifies the tool's purpose, distinguishing it from sibling tools focused on workers and runs.

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 includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, providing clear context for usage and exclusion. It also includes Chinese triggers, offering comprehensive guidance on when to invoke this tool versus 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's behavioral burden is lighter. The description adds value by specifying the returned JSON fields (slug, status, worker, etc.) and outlining the workflow, which goes 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 well-organized with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence is informative without redundancy. It is concise but packs essential 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?

Given zero parameters, comprehensive annotations, and no output schema, the description fully covers what the tool does, when to use it, what it returns, and how it fits into the broader workflow. No missing context.

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

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

Schema has 0 parameters and 100% coverage. Baseline is 4. The description does not need to elaborate on parameters since there are none, and the description implicitly confirms no inputs.

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

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

Clearly states it gets the current user's most recent CoreClaw worker run. Uses specific verb+resource and distinguishes from siblings by listing follow-up workflow 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?

Explicitly provides when-to-use triggers (e.g., 'last run', 'latest job') and when-not-to-use instructions (avoid public web search for private data). Also references alternative sibling tools in the workflow section.

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. The description adds that it returns JSON with recent run log data, but does not elaborate on edge cases like no recent run. With annotations covering safety, this is adequate but not rich.

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?

Description is structured with headers and front-loaded purpose, but includes verbose elements like the Chinese trigger. Could be more concise, but overall efficient.

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

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

With no parameters or output schema, the description covers usage, return type, and workflow. Missing specifics about error handling or 'most recent' definition, but sufficient for a simple log retrieval 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?

No parameters exist, and schema coverage is 100%. Baseline score of 4 applies as description does not need to add parameter info.

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 retrieves logs for the current user's most recent CoreClaw worker run, using a specific verb and resource. It distinguishes from sibling tools like get_worker_run_log and get_last_worker_run.

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections provide clear context: debugging failed/stalled runs, avoiding public web search, and suggesting workflow after get_last_worker_run. The Chinese trigger adds additional 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, destructiveHint=false. Description adds that it returns JSON with specific fields (name, username, version, readme, parameters), and implies a read-only GET operation. No contradictions.

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 concise and well-structured: brief intro, explicit WHEN TO USE, WHEN NOT TO USE, RETURNS, and WORKFLOW sections. Every sentence adds value, no redundancy.

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

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

Given the tool's simplicity (one parameter, read-only, good annotations), the description is complete. It explains the return value and workflow, compensating for the lack of 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 the single parameter 'worker_id', with clear description including example and source. The tool description does not add significant new meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states 'Get detail for a CoreClaw worker', specifying the verb and resource. It distinguishes itself from sibling tools like run_worker, list_workers, etc., by noting it is used before running a worker to inspect version, README, and parameters.

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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. When to use: before running a worker to inspect details. When not to use: avoid public search for private data and internal APIs. Also provides follow-up workflow with get_worker_input_schema and run_worker.

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, indicating a safe, read-only operation. The description adds that the return is 'JSON with input_schema' and suggests a workflow, but does not detail potential error conditions or authentication requirements. It provides sufficient context without contradiction.

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

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

The description is highly concise with a well-organized structure: a clear opening sentence, followed by 'WHEN TO USE', 'WHEN NOT TO USE', 'RETURNS', and 'WORKFLOW' sections. No extraneous information; every section provides value and is front-loaded with the core 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 simplicity (1 required parameter, no output schema, strong annotations), the description covers all necessary information: purpose, usage context, return format, and workflow integration. It enables an agent to correctly invoke the tool without ambiguity.

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

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

The input schema has 100% description coverage for the single parameter. The description adds extra context by providing examples ('demo-worker' or 'owner~demo-worker') and sourcing advice ('Obtain from list_store_workers or list_workers'), which enhances the parameter's meaning beyond the schema alone.

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

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

The description clearly states 'Get the public input JSON schema for a CoreClaw worker', specifying the verb (get) and resource (input schema). This purpose is distinct from sibling tools like get_worker (which returns worker details) or run_worker, as it focuses on obtaining the schema needed for composing input.

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

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

Explicitly provides when-to-use ('before composing run_worker input_json') and when-not-to-use instructions, including a Chinese trigger phrase and exclusions for external searches and internal APIs. Also recommends a workflow: 'Call before run_worker so input_json matches the worker schema', guiding the agent on proper tool sequencing.

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 tool is clearly safe. The description adds context about return format (JSON) and workflow, which goes beyond annotations. No contradiction.

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

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

The description is well-structured with clear headings (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is concise without wasting words. Every sentence 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?

Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: a clear purpose, usage guidelines, return format, and workflow. It is 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?

The input schema has full coverage (100%) for the single parameter, including a description with example. The description does not add additional meaning beyond the schema, 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 purpose: 'Get the most recent run for a specific CoreClaw worker.' It uses a specific verb and resource, and the sibling list includes other run-related tools, so it distinguishes itself well.

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 includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, providing clear context and exclusions, such as not using public search or internal APIs. This helps the agent decide when to invoke this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is known to be safe. The description adds that it returns JSON with log data and workflow positioning (call after get_worker_last_run). No contradictions.

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 well-structured with clear sections (purpose, when to use, when not to use, returns, workflow). Every sentence adds value, no redundancy. It is concise yet comprehensive.

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 input (one fully-described parameter), rich annotations, and mention of return format (JSON), the description is complete. It also includes workflow guidance, which is helpful for correct invocation.

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

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

There is only one parameter (worker_id) with full schema description (100% coverage) including examples and where to obtain it. The description does not add additional semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states 'Get logs for the most recent run of a specific CoreClaw worker,' using a specific verb and resource. It distinguishes from sibling tools like get_worker_last_run (status/output) and get_worker_run_log (logs for a specific run, not necessarily the last).

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

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

Explicitly provides 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It says to use when debugging the latest run, and not to use for public searches or internal APIs. Also gives workflow context: 'Call after get_worker_last_run when status or output needs explanation.'

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 readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns JSON with fields like run status, worker, timestamps, etc., and suggests a subsequent workflow (e.g., follow with results, logs). 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 well-structured with sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loads the main purpose. It is appropriately concise for the complexity, though slightly verbose with the Chinese trigger text.

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 tool with one parameter and good annotations, the description covers all necessary context: purpose, usage, return format, and follow-up actions. It is complete and leaves no ambiguity.

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

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

Input schema coverage is 100%, so baseline is 3. The description adds value by explaining where to obtain the run_id ('Obtain from run_worker, list_worker_runs, or get_last_worker_run.'), which aids correct usage.

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: 'Get detail for a specific CoreClaw worker run by run_id.' It distinguishes itself from sibling tools by focusing on retrieving details for a single run by its identifier, and the 'WHEN TO USE' section reinforces this.

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 when-to-use criteria (user provides run ID, wants status/cost/detail) and when-not-to-use (avoid public search for private data, avoid internal APIs). This helps the agent select the correct tool among many related siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, aligning with log retrieval. The description adds useful behavioral context: grep filtering, the note that raw logs have few system lines with buried tracebacks, and the return structure when grep is set ({matched_count, lines[]}). No contradictions with annotations, though the non-grep return format is briefly mentioned as 'JSON with log 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 well-structured with clear sections and front-loaded purpose, but it is longer than necessary. The inclusion of the Chinese trigger paragraph adds redundant, broad instructions that dilute conciseness and introduce noise. A more streamlined version would be more effective.

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 provides coverage for retrieval, grep filtering, workflow, and exclusions, but it leaves the non-grep return format vague ('JSON with log data') and includes the confusing Chinese trigger that implies unrelated capabilities. With no output schema, these gaps create some ambiguity for an agent deciding how to use 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 description coverage is 100%, with detailed descriptions for run_id, grep, max_matches, and context_lines. The description adds a practical tip by recommending grep for Error/Traceback lines and explaining why, which enriches parameter semantics beyond the schema. However, this is modest additional value given strong 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 English description clearly states 'Get logs for a specific CoreClaw worker run, optionally filtered to lines matching error/traceback keywords,' which is specific and distinguishes from sibling tools like get_worker_run. However, the Chinese trigger ('中文触发') broadens usage to 'query, run, rerun, stop, export, or view' worker/run/task data, overstating the tool's scope and adding 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 WHEN TO USE section gives explicit scenarios (debug a known run id, failed/stalled/suspicious runs) and advises passing grep, while the WORKFLOW suggests calling after get_worker_run. However, the Chinese trigger instructs using this tool for run, rerun, stop, and export operations, which are not this tool's function, creating conflicting guidance. The WHEN NOT TO USE section does not address this misstatement.

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 agent knows it's a safe read operation. The description adds value by listing the return fields (title, description, worker_id, input, schedule, slug) and suggesting follow-up tools, which provides 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?

The description is well-organized with clear section headers (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is concise but informative, without wasted words. Could be slightly more compressed, but overall it is efficient.

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

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

For a simple read tool with one parameter and no output schema, the description provides adequate completeness: it explains the return format, gives usage guidelines, and suggests a workflow. It covers key aspects an agent needs to know, though it could mention idempotency or caching hints.

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 covers 100% of the single parameter (worker_task_id) with a description and example. The description does not add additional parameter-specific information beyond what the schema provides. Baseline 3 is appropriate when schema coverage is high.

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

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

The description begins with a clear statement: 'Get detail for a specific saved CoreClaw worker task.' It specifies the verb (get), resource (worker task), and scope (specific, saved). This clearly distinguishes it from sibling tools like list_worker_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 includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It states when to inspect a saved task's configuration, schedule, or input, and provides a Chinese trigger. It also warns against using public web search or code search for private data, and not to call internal APIs. This provides clear guidance on when to use this tool vs 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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds return format ('JSON with task's input object and optional version field'). No contradictions.

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?

Well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Front-loaded with main purpose. 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?

Given the tool's simplicity (one parameter, read-only), the description covers purpose, usage, return, and next steps. Absence of output schema is mitigated by stating return format.

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 description does not add parameter-level meaning beyond the schema's description of worker_task_id. Baseline score of 3 applies.

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

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

Clearly states the verb 'Get' and the resource 'input payload for a saved CoreClaw worker task'. Differentiates from siblings by specifying 'input payload' and providing workflow hints.

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections with concrete scenarios (inspect/copy input) and exclusions (public search, internal APIs). Provides Chinese trigger phrase and mentions alternatives (follow with update_worker_task_input or run_worker_task).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description adds extra context by disclosing pagination, the current-user scope, the JSON return shape, and the recommended call ordering. The note about executing after get_last_worker_run succeeds is useful behavioral context, though the 'Do not call excluded internal...' phrasing is vague.

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?

While the purpose sentence is front-loaded and section headers help structure, the description includes a redundant and overly broad Chinese trigger list (including actions like stop, rerun, export that this tool cannot perform) and an irrelevant 'Do not use public web search' statement. Several sentences do not earn their place, making the description less concise than needed.

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 paginated list tool with two well-documented parameters and no output schema, the description provides adequate context: purpose, scope, return type, and a workflow pointer. It could be more complete by describing the actual result row contents or error behavior, but given the low complexity, it covers the essential information well.

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 covers 100% of parameters and includes thorough descriptions for limit (range/default) and offset (1-based, offset=0 accepted). The tool description only adds the generic notion of 'paginated results' and does not provide additional parameter-level meaning beyond what the schema already offers, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists paginated results from the current user's most recent CoreClaw run, which identifies the verb, resource, and scope. However, it does not explicitly distinguish this tool from similarly named siblings like list_worker_last_run_results or list_worker_run_results, leaving potential ambiguity about the exact entity being queried.

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 has explicit WHEN TO USE and WHEN NOT TO USE sections, gives a concrete workflow step (call after get_last_worker_run shows status succeeded), and names export_last_worker_run_results as the alternative for large output. This provides clear actionable guidance for 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 and idempotentHint=true, so the description does not add much beyond confirming the read-only nature and stating it returns JSON. This is adequate but not enhanced beyond 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 well-structured with labeled sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is concise, containing only essential information with 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers purpose, usage, returns, and workflow comprehensively. No gaps are present.

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 covers the single 'language' parameter fully (100% coverage), including default and description. The description merely echoes 'English or Chinese,' adding no significant new meaning 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 'List CoreClaw proxy regions in English or Chinese,' specifying the verb (list), resource (proxy regions), and language options. It effectively distinguishes itself from sibling tools that deal with workers, runs, or tasks.

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

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

The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, covering use cases (e.g., before running a worker) and listing alternatives to avoid (public web search, internal APIs). This provides clear guidance for agent 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, so the description doesn't need to restate safety. It adds value by disclosing the return format ('JSON with count, page_index, page_size, and list of queue items') and the workflow context ('Follow with activate_run_queue_items...'), which go beyond the annotation metadata.

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 well-structured with clear section headers, but it contains redundancy. The Chinese line (中文触发) broadens the use case to '运行、重跑、停止、导出' (run, rerun, stop, export), which are not actions of this list tool and could mislead. The WHEN NOT TO USE statement about 'excluded internal worker-version or internal-detail APIs' is vague and adds little actionable guidance.

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

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

Given no output schema, the description compensates by stating the return structure. It covers when to use, the workflow, and the general purpose. It doesn't explain error handling or authentication, but for a simple read-only list operation with well-documented parameters and annotations, this is adequately 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%, with each parameter (limit, offset, status) having detailed descriptions including defaults, ranges, and allowed enum values. The tool description does not add parameter-specific syntax but does connect 'waiting/inactive' to the status parameter, providing a little extra semantic context. This aligns with the baseline 3 for 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 opens with 'List items in the CoreClaw Run Queue', a clear verb+resource statement. The WHEN TO USE section reinforces specificity by mentioning 'inspect queued runs, find a queue_ref, or check waiting/inactive items', which distinguishes this tool from siblings like activate_run_queue_items or release_run_queue_items.

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 WHEN TO USE section explicitly states when to invoke the tool ('inspect queued runs, find a queue_ref, check waiting/inactive items before activating or releasing'). The WHEN NOT TO USE section provides exclusions, and the WORKFLOW section names complementary tools (activate_run_queue_items, release_run_queue_items), giving clear guidance against 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?

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable context: it specifies return format (JSON with slug, path, title, username, description) and workflow role ('Usually first step'). It also discloses a caveat about not calling internal APIs. This surpasses the baseline for annotation-backed transparency, though it doesn't exhaustively cover rate limits or error behavior.

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

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

The description is well-structured with clear headers (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loaded purpose. It is somewhat verbose due to the Chinese duplicate line, but that doesn't detract significantly. Each section adds distinct value without excessive 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?

The description is complete for a search tool: it explains return format even without an output schema, provides workflow context relative to sibling tools, and sets expectations for when to use it. Given the simple parameter set and annotations, 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 100%, so baseline 3 applies. The description adds a slight semantic cue by connecting keyword search to 'site name' in WHEN TO USE, but it doesn't go beyond the schema's parameter descriptions. No compensation needed, yet no meaningful addition beyond 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 opens with a specific verb and resource: 'Search the public CoreClaw worker marketplace for ready-to-run workers.' It clearly differentiates from sibling tools by emphasizing the 'public' marketplace and 'store' workers, and the WHEN NOT TO USE section explicitly excludes internal-detail APIs, reinforcing its unique 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 provides explicit WHEN TO USE and WHEN NOT TO USE sections. It names concrete use cases (find, discover, browse, search) and exclusions (do not use public web search for private platform data). The WORKFLOW section further guides tool selection by recommending follow-up tools (get_worker_input_schema, get_worker) before run_worker.

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 and idempotent hints, and the description adds valuable behavioral context: it notes the return includes pagination metadata, suggests calling after get_worker_last_run succeeds, and recommends export for large outputs. This goes beyond the structured annotations 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 well-organized with sections for purpose, when to use, when not to use, returns, and workflow. The Chinese trigger section is somewhat redundant and adds clutter, but the overall structure is front-loaded and 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?

For a read-only listing tool with rich annotations and schema, the description covers the essential context: what it returns, when to call it, and workflow dependencies. It could mention the difference from list_worker_run_results or list_last_worker_run_results, but the given context is sufficient 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?

The input schema already provides 100% coverage with detailed parameter descriptions, examples, and edge cases. The description adds little parameter-specific meaning beyond stating that results are paginated, 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 clearly states the tool lists paginated results from the most recent run of a specific CoreClaw worker, using a specific verb and resource. However, it does not explicitly distinguish itself from similarly named siblings like list_last_worker_run_results or list_worker_run_results, so it falls short of full differentiation.

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

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

Provides a clear WHEN TO USE section and a WHEN NOT TO USE section, including guidance to use export_worker_last_run_results for large output. The Chinese trigger sentence is overly broad and could mislead selection for run/stop/export actions, but the overall guidance is contextually useful and points to 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context beyond annotations: returns JSON with pagination metadata, and workflow constraints for large outputs. It also implies a dependency on run status. No contradiction.

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

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

Structured with clear headers (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loaded with the primary purpose. The Chinese text repeats the English usage but adds bilingual trigger coverage. No unnecessary fluff, though slightly longer than the minimal 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?

No output schema exists, and the description provides a high-level return type ('JSON with result rows and pagination metadata') and workflow guidance. It also distinguishes from export for large outputs. However, it does not detail the exact shape of pagination metadata or error/edge-case behavior (e.g., run not found), leaving minor gaps.

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

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

Schema description coverage is 100% – all three parameters (limit, offset, run_id) have full descriptions and examples. The description only reinforces that a 'known run id' is required but does not add new semantic meaning beyond the schema. 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 'List paginated results for a specific CoreClaw worker run' – a specific verb (List) and resource (paginated results for a specific run). It distinguishes from siblings like list_worker_runs (lists runs) and export_worker_run_results (for large output via WORKFLOW). The 'specific' qualifier differentiates it from the last-run listing 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?

WHEN TO USE explicitly states 'when the user wants records/output rows from a known run id'. WHEN NOT TO USE provides exclusions (no web/search for private data, no internal APIs). WORKFLOW gives an alternative ('use export_worker_run_results for large output') and a prerequisite ('Call after get_worker_run shows status succeeded'). This is explicit and actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the current-user scoping and a RETURNS breakdown, but it does not disclose additional behavioral details like default time-window behavior (though that appears in the schema) or potential rate limits. The vague 'Do not call excluded internal worker-version or internal-detail APIs' adds little.

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 well-structured with clear section headings (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is appropriately sized. It loses a point for redundancy: the Chinese trigger duplicates the WHEN TO USE content, and the internal-API exclusion line is vague rather than concise.

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

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

With no output schema, the RETURNS section usefully lists expected fields (count, list, offset/page data, run slug, worker info, status, usage, traffic, timestamps). Combined with usage guidance and workflow, the description gives a complete mental model of the tool. It does not mention the default current-month-only behavior, but that is captured in the schema.

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

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

Schema description coverage is 100%, with each of the 6 parameters well-documented in the schema (defaults, ranges, enums, examples). The description itself adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description opens with a specific verb and resource: "List the current user's CoreClaw worker runs." It clearly distinguishes from sibling tools like list_workers and list_worker_run_results by specifying the resource (worker runs) and scope (current user). The additional intent 'find a run_id by worker or status' reinforces its purpose.

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

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

The description includes explicit WHEN TO USE and WHEN NOT TO USE sections, with concrete user intents like 'run history' and 'recent jobs'. It also names follow-up tools in the WORKFLOW section. However, it does not explicitly contrast this tool with alternatives like get_worker_run for single-run lookup, so it stops short of full alternative differentiation.

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 return format (JSON fields) and ownership scope. Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is covered. The description adds behavioral context about the returned data fields and the fact that it's scoped to the current user, going 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 structured with headings and front-loaded, but includes redundant Chinese text and a vague 'WHEN NOT TO USE' instruction about 'excluded internal worker-version or internal-detail APIs' that adds little clarity. It is longer than necessary for this simple listing 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?

With no output schema, the description explains the return fields, mentions the usage workflow with follow-up tools, and clarifies the scope. It lacks explicit pagination behavior, but the schema covers that. For a list tool, it is fairly complete given annotations and schema coverage.

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%; each parameter (limit, offset, keyword) has a clear description and constraints. The description does not add parameter-specific semantics beyond what the schema provides, 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 states 'List CoreClaw workers owned by the current user,' with a specific verb (list), resource (workers), and scope (owned by current user). It distinguishes itself from sibling tools like list_store_workers by explicitly contrasting with the public marketplace.

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 explicit WHEN TO USE and WHEN NOT TO USE sections, including a Chinese trigger phrase. It tells the agent to use this for private/current-user workers rather than public marketplace, and warns against using public web search for private data. It also suggests follow-up tools in WORKFLOW.

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 readOnly/idempotent/destructive hints. The description adds context beyond these: the 'current user' scoping, the 'saved tasks' filter, the return format ('JSON list'), and a workflow hint about following up with run_worker_task. No contradictions.

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 well-structured with labeled sections and the core purpose in the first sentence. It is concise overall, though the 'WHEN NOT TO USE' mention of 'excluded internal worker-version or internal-detail APIs' is somewhat vague and could be tightened.

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 moderate complexity (4 optional params, many sibling tools, no output schema), the description provides adequate context: purpose, usage scenarios, return type, and a workflow pointer. It does not enumerate return fields, but the output schema absence is partially mitigated by the RETURNS statement.

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 covers 100% of parameters with detailed descriptions, examples, defaults, and constraints. The description adds no additional parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb+resource+scope: 'List saved CoreClaw worker tasks for the current user.' This clearly distinguishes it from siblings like list_worker_runs (runs vs tasks) and list_workers (workers vs tasks), while also specifying the user 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 provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, covering common intents like saved tasks, scheduled presets, and configured jobs, and warns against using it for public web/code search or internal APIs. It does not name alternative tools directly, but the boundary 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 readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral context beyond annotations: polling until terminal state or timeout, return fields (status, err_msg, poll_count, elapsed_ms), result preview behavior, and the intended workflow with sibling tools.

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 well structured with front-loaded purpose and labeled sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is somewhat long, and the Chinese trigger sentence is broad and not specifically tied to polling, while the WHEN NOT TO USE section contains vague statements about excluded APIs, which slightly reduce clarity.

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 complete lifecycle: when to call it, what it returns (status, err_msg, poll_count, elapsed_ms, result preview), and what follow-up tools to use. Without an output schema, the RETURNS section provides the needed expectation of response shape. It also accounts for the complex async run scenario and long-running workers.

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 each parameter already has a detailed description with defaults, ranges, and source guidance. The tool description does not add meaningful parameter-level semantics beyond vaguely referencing 'result preview' and 'timeout elapses', so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb ('Poll') and resource ('CoreClaw worker run'), and clearly states the outcome: wait until a terminal state or timeout, then return final status and optionally a result preview. It also distinguishes itself from get_worker_run by explicitly noting it avoids manual polling loops.

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 includes dedicated WHEN TO USE and WHEN NOT TO USE sections, naming concrete alternatives like get_worker_run, verify_run, list_worker_run_results, and get_worker_run_log. It also gives workflow context (call after run_worker or rerun_worker_run) and mentions slow worker durations (60-285s) to justify polling.

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 cover readOnly and destructive hints. The description adds the key behavior: the run is queued, not executed immediately, and returns queued/queue_ref/queue_status. It does not cover auth, rate limits, or what happens queue-side, but these are not required given the annotation baseline.

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 structured with clear sections but is somewhat verbose. The Chinese trigger sentence is redundant and confusing, and the WHEN NOT TO USE section is generic filler. The key purpose is front-loaded, but the extra content could be trimmed.

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 core queueing concept, return fields, and a workflow for subsequent actions. However, it doesn't explain why limit/offset parameters apply to a submission tool, and lacks error/edge-case information. Given no output schema, it does provide minimal return info.

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 detailed parameter explanations (defaults, examples, constraints). The tool description adds no parameter-specific meaning beyond schema, so the baseline of 3 is appropriate.

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

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

The description states 'Submit a CoreClaw worker run to the Run Queue instead of executing immediately' – a specific verb, resource, and destination that clearly distinguishes it from immediate execution tools like run_worker. It also mentions returning a queue_ref for tracking.

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?

WHEN TO USE provides explicit context ('when the user wants to queue a run for later activation'), and WORKFLOW outlines follow-up tool usage. However, WHEN NOT TO USE is generic (public web/code search) and does not explicitly name run_worker as the alternative for immediate execution; the Chinese trigger line is overly broad and includes many unrelated operations.

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 the description adds that the item 'never executes', implying permanence. It also discloses the return format and workflow, providing behavioral context beyond the annotation. 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 structured with clear sections, but it includes extraneous content: a generic Chinese trigger sentence about querying/running/stopping/exporting data that is not specific to this destructive tool, and vague exclusions about 'internal worker-version or internal-detail APIs'. These do not earn their place and may confuse the agent.

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

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

Despite no output schema, the description provides the return format (JSON with results[]: {queue_ref, success, error?}) and a workflow prerequisite (call after list_run_queue_items). It covers the essential context for safe usage, though the irrelevant Chinese trigger slightly detracts. Overall, quite complete for a simple removal 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%, with both parameters already documented. The description adds only minor context by mentioning 'queue_id' and confirming it from list_run_queue_items, which is already in the schema. Given high schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the verb and resource: 'Release (remove) a single CoreClaw Run Queue item so it never executes.' It distinguishes from the sibling tool 'release_run_queue_items' by noting the singular version uses the queue_ref in the path. This is specific and 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 'WHEN TO USE' section explicitly says to use when removing one queued run by queue_id and contrasts it with the plural version. 'WHEN NOT TO USE' gives exclusions (public search, internal APIs), and WORKFLOW instructs to call after list_run_queue_items to confirm the queue_id. This provides clear guidance on when and how 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 destructiveHint=true, and the description adds valuable context with 'remove' and 'so they never execute', implying irreversibility. It also describes the per-item results structure ({queue_ref, success, error?}) and the workflow prerequisite, which goes beyond the structured annotations 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 organized into sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) making it scannable. However, the Chinese trigger sentence is extraneous and redundant, and the WHEN NOT TO USE section contains generic statements that do not specifically apply to this tool, adding noise without earning their 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 provides a concise return format, which is sufficient. It includes workflow guidance and distinguishes the batch nature. Minor gaps include not explicitly mentioning the relationship to activate_run_queue_items or the singular variant, but the overall context is adequate for selection and invocation.

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

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

Schema coverage is 100%, with both parameters well-documented: queue_refs includes example formatting and an explicit note to obtain values from list_run_queue_items; reason is described as optional. The description does not add new parameter semantics but reinforces the workflow, so it meets the baseline without going above.

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: 'Release (remove) one or more CoreClaw Run Queue items so they never execute.' This specifies the verb, resource, and effect. It also distinguishes itself from the singular sibling by explicitly calling itself 'the batch version.'

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 WHEN TO USE section provides clear context ('when the user no longer needs queued runs and wants to remove them in bulk') and the WORKFLOW indicates a prerequisite (call after list_run_queue_items). However, the Chinese trigger is overly broad and mismatched, covering query/run/rerun/stop/export/view rather than removal, which could mislead an agent. The WHEN NOT TO USE section is generic and does not address alternatives like the singular release_run_queue_item or activate_run_queue_items.

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 non-read-only, non-idempotent, non-destructive behavior. The description adds useful behavioral context: it creates a new run, returns a new run_slug or synchronous result fields, and depends on is_async. This goes beyond annotation-only transparency, though it does not mention rate limits, permissions, or side effects beyond running.

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 well-structured with labeled sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loads the core purpose. Some content, such as the broad Chinese trigger and the warning against public web search, is tangential and could be trimmed 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?

The description covers when to use, when not to use, return type, and a follow-up workflow, which is helpful given the low annotation detail and absence of an output schema. However, it does not explain why parameters like limit/offset or callback_url are relevant to rerunning, and the RETURN statement is vague about which fields appear in synchronous results.

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 covers 100% of parameters with descriptions, so baseline is 3. The tool description does not add any parameter-level meaning beyond the schema, and notably does not explain why limit/offset apply to a rerun action.

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

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

The description states a specific verb and resource: 'Rerun the current user's most recent CoreClaw worker run with the same saved inputs.' It clearly distinguishes this tool from siblings by scoping to the current user's most recent run and noting that saved inputs are reused.

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?

Explicit WHEN TO USE conditions are given with natural language triggers ('rerun last, retry latest') and a Chinese trigger. WHEN NOT TO USE cautions against using public web/code search for private CoreClaw data. However, the Chinese trigger is overly broad, covering query/run/stop/export/view rather than only rerunning, which slightly weakens the 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 annotations already declare readOnlyHint=false and idempotentHint=false, so the mutation/non-idempotent nature is known. The description adds that it returns a new run_slug or synchronous result fields, which is useful context, but it does not disclose other behavioral nuances such as side effects on the original run or rate limits. This is adequate but not exceptional 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 structured into clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loaded with the main purpose, but it includes a redundant Chinese sentence that is overly broad and potentially confusing ('查询、运行、重跑、停止、导出或查看' covers far more than rerun). Some sentences are vague ('excluded internal worker-version or internal-detail APIs') and do not earn their 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 tool with 5 parameters (one required) and no output schema, the description provides helpful context via RETURNS (JSON with run_slug or synchronous fields) and WORKFLOW (follow with get_worker_last_run or list_worker_last_run_results). It also mentions the prerequisite of a 'known worker.' The schema fully documents parameters, so the additional context is sufficient, though a note on error cases would push it higher.

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 each parameter having a detailed description (e.g., limit, offset, is_async, worker_id, callback_url). The tool description does not add meaning beyond the schema—it merely mentions 'specific CoreClaw worker' without elaborating on parameters. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states 'Rerun the most recent run for a specific CoreClaw worker' with a specific verb and resource, and the phrase 'most recent' distinguishes it from the sibling 'rerun_worker_run' which targets a specific run by ID. The main purpose is instantly clear and 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?

It explicitly provides a WHEN TO USE section ('retry or repeat the latest run for a known worker') and a WHEN NOT TO USE section (avoid public web or code search for private data). It does not explicitly name alternative tools like 'rerun_worker_run' for rerunning specific runs, but the scope is well-enough implied.

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

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

Annotations already indicate a non-read-only, non-idempotent operation. The description adds meaningful context: reruns use 'same saved inputs,' returns a 'new run_slug or synchronous result fields,' and suggests follow-up actions. It doesn't detail side effects like resource consumption, but the annotations lower the burden and the description adds sufficient value.

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

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

The description is well-organized with clear sections. It is appropriately sized but includes a broad Chinese trigger phrase that catches many unrelated actions. Still, every section earns its place and the structure is effective.

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

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

Given no output schema, the description provides return information and a workflow. It covers the essential use case. Minor gaps exist: the meaning of 'synchronous result fields' and the relevance of limit/offset are not explained, but the schema already describes parameters thoroughly.

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 all parameters. The description does not add parameter-specific insight beyond mentioning 'same saved inputs,' but the baseline of 3 applies because the schema carries the heavy lifting.

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

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

The description states 'Rerun a specific CoreClaw worker run with the same saved inputs,' which is a specific verb + resource + scope. It distinguishes from sibling rerun tools like rerun_last_worker_run by emphasizing 'specific' and 'known run id.'

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections provide clear context. It mentions retrying/repeating a known run id and gives a follow-up workflow with get_worker_run or list_worker_run_results. Exclusions are stated (no public web search for private data).

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 non-read-only, non-idempotent, and non-destructive. The description adds valuable behavioral detail: async runs return a run_slug, sync runs return result fields, and input_json is wrapped as input.parameters.custom. It does not mention side effects or error cases, but given annotation coverage, this is adequate.

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 well-organized into headed sections (purpose, when, when not, returns, workflow), making it scannable and front-loaded. The Chinese trigger line is somewhat redundant for English users, but it serves bilingual audiences and only slightly lengthens the text. Every section contributes operational 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 complex tool with 8 parameters, no output schema, and many sibling tools, the description covers the essential context: return shape, async/sync behavior, required sequencing, and clear boundaries against other tools. It lacks error handling and edge cases, but the rich schema and workflow guidance make it sufficiently complete 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%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the relationship between input_json and raw_input_json, the escaping mechanism, and the workflow dependency on get_worker_input_schema. This extra clarification justifies a 4.

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

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

The description opens with a specific verb+resource: 'Run a CoreClaw worker with an ad-hoc JSON input payload.' This clearly distinguishes run_worker from siblings like run_worker_task (saved task) and queue_worker_run (queued execution) by emphasizing ad-hoc payloads. The WHEN TO USE section further reinforces the scope with concrete actions (start, execute, scrape, crawl).

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections provide clear context, including a Chinese trigger phrase and exclusions for public search/internal APIs. The WORKFLOW section prescribes ordering with get_worker_input_schema first, then run_worker, then result/export tools. However, it does not name alternative sibling tools explicitly, 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?

Annotations only cover readOnly/destructive/idempotent hints, but the description adds substantial behavioral detail: it polls runs to terminal state, uses a synthetic batch path with custom per-item run_worker requests, processes items in input order, and explains skip_run_ids best-effort semantics. This goes well beyond the structured annotations with no contradiction.

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

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

The description is well-organized with clear section headers and front-loaded purpose. However, it includes some extraneous content like the generic Chinese trigger phrase and a broad 'do not use public web search' warning that does not specifically address this tool's usage. Most sentences earn their place, making it only slightly overlong.

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 (6 parameters, no output schema), the description covers the return JSON shape, processing order, polling behavior, concurrency defaults, and workflow dependencies. It also documents a subtle behavioral caveat about skip_run_ids and ad-hoc runs, making it comprehensive for an agent to use correctly.

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

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

Schema coverage is 100% with per-parameter descriptions, so baseline is 3. The description adds value by explaining that items are ad-hoc run_worker invocations, polling behavior, and the caveat about resubmitting ad-hoc input starting new runs. This extra context justifies a score above baseline.

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

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

The description clearly states it runs multiple CoreClaw workers in one call and returns a per-item summary, distinguishing it from the individual run_worker sibling. It specifies the scope (batch of ad-hoc runs), default serial behavior, and optional concurrency.

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?

Explicit WHEN TO USE and WHEN NOT TO USE sections are provided, including a concrete example (full-store smoke test) and the alternative (avoiding many individual run_worker calls). The WORKFLOW section gives clear preceding and succeeding steps, naming specific 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 declare readOnlyHint=false and idempotentHint=false, but the description adds that it returns a run_slug and can be synchronous or asynchronous, and that it should be followed by result/export tools. This conveys the execution flow and side-effect potential. It stops short of detailing all behavioral nuances (e.g., callback semantics, resource usage), but since annotations already cover the core mutation nature, the added context is above average.

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 well-structured with labeled sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and each sentence provides essential operational context. It avoids repetition and unnecessary details, earning a top score for clarity and efficiency.

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 no output schema and a complex execution action, the description covers purpose, usage boundaries, expected return, and follow-up workflow. It lacks some depth on the actual execution side effects, but the workflow hint and return description make it sufficiently complete 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?

The input schema covers 100% of parameters with descriptions, including examples and defaults. The tool description itself doesn't add further parameter-level detail, only clarifying the primary parameter (worker_task_id) represents a 'saved' task. This is sufficient, meeting the baseline for 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 opens with a clear verb+resource: 'Run a saved CoreClaw worker task.' It distinguishes from siblings by stating this is for 'configured task rather than supply ad-hoc worker input,' and clarifies the return type ('run_slug or synchronous result fields'). This fully differentiates it from adjacent tools like run_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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance, including the exact scenario (executing a configured task) and exclusions (no public web/code search for private data, no internal APIs). The 'WORKFLOW' section even suggests follow-up tools, giving an implementation path.

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

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

The description reveals that omitted fields are preserved via partial update, which is important behavioral context. It also discloses return format as 'JSON success envelope data, often null' and suggests calling after get_worker_task. Annotations already include idempotentHint=true, but the description adds workflow and partial-update semantics without contradiction.

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

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

The description is structured with headers and front-loaded with the key statement. However, the Chinese trigger appears to be an irrelevant copy-paste error and the WHEN NOT TO USE section references unrelated APIs, adding noise without value. Overall it is moderately concise but contains extraneous 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?

The description provides a clear workflow, return behavior, and when-to-use guidance. Combined with the 100%-detailed schema, the agent has most context needed to call it correctly. The misleading Chinese trigger and vague exclusion about internal APIs slightly reduce completeness, but the core guidance is present.

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 covers 100% of parameters with detailed descriptions and examples, so the baseline is 3. The description's general 'omit fields to keep current values' reinforces what the schema says for title, and all parameters are already well-documented. No additional parameter-specific semantics are needed.

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 opening sentence 'Update a saved CoreClaw worker task's metadata and schedule' clearly identifies the verb, resource, and scope. It distinguishes the tool from siblings like run_worker_task and update_worker_task_input, and the partial-update note adds useful precision.

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 English 'WHEN TO USE' correctly scopes the tool to changing title, description, or schedule. However, the Chinese trigger states to use this tool when the user wants to query, run, rerun, stop, export, or view task data, which directly contradicts the tool's purpose and overlaps with many sibling tools. This misleading guidance undermines usage clarity.

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 provide idempotentHint=true and destructiveHint=false; description adds that it returns 'JSON success envelope data, often null', which is useful. 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 well-structured with sections and is informative, though the Chinese trigger line adds minor redundancy. Overall concise for the amount of information provided.

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 3 parameters, no output schema, and annotations present, the description covers the workflow (confirmation step, follow-up with run_worker_task) and return type, which provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters well. The description only adds workflow context ('Call after get_worker_task_input') but does not add extra meaning to individual parameters 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 'Update the input payload for a saved CoreClaw worker task' with a specific verb and resource. It also hints at sibling differentiation by noting it does not modify title/schedule, but does not explicitly mention `update_worker_task` as alternative.

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?

Includes a WHEN TO USE section specifying the scenario (change input parameters without modifying title/schedule) and WHEN NOT TO USE with guidance against public search and internal APIs. Could be improved by mentioning sibling tool `update_worker_task` explicitly.

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 false, but the description adds key behavioral details: it inspects leading result rows ('real-data sniff'), returns specific verdicts including ERROR_RECORD to avoid false-PASS traps, and explains the JSON return structure. This goes beyond annotations by clarifying the validation logic and the meaning of verdicts.

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 well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loads the core purpose. However, it includes some extraneous content: the '中文触发' section is overly broad and unrelated to verification, and 'Do not call excluded internal worker-version or internal-detail APIs' is vague and not tool-specific. Still, most sentences earn their 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 tool with no output schema, the description is impressively complete. It covers the purpose, usage timing, alternatives, return values with all verdicts and fields, and workflow integration with sibling tools. An agent can confidently decide when and how to invoke this tool, and understand what to expect in response.

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

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

Schema description coverage is 100%, so both parameters (run_id and limit) already have descriptions. The tool description does not significantly add semantic meaning beyond the schema; it only indirectly references the limit via 'real-data sniff' and the run_id via workflow examples. Since the schema does most of the work, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Verify a CoreClaw worker run produced real, usable data and return a structured PASS/NO_DATA/FAILED/ERROR_RECORD verdict.' It uses a specific verb (verify), names the resource (CoreClaw worker run), and specifies the outcome (verdict). It also differentiates itself from sibling tools like get_worker_run or poll_run by emphasizing that it distinguishes genuine data from error records, which is a unique acceptance-check role.

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 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It states to use after a run reaches a terminal state and mentions using get_worker_run_log for failure diagnosis and export_worker_run_results for full data, giving alternatives. It also clearly warns against using public search or internal APIs for this private data. This is thorough and actionable guidance.

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