mcp-coreclaw

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

Annotations provide destructiveHint=true and idempotentHint=true, so the description does not need to cover those. It adds useful context via the WORKFLOW and RETURNS sections, but could describe what aborting entails for run state.

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 section headers (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It front-loads the core purpose and avoids 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?

The description provides usage guidance and a workflow reference, but lacks details on error handling, permissions, or behavior when no run exists. Given no output schema, this leaves some gaps for a tool with optional parameters that are not clearly linked to the operation.

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

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

Although schema description coverage is 100%, the description does not clarify how parameters like limit, offset, is_async, and callback_url apply to aborting a run. The schema definitions are generic, and the description misses the opportunity to contextualize them.

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

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

The description clearly states 'Abort the current user's most recent CoreClaw worker run', specifying a distinct verb and resource. It differentiates from siblings like 'abort_worker_run' by focusing on the most recent run and the current user, though some sibling names are similar.

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, including a specific workflow instruction ('Call after get_last_worker_run confirms the last run is still active'). This clearly guides the agent on when to choose this tool over 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 declare destructiveHint=true and idempotentHint=true, which align with the 'Abort' verb. The description adds that the tool returns 'JSON success envelope data, often null.' This provides some additional context beyond annotations but does not elaborate on side effects or further behavioral traits.

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

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

The description is structured with clear sections (action, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). However, it includes Chinese text that may be redundant for an English-speaking AI agent. It is slightly verbose for the content 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?

Given the tool has 5 parameters, many sibling tools, and no output schema, the description provides useful context including when to use, workflow, and return type. It could be more complete by explaining abort mechanics or idempotency implications, but the current coverage is adequate.

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

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

Schema coverage is 100%, so the schema already documents all 5 parameters. The description does not add any parameter-specific semantics beyond what the schema provides. It mentions a workflow that indirectly relates to worker_id but no direct elaboration on parameter 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 'Abort the most recent run for a specific CoreClaw worker.' It specifies the verb (abort) and resource (most recent run of a worker). However, among sibling tools like 'abort_last_worker_run' and 'abort_worker_run', it does not explicitly differentiate, though the 'most recent' qualifier helps distinguish from aborting a specific 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?

The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It tells when to use (cancel the latest active run of a known worker) and when not to use (avoid public search or internal APIs). It also provides a workflow hint to call after get_worker_last_run confirms the run is active. This is comprehensive guidance.

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

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

Annotations already indicate destructive hint=true. The description adds behavioral context: it aborts a run, returns a JSON envelope (often null), and specifies calling after confirming status via get_worker_run.

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, but contains some redundancy (e.g., Chinese trigger and repeated warnings about internal APIs) that could be trimmed for brevity.

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 abort action with one parameter, the description covers all necessary aspects: when to use, when not, return value, and workflow steps, making it fully self-contained.

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

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

With 100% schema coverage and a single parameter (run_id) that is well-described in the schema, the description adds no additional semantic information beyond the example and source guidance already present.

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 'abort', the resource 'worker run', and the identifier 'run_id', distinguishing it from siblings that target 'last' 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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear context for when to invoke this tool (to cancel a known running run) and when not to, including references to alternative tools and internal APIs.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful context: returns JSON with a temporary download URL and workflow dependency, which goes beyond the annotations but doesn't contradict 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?

Description is well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is somewhat verbose due to the Chinese text, but each sentence adds value. Could be slightly trimmed without losing meaning.

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

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

Given the simple export functionality and absence of output schema, the description covers essential aspects: purpose, usage, return type, and workflow. It is sufficiently complete 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?

Input schema has 100% description coverage for both parameters (format and filter_keys), so the schema already explains them adequately. The description adds no extra parameter-level detail beyond what the schema provides, meeting the baseline.

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

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

The description clearly states the tool exports the current user's most recent run results with verb and resource. However, it does not explicitly differentiate from the very similar sibling tool 'export_worker_last_run_results', which could cause confusion for an AI agent.

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 concrete examples (download as CSV/JSON) and Chinese triggers. Also specifies workflow dependency on get_last_worker_run success, offering clear guidance on when to invoke.

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 a temporary download_url, which adds value. However, it doesn't mention URL expiration or error cases, missing some transparency 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 clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence adds value, no fluff. Front-loaded with 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 complexity (3 params, no output schema, simple return type), the description covers purpose, usage guidelines, return type, and workflow. It is sufficient for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. Description adds no extra parameter details beyond the schema; it only mentions workflow context. The parameter descriptions in the schema are adequate, but the description doesn't enhance them.

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

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

The description clearly states the tool exports results from the most recent run of a specific CoreClaw worker. It distinguishes from siblings like export_worker_run_results and list_... results by specifying 'most recent 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, providing clear context for when to call this tool vs alternatives (e.g., not for public search). Also includes workflow guidance to call after get_worker_last_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 known. The description adds that it returns a temporary download_url and reinforces the export nature, providing modest additional 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?

Highly concise and well-structured with clear section headings (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence is purposeful, no redundancy.

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

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

No output schema, but description explains return value (JSON with download_url) and workflow prerequisite. Parameters are well-documented in schema. For a moderate-complexity tool with 3 params, this is nearly 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?

Input schema has 100% description coverage for all 3 parameters. Description does not add meaning beyond what the schema already provides, but neither does it contradict or miss. 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?

Clearly states the tool exports result data for a specific CoreClaw worker run. Distinguishes from sibling tools like export_last_worker_run_results and export_worker_last_run_results by being specific to a given 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?

Provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, including a Chinese trigger phrase and a workflow step (call after get_worker_run shows succeeded). Gives clear context and exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the return format (JSON with balance, traffic, traffic_expiration_at) and workflow (terminal call or preflight before run_worker). 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 sections for WHEN TO USE, WHEN NOT TO USE, RETURNS, and WORKFLOW. Every sentence adds value without redundancy, achieving conciseness while remaining informative.

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

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

For a zero-parameter read-only tool, the description fully covers purpose, usage context, return format, and workflow. Despite no output schema, the return fields are specified, making it complete for agent 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 tool has no parameters (0 params) and schema coverage is 100%. Per guidelines, baseline is 4; no additional parameter information is 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 description clearly states the tool retrieves the current user's account balance and traffic quota. It uses a specific verb 'Get' and resource, easily distinguishing it from sibling tools focused on worker runs and 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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance, including specific user queries (balance, traffic, quota) and Chinese triggers. It also advises against using alternative tools for this 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, idempotentHint, destructiveHint. The description adds value by detailing the return JSON structure and workflow context, but does not reveal any additional safety or behavioral nuances 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?

Well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Each sentence is informative and necessary, 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 zero parameters and no output schema, the description fully covers what the tool does, its return structure, and how to follow up. No 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?

No parameters exist (empty input schema), so baseline is 4. The 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 it returns the current user's most recent CoreClaw worker run, listing specific fields (slug, status, worker, version, etc.). It is distinct from siblings by specifying scope (current user) and providing workflow guidance.

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 section with example user phrases and Chinese triggers, and WHEN NOT TO USE section that excludes public web search and internal APIs. Also provides a WORKFLOW list of subsequent tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's safety profile is covered. It adds behavioral context by stating returns are in JSON format and advising on workflow sequence, which is useful 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 structured with clear sections (first sentence, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is concise, every sentence adds value, and the key information is front-loaded.

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

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

Given the tool's simplicity (no parameters, no output schema) and existing annotations, the description is complete. It covers purpose, usage guidelines, return type, and workflow, leaving 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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds value by implicitly defining the scope ('current user's most recent run'), which clarifies that no parameters 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 description clearly states it gets logs for the current user's most recent worker run. It specifies the resource (CoreClaw worker run) and scope (current user, most recent), distinguishing it from siblings like get_worker_run_log which may require a specific 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?

The description includes explicit WHEN TO USE and WHEN NOT TO USE sections. It advises using when debugging failed/stalled runs and explicitly warns against using public web search or internal APIs. It also provides workflow guidance to call after get_last_worker_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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it returns JSON with specific fields, but does not contradict annotations. No additional behavioral traits needed 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?

Description is well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). However, includes Chinese text ('中文触发') which may not be necessary for all agents, slightly reducing conciseness.

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

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

Given the tool is read-only with one parameter and no output schema, the description is complete: states return format (JSON with worker name, username, version, readme, parameters) and suggests next steps. Annotations cover safety aspects.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the 'worker_id' parameter format (slug or owner path) and provides example (e.g., 'demo-worker' or 'owner~demo-worker'), and source (from list_store_workers or list_workers).

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' with specific verb and resource, and distinguishes from sibling tools like get_worker_run, get_worker_input_schema, etc.

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 states when to use ('before running a worker to inspect version, README, and parameters'), when not to use ('Do not use public web search or code search for private CoreClaw platform data'), and provides workflow ('Follow with get_worker_input_schema and then 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=true, idempotentHint=true, destructiveHint=false. The description adds that the schema is 'public' and returns 'JSON with input_schema', consistent with annotations. 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). Slightly lengthy due to bilingual content, but every sentence adds value. Front-loaded with 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 single parameter, rich annotations, and no output schema, the description provides enough context: when to use, what it returns, and workflow integration. Could mention if auth is required, but 'public' implies minimal access control.

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?

Only one parameter (worker_id) with schema coverage 100%. The schema description already provides example and source. The tool description does not add extra semantic value beyond the schema.

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

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

Clearly states it gets the public input JSON schema for a CoreClaw worker. Distinguishes from sibling tools which focus on runs, logs, or worker details.

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

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

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. Advises using before run_worker and lists exclusions like public search or internal APIs. Also includes a Chinese trigger phrase.

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=true, destructiveHint=false, and idempotentHint=true. The description adds the return format ('JSON with last run details') and a workflow hint, providing beneficial context beyond annotations 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 into clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and front-loads the purpose. Each section adds value without redundancy, though it is slightly longer than necessary.

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 covers purpose, usage conditions, return format, and workflow. It differentiates from siblings like get_worker_run but does not explicitly distinguish from the similarly named get_last_worker_run.

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', and the schema description already provides detailed syntax and examples. The tool description does not add new parameter information, 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 the most recent run for a specific CoreClaw worker,' using a specific verb and resource. The WHEN TO USE section further differentiates it from siblings by specifying it's for last-run queries, distinguishing it from tools like get_worker_run or list_worker_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?

Explicit WHEN TO USE and WHEN NOT TO USE sections provide clear context and exclusions, including examples of triggers and contrast with internal APIs. The WORKFLOW section also suggests appropriate follow-up actions, fully guiding the agent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds that it returns JSON log data and suggests workflow (call after get_worker_last_run). No contradictions, but the description adds minimal behavioral context 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 clear sections (purpose, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence adds value without redundancy, and it's appropriately 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?

Given no output schema, the description mentions 'JSON with log data' but lacks details on return structure. However, with full parameter schema coverage, a simple use case, and workflow hint, it is reasonably complete. Missing return format details prevent a perfect score.

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

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

Schema description coverage is 100% for the single required parameter (worker_id), with examples and source hints. The tool description does not add further parameter semantics, 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 'Get logs for the most recent run of a specific CoreClaw worker', specifying verb (Get), resource (logs), and scope (most recent run). It distinguishes from siblings like get_worker_run_log and get_worker_last_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?

Description includes explicit WHEN TO USE (debugging latest run) and WHEN NOT TO USE (public search, internal APIs). However, it does not directly exclude or compare to sibling tools like get_worker_run_log, leaving some ambiguity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that it returns a JSON with run status, worker, version, timestamps, etc., which goes beyond annotations. 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 (description, when to use, when not, returns, workflow). It is slightly verbose due to the Chinese trigger text, but overall front-loaded and each section serves a purpose.

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

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

For a simple getter tool with one parameter and no output schema, the description is quite complete. It lists the return fields and suggests follow-up tools. Missing error handling details but acceptable given the simplicity.

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

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

Schema coverage is 100% for the single parameter run_id, so baseline is 3. The description adds an example value and explains how to obtain it ('Obtain from run_worker, list_worker_runs, or get_last_worker_run'), which provides meaningful extra context.

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 specific CoreClaw worker run by run_id', using a specific verb and resource. It distinguishes from siblings like get_last_worker_run and get_worker_run_log by focusing on a specific run by 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 section with concrete triggers (user gives run id, wants status/cost/detail), including a Chinese trigger. WHEN NOT TO USE section clearly excludes public web search, code search, and internal APIs. Also suggests subsequent workflow tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; description adds that it returns JSON log data and workflow context. No contradictions, but doesn't detail behavior beyond what's inferred.

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?

Concise and well-structured: front-loaded purpose, then usage guidelines, return type, and workflow. Every sentence adds value with no waste.

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

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

For a simple, single-parameter tool with good annotations and schema coverage, the description is complete enough, covering purpose, usage, workflow, and return type.

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, which includes a clear description and example. The description does not add significant extra semantics beyond the schema.

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

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

Clearly states 'Get logs for a specific CoreClaw worker run' and distinguishes from sibling tools by specifying it returns logs for a known run ID, with guidance on obtaining the ID from other 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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, providing clear context for debugging failed/stalled runs and excluding alternative search approaches, helping the agent select the correct 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, destructiveHint=false, and idempotentHint=true. The description adds that it returns JSON with result rows and pagination metadata, and provides a workflow hint. 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 (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). While slightly long, every sentence adds value. Could be slightly more concise but overall 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 specifies return type (JSON with result rows and pagination metadata). Includes workflow steps and differentiation from similar tools. Complete for the tool's complexity.

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

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

Schema coverage is 100%, so the description does not need to add parameter info. It mentions 'paginated results' which aligns with limit/offset but adds no new semantics beyond the schema. 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, specifying the exact resource and scope. It distinguishes from sibling tools like list_worker_last_run_results and list_worker_run_results by focusing on the current user's last 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, including alternative tool suggestions and a workflow step (call after get_last_worker_run shows success). Chinese trigger phrase aids non-English users.

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 'JSON with a list of proxy regions and region codes,' which is consistent and provides a bit more detail about the output, though not extensive.

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 (main, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence is purposeful and front-loaded. 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?

Despite no output schema, the description specifies the return type as 'JSON with a list of proxy regions and region codes,' which is adequate for a simple list tool. However, it could be more explicit about the exact fields in each region object.

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 a single optional 'language' parameter, and the schema already describes it as 'Region display language.' The description mentions 'English or Chinese' and 'regional display language,' adding marginal value beyond the schema.

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

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

The description clearly states 'List CoreClaw proxy regions in English or Chinese,' specifying the action and resource. It is specific but does not explicitly differentiate from sibling list tools, though the resource 'proxy regions' is unique.

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 'WHEN TO USE' and 'WHEN NOT TO USE' sections with explicit context, examples (US, JP, DE), and even Chinese triggers. Also provides a workflow indicating when to call before run_worker. This leaves no ambiguity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating the return format (JSON with slug, path, title, etc.) and workflow context, but does not contradict annotations.

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

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

The description is well-structured with clear sections (WHEN TO USE, etc.), concise yet informative. Chinese translations add length but are efficient for localization.

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 (3 optional params, no output schema, good annotations), the description covers purpose, usage, return format, and workflow completely.

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 all three parameters described. The description mentions searching 'by keyword or site name' which aligns with the keyword parameter but adds no additional semantic detail beyond the schema.

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

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

The description clearly states the tool searches the public CoreClaw worker marketplace for ready-to-run workers. It uses a specific verb-resource pair ('search the ... marketplace') and distinguishes from siblings like 'list_workers' which likely list private workers.

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

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

The description provides explicit WHEN TO USE, WHEN NOT TO USE, and WORKFLOW sections. It specifies when to use (find, discover, browse by keyword) and when not to use (public web search for private data, internal APIs), plus typical workflow first step.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond annotations by stating it returns JSON with result rows and pagination metadata, and that pagination is controlled via limit/offset. 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 headings (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is concise, with every sentence adding value. No wasted 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?

Despite having no output schema, the description explains what the tool returns (JSON with result rows and pagination metadata). It covers usage context, preconditions, and alternatives (export for large output). Annotations are rich, so the description completes the picture adequately.

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% with all parameter descriptions. The description does not add further details about parameters, but it provides context about pagination and workflow. Baseline of 3 is appropriate as schema already documents parameters.

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

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

The description uses a specific verb ('List') and resource ('paginated results from the most recent run of a specific CoreClaw worker'). It clearly distinguishes this tool from siblings like list_worker_run_results (which lists results from any run) by emphasizing 'last 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?

The description explicitly states when to use ('user wants latest output rows for a known worker') and when not to use (public web search or internal APIs). It also provides a workflow: call after get_worker_last_run shows succeeded, and use export_worker_last_run_results for large output.

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. The description adds that it returns JSON with result rows and pagination metadata, and clarifies it is non-destructive. 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, but slightly verbose. Every sentence earns its place, providing necessary 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?

For a tool with no output schema, the description adequately describes return type (JSON with result rows and pagination metadata). It also links to related tools, making the context 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 coverage is 100%, but the description adds value by explaining that run_id can be obtained from other tools and that the tool lists paginated results. It also mentions the workflow dependency, enriching parameter context.

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 paginated results for a specific CoreClaw worker run,' which is a specific verb+resource. It distinguishes from sibling tools like export_worker_run_results by noting its paginated nature.

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 (known run id) and WHEN NOT TO USE (public web search, internal APIs). Also provides workflow guidance: call after get_worker_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, indicating safe read operation. The description adds context about the return JSON structure (count, list, timestamps) and mentions typical workflow follow-ups, which goes 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 headers (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and is concise overall. However, the inclusion of Chinese trigger text ('中文触发') adds minor redundancy for an English 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?

Given the tool's purpose (listing runs), no output schema, and rich sibling set, the description provides sufficient context: return format, suggested follow-up actions, and clear scope. It covers key aspects for an AI agent to decide when 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?

Schema coverage is 100%; all four parameters have detailed descriptions and constraints (limit, offset, status enum, worker_id). The description does not add further parameter semantics 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 'List the current user's CoreClaw worker runs', specifying both the resource (worker runs) and scope (current user). This distinguishes it from siblings like get_worker_run (single run) and list_worker_run_results (results of a 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?

The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, stating use cases like run history or finding a run_id, and exclusions like public web search or internal APIs. It also references alternative follow-up tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the return format (JSON with fields like slug, path, title, username, description) and suggesting follow-up workflow steps, enhancing transparency 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 clear sections (description, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) and no unnecessary words, making it easy to parse and understand.

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 lists return fields and suggests follow-up tools. All parameters are documented, and annotations cover safety. The description is complete for an agent to understand and 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?

Input schema has 100% description coverage for all 3 parameters (limit, offset, keyword). The description does not add additional parameter-level information beyond what the schema provides, so 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 specific action ('List'), resource ('CoreClaw workers'), and scope ('owned by the current user'), which distinguishes it from sibling tools like 'list_store_workers' for public marketplace workers.

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

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

The description provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, guiding the agent to use this tool for private/current-user workers and avoid public marketplace or internal APIs, clearly differentiating it from 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, idempotentHint, and destructiveHint. The description adds context that it returns a JSON list and is scoped to the current user, which is valuable beyond annotations. 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 with clear sections (main purpose, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It front-loads the primary action and avoids unnecessary 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 no output schema, the description states returns 'JSON list of saved worker tasks', which is minimal but sufficient. The workflow note adds context. Parameters are fully described in the schema, and the usage sections cover edge cases.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add extra semantics beyond the schema, although it mentions 'task ids' in usage context indirectly.

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

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

The description clearly states it lists saved CoreClaw worker tasks for the current user, using a specific verb and resource. It differentiates from sibling tools like list_worker_runs and list_workers by focusing on 'saved tasks', and provides explicit triggers in both English and Chinese.

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, detailing scenarios for using this tool and excluding inappropriate alternatives like public web search or internal APIs. It also suggests a workflow to follow with 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 indicate destructiveHint=true, and the description adds context: returns a new run_slug, follows with other tools, and mentions sync vs async. Provides behavioral detail 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?

Well-structured with sections (WHEN TO USE, etc.) and front-loaded main sentence. Each section adds value, though slightly verbose. No redundancy.

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

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

No output schema, so return description is needed but vague ('new run_slug or synchronous result fields'). Workflow mentioned but parameter effects on behavior not fully explained. Adequate for a destructive tool with 4 optional params.

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 clear parameter descriptions, so baseline is 3. The description does not add significant meaning to parameters beyond 'same saved inputs'; purpose of limit/offset is not explained in context.

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 reruns the current user's most recent CoreClaw worker run with saved inputs, distinguishing it from siblings like rerun_worker_run (specific run) and run_worker (new 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?

Includes explicit WHEN TO USE (user phrases like 'rerun last', Chinese triggers) and WHEN NOT TO USE (excludes public search and internal APIs), plus workflow guidance. Clearly differentiates from 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 indicate destructiveHint=true, and the description confirms it creates a new run. It adds that returns JSON with new run_slug. While more detail on side effects could be added, it's adequate given 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). Every sentence adds value, no fluff.

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

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

Given 5 parameters and no output schema, the description states return format (JSON with new run_slug) and workflow. It could detail synchronous vs async behavior more, but is fairly 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 coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema provides for any parameters. No explicit parameter details in the description text.

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

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

The description clearly states 'Rerun the most recent run for a specific CoreClaw worker.' This is a specific verb+resource+scope, and it distinguishes from siblings like rerun_worker_run which reruns a specific 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?

The description provides explicit WHEN TO USE and WHEN NOT TO USE sections, including a Chinese trigger and instructions to avoid public web search and excluded internal APIs. It also suggests a follow-up 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 declare destructiveHint=true and readOnlyHint=false. The description adds that a new run_slug is returned but does not elaborate on destructive consequences or side effects beyond that. 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?

Description is well-structured with clear sections (main, when to use, when not to use, returns, workflow). No redundant sentences.

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 5 parameters and no output schema, the description explains return format and workflow. However, it does not cover edge cases like run already running or nonexistent run.

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 descriptions for all parameters. The description does not add additional meaning beyond the schema; it merely restates that a run_id is 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 description clearly states it reruns a specific worker run with saved inputs, differentiating from sibling tools like 'rerun_last_worker_run' by specifying 'specific' and using a 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?

Explicitly provides WHEN TO USE and WHEN NOT TO USE sections, including a trigger phrase in Chinese and English, and warns against using public search or internal APIs. Also suggests follow-up 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 indicate destructive, non-idempotent, read-write behavior. The description adds context about return values (run_slug or sync results) and workflow steps, but could mention permissions or side effects more explicitly.

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 (main description, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Each sentence is purposeful and no 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 8 parameters, 1 required, and no output schema, the description covers workflow, return types, and usage guidance. It is mostly complete but missing error handling or permission requirements.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add much beyond schema, but explains raw_input_json as an escape hatch and input_json vs raw_input_json not to combine. This provides minor added value.

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 'run' and the resource 'CoreClaw worker', and distinguishes from sibling tools like abort, get, list, etc. It also specifies ad-hoc JSON input payload, making the purpose unambiguous.

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

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

Explicit WHEN TO USE and WHEN NOT TO USE sections with specific conditions, including Chinese trigger text and excluded internal APIs. It also recommends using get_worker_input_schema first and provides workflow steps.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds behavioral context about synchronous vs async execution (via is_async param) and callback URL. It doesn't contradict annotations and provides useful workflow context, though it doesn't elaborate on destructive implications.

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

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

Structured with sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW) making it scannable. The inclusion of Chinese text (中文触发) adds redundancy for an English-based AI, but overall it's well-organized and front-loaded with the main 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 5 parameters, no output schema, and many sibling tools, the description provides workflow guidance (follow with get_worker_run) and return type (JSON with run_slug or synchronous results). It covers when to use and not use, and mentions async support, making it fairly complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with all 5 parameters described. The description adds no additional parameter meaning beyond the schema; it only mentions return fields (run_slug or synchronous result). Baseline of 3 is appropriate as the schema carries the load.

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

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

The description clearly states 'Run a saved CoreClaw worker task,' specifying the verb (run), resource (saved worker task), and distinguishing from ad-hoc worker runs (sibling run_worker). The mention of saved vs ad-hoc differentiates it from similar 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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear context, including a 中文触发 example. It tells when to use (execute a configured task) and when not (avoid public search for private data, avoid excluded APIs). Also suggests follow-up tools like get_worker_run.

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