mcp-coreclaw

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

Annotations already indicate destructiveHint=true, but the description adds return format ('JSON success envelope, often null') and workflow context. 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 labeled sections, no redundant information, 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?

Covers purpose, usage, return, and workflow. Given no parameters and simple action, the description is fully complete for correct tool 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?

No parameters exist, so description does not need to explain them. Baseline 4 as per guidelines for zero 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 clearly states the verb 'abort', the resource 'current user's most recent CoreClaw worker run', and distinguishes from sibling tools like 'abort_worker_run' by specifying 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?

Includes explicit 'WHEN TO USE' (stop/cancel last running job) and 'WHEN NOT TO USE' (avoid public search for private data), plus workflow instruction to call after get_last_worker_run confirms active 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 indicate destructive and idempotent behavior. The description adds that it returns a JSON success envelope (often null) and workflow context. 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?

Well-structured with sections, front-loaded action statement. Every section is informative, though slight redundancy in the Chinese trigger line 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?

Given the tool's simplicity (1 param, no output schema) and sufficient annotations, the description covers purpose, usage, behavior, parameter, and workflow comprehensively.

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. Description adds example values ('demo-worker', 'owner~demo-worker') and source (list_store_workers or list_workers), going 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 the action ('Abort the most recent run') and the resource ('specific CoreClaw worker'), distinguishing it from sibling tools that abort other runs or perform other operations.

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

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

Includes explicit WHEN TO USE and WHEN NOT TO USE sections, providing clear context for when to call this tool (cancel latest active run) and when to avoid (public web search, excluded APIs). Also mentions workflow dependency on get_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 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 indicate destructiveHint=true, consistent with creation. Description adds return value details (JSON with slug) and workflow context, but does not elaborate on permissions or potential side effects. Still, it aligns well with annotations and provides useful behavioral clues.

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 labeled sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Front-loaded with the core purpose, each sentence serves a purpose without redundancy.

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

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

Given 11 parameters, no output schema, and 33 sibling tools, the description is complete. It covers tool purpose, usage boundaries, return format, and subsequent workflow, enabling informed use without extra 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 coverage is 100% with detailed descriptions for all 11 parameters. The description summarizes the overall structure but does not add extra meaning beyond the schema, meeting the baseline for high-coverage scenarios.

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 'Create a new saved CoreClaw worker task with input and optional schedule', specifying the verb, resource, and key attributes. It distinguishes from siblings like update_worker_task and delete_worker_task by focusing on creation with schedule support.

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' and 'WHEN NOT TO USE' sections, detailing when to create a saved task and when to avoid using this tool. Also provides a workflow hint to follow with run_worker_task using the returned worker_task_id, guiding the agent on next 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 and idempotentHint. Description adds return type (JSON success envelope, often null) and workflow context (call after list/get). 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?

Well-structured with clear sections, no wasted words. Front-loaded with the essential 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 large sibling set, the description adequately covers what an agent needs: destructive action, idempotent, parameter source, usage constraints, and workflow. Complete for a delete 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 already covers the parameter with description and example. The tool description adds value by advising to obtain the ID from list/get tools, which guides 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?

Clearly states the verb 'delete' and the resource 'saved CoreClaw worker task'. Distinguishes from sibling tools like create, update, 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. Provides a Chinese trigger and specifies to call after list/get to confirm existence. Guides against using for public search or excluded 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read operation. The description adds that it returns a JSON with a temporary download_url, which is useful context about the response. This goes beyond 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-structured with clear headings (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Each sentence serves a purpose, and it is concise without wasted words. 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 no output schema, the description explains the return type (JSON with temporary download_url) and provides a workflow hint (call after get_last_worker_run success). However, it lacks details about URL expiration or error handling, which would improve completeness.

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

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

Schema coverage is 100%, so the input schema already fully describes both parameters (format with enum/default, filter_keys with example). The description adds no additional semantic value beyond schema. Baseline 3 is appropriate.

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

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

The description explicitly states it exports the current user's most recent CoreClaw run results. It distinguishes from sibling tools like 'export_worker_last_run_results' by being user-specific and not tied to a particular worker. Verb (export), resource (last run results), and scope (current user) are clear.

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

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

Includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections with specific triggers (e.g., user asks to download latest run as CSV/JSON) and exclusions (public web search, internal APIs). Provides clear guidance on when to select 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 already indicate read-only and idempotent. The description adds behavioral context: it returns a temporary download URL and requires the worker run to be succeeded. This workflow hint is valuable 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 very concise with clear sections (main purpose, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence adds value without 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 simple tool, the description covers purpose, usage context, return format, and a workflow prerequisite. No output schema is present, but the description adequately explains what is returned (JSON with download URL).

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% coverage with descriptions for all three parameters. The tool description adds no additional parameter-specific meaning beyond the schema, meeting the baseline expectation.

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 the specific resource 'results from the most recent run of a specific CoreClaw worker'. It distinguishes from siblings like 'export_worker_run_results' by focusing on '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 provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, including example triggers. It could be improved by directly contrasting with sibling export tools for non-last runs, but is still well above minimal.

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 temporary download_url, providing behavioral context 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 sections, but includes a redundant Chinese line ('中文触发...') that may not be necessary for most agents. Could be slightly more concise, but overall good.

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 states the return type (JSON with temporary download_url). Parameter coverage is complete. Includes workflow guidance and differentiations. The tool has moderate complexity and the description covers all needed 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 description coverage is 100% (all params have descriptions). The description does not add significant meaning beyond the schema; it merely repeats or lightly references the parameters. With full coverage, baseline is 3.

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

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

The description clearly states 'Export result data for a specific CoreClaw worker run' (specific verb+resource). It distinguishes from sibling tools like export_last_worker_run_results and export_worker_last_run_results by focusing on a specific run identified 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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It advises using when user wants to download/save output from a known run, and not for public web search or excluded internal APIs. Also provides workflow hint to 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, destructiveHint. Description adds value by stating return format (JSON with balance and balance_expiration_at) and workflow context (preflight before run_worker), without 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?

Description is concise and well-structured: one sentence for purpose, then separate sections for WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW. 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 no output schema, the description explains return type and key fields. Provides usage context and workflow suggestion. Annotations cover safety. Adequate for a simple account info 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 has zero parameters; schema description coverage is trivially 100%. Description adds no parameter info, which is appropriate. Baseline for 0 parameters is 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 the verb 'Get', the resource 'current user's CoreClaw account balance and traffic quota', and distinguishes from sibling tools focused on worker runs/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' section lists specific user queries (balance, traffic, quota, billing) and includes Chinese trigger. 'WHEN NOT TO USE' warns against public web search and internal APIs, providing clear exclusions.

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

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

Annotations 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, idempotentHint=true, destructiveHint=false. Description adds that it returns JSON with specific fields (title, description, worker_id, input, schedule, slug) and that it's a read operation. No additional behavioral caveats (auth, rate limits) needed beyond annotations. Value added is moderate but not essential.

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 adds value, no redundancy. Concise and easy to scan.

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

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

For a simple get-detail tool with one parameter, no output schema, and strong annotations, the description covers purpose, usage, return content, and next steps. Complete and actionable.

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_task_id, with clear type, required, and description. The description enhances this with a concrete example ('task_daily_demo') and source guidance ('Obtain from list_worker_tasks'), adding practical context 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 'Get detail for a specific saved CoreClaw worker task,' identifying the verb (get), resource (worker task), and scope (specific saved task). It distinguishes from siblings like list_worker_tasks (list all) and get_worker_task_input (get input only).

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 on when to use (inspecting task config, schedule, input) and when not (public web search, excluded APIs). Also includes Chinese trigger keywords and follow-up workflow suggestions.

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 return format details (JSON with input object and version field) and notes the scope ('saved' tasks), providing useful 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 highly organized with clear sections (purpose, when to use/not use, returns, workflow) and is fully front-loaded. Every sentence adds value without redundancy, making it efficient and easy to parse.

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

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

For a simple tool with one parameter, good annotations, and no output schema, the description covers purpose, usage boundaries, return value, and recommended next steps. It is complete and leaves no significant gaps for an AI agent to infer.

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

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

Schema description coverage is 100% and already provides a clear description and example for the single parameter. The description does not add any additional meaning 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 'Get the input payload for a saved CoreClaw worker task', a specific verb+resource. The WHEN TO USE section reinforces this purpose, and it distinguishes from siblings like get_worker_task by focusing on the input payload.

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 中文 trigger phrase. The WORKFLOW section suggests follow-up tools, guiding the agent on when to use 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, 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 already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context on async/sync behavior, return values (run_slug vs synchronous results), and the workflow order, going beyond what annotations provide.

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

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

The description is well-structured with clear sections and a concise opening sentence. It is slightly lengthy due to the Chinese trigger and workflow enumeration, but all information is relevant and easy to parse.

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

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

Given 8 parameters and no output schema, the description thoroughly explains return formats, workflow steps, and parameter constraints (e.g., async/sync, input_json usage). It also covers edge cases like omitting input_json when no business fields exist.

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 adds workflow context (e.g., call get_worker_input_schema first) and clarifies parameter relationships (e.g., input_json vs raw_input_json cannot be combined), providing meaningful additional guidance.

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 a CoreClaw worker with ad-hoc JSON input, and distinguishes from sibling tools by providing a WHEN TO USE section and explicit exclusions like public search and internal APIs.

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 on when to invoke this tool versus alternatives, including a Chinese trigger for non-English users and exclusions for excluded 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 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.

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

Annotations provide readOnlyHint=false (write), idempotentHint=true, destructiveHint=false. Description adds 'RETURNS: JSON success envelope data, often null.' It does not detail side effects or permissions but is consistent. Adding return format 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?

Structured with clear sections (main, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Each sentence is informative and necessary. No redundancy or fluff.

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

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

Covers purpose, usage, return, and workflow. With 9 parameters and no output schema, it provides adequate context. Lacks explicit mention of idempotency or behavior on partial updates, but still complete enough.

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 detailed descriptions and examples. The tool description reinforces parameter purpose ('title, description, or schedule settings') in the usage guide, adding context beyond 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 'Update a saved CoreClaw worker task's metadata and schedule,' specifying the verb and resource. It distinguishes from sibling tools like create_worker_task and update_worker_task_input by mentioning 'metadata and schedule' and noting the separate input update tool.

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

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

Explicit WHEN TO USE section: 'Use when the user wants to change a task's title, description, or schedule settings.' WHEN NOT TO USE excludes public search and internal APIs. WORKFLOW guides to call after get_worker_task and mentions update_worker_task_input for payload changes.

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 idempotentHint=true and destructiveHint=false, aligned with description. Description adds return type ('JSON success envelope data, often null') and workflow context, 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?

Well-structured with sections: main sentence, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW. Extremely concise with 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?

For a tool with 3 parameters and no output schema, the description covers purpose, usage, workflow, and return. Could be slightly more specific about the return value (e.g., whether it's the updated input), but overall 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% with parameter descriptions. Description adds value by referencing get_worker_input_schema for input_json structure and listing worker_task_id example. Baseline 3 elevated due to 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 the verb 'Update' and the resource 'input payload for a saved CoreClaw worker task'. It distinguishes from siblings like update_worker_task (title/schedule) and run_worker_task (execution).

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 (changing input parameters without modifying title/schedule) and WHEN NOT TO USE (avoiding public search or excluded APIs). Provides workflow instructions (call after get_worker_task_input, before run_worker_task) and even 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.