mcp-coreclaw

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

The description elaborates on the destructive nature (transition to status 5 then 4, terminal call) beyond the destructiveHint annotation. It adds specific behavioral details (no pause/resume) that help the agent understand the tool's safety profile.

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

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

The description is concise, well-structured with clear sections, and every sentence serves a purpose. No redundant or vague language.

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

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

Despite lacking an output schema, the description explicitly states the return values (run_slug, status). It also provides workflow context (preceded by status checks). For a single-parameter terminal operation, this is complete.

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

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

The description does not add significant meaning beyond the input schema for the single parameter run_slug. The schema already provides an example and source instruction. With 100% coverage, baseline 3 is appropriate.

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

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

The description clearly states the action ('abort') and the resource ('in-progress CoreClaw scraper run'), with explicit examples in English and Chinese. It distinguishes from sibling tools like run_scraper or get_run_status by focusing on stopping, not starting or monitoring.

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 specific conditions (only for in-progress runs, do not use on finished runs or for pausing). It also suggests a preceding workflow (get_run_status or list_runs) to confirm run is active.

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?

Description adds temporary URL expiration (~30 min) and return structure beyond annotations. Annotations declare destructiveHint=true, which is consistent with generating an export file; 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?

Very concise with clear sections. Front-loaded action statement. Every sentence serves a purpose—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?

No output schema, but description covers return value (JSON fields), workflow, constraints, and usage context fully. 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?

Schema coverage is 100%, and description adds context: explains format enum (csv=human-readable, json=nested), run_slug source, filter_keys usage and listing. Adds meaning over 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 verb (export), resource (run results), and output format (CSV/JSON). Distinguishes from sibling get_run_results by contrasting file download vs in-chat preview.

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 (user wants file, large dataset), WHEN NOT TO USE (in-chat preview, logs), and workflow prerequisite (get_run_status status=3). Naming sibling tools for 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?

Description implies a read-only operation ('get account info'), but annotations set readOnlyHint=false and destructiveHint=true, indicating possible mutation. The description does not address this contradiction or explain the destructive behavior, misleading the agent.

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 purpose, usage guidelines, return format, 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 zero parameters and no output schema, the description adequately covers return fields and workflow. However, it fails to explain the destructive annotation, which is a completeness gap for a get 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?

The input schema has zero parameters, so there is no need for parameter documentation. Baseline 4 is appropriate as the description adds no redundant parameter info.

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

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

The description clearly states the verb 'get', the resource 'account info', and lists the specific fields returned (balance, traffic usage, expiration time). It distinguishes from sibling tools which focus on runs and scrapers.

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

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

Explicit WHEN TO USE and WHEN NOT TO USE sections with examples in multiple languages, and mentions alternatives like list_runs and web_search. Also provides workflow context (called before run_scraper).

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 include destructiveHint=true, but description says 'Get execution logs' implying no side effects. Does not explain what destructive behavior might occur (e.g., log consumption or state change). Missing behavioral context.

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

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

Well-structured with clear sections (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence adds value; no unnecessary text.

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

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

For a simple one-parameter tool with no output schema, the description fully explains return format, workflow placement, and usage boundaries. Complete and 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?

Schema covers 100% of parameters and description adds example value and source hint ('Obtain from run_scraper or list_runs'), enhancing usability 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?

Clearly states it gets execution logs for debugging/failure diagnosis. Distinguishes from siblings like get_run_status and get_run_results by contrasting use cases.

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 (debugging, troubleshooting) and when-not-to-use (status or results queries). Offers workflow context (call after get_run_status=4).

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

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

The description claims the tool is a read-only operation (getting result data), but annotations set destructiveHint: true, indicating potential side effects. This is a direct contradiction, making the description misleading about behavioral traits.

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

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

The description is well-structured with sections, front-loaded with purpose, and every sentence adds value. No fluff or redundancy.

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

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

The description covers return format (JSON with total, columns, records), workflow (preceded by get_run_status), and pagination guidance. Slight gap in not explaining the total count's role in pagination fully, but sufficient for a paginated list tool with sibling tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some usage context (e.g., 'page_size=20 first to check total') but no new syntactic details beyond the schema.

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

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

The description clearly states 'Get paginated result data from a completed CoreClaw scraper run' with a specific verb and resource, and distinguishes from siblings by explicitly stating when NOT to use (e.g., for metadata use get_run_status, for logs use get_run_logs).

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

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

The description includes dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections with concrete examples and explicit alternative tools (export_run_results for large datasets, get_run_status for metadata, get_run_logs for logs), and notes the workflow prerequisite of get_run_status.

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

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

The description does not disclose the destructive behavior implied by the annotation destructiveHint: true. The tool is described as a read-only status check, which contradicts the annotation. This is a serious omission and misalignment.

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 concisely structured with clear sections: purpose, when to use, when not to use, returns, and workflow. Every sentence adds value without redundancy, and the most critical 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?

Despite the lack of an output schema, the description explains the return structure (status codes, timing, result_count, cost) and provides workflow integration with sibling tools. However, it fails to address the contradictory destructive hint, leaving a gap in 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?

The input schema has 100% coverage for one parameter (run_slug). The description adds valuable context: the parameter is the run identifier, with an example and sources to obtain it (from run_scraper, run_task, etc.), going beyond the schema's basic description.

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

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

The description clearly states the tool's purpose: "Get the current execution status of a CoreClaw scraper run." It uses a specific verb and resource, and the WHEN NOT TO USE section explicitly distinguishes it from sibling tools like get_run_results, list_runs, and get_run_logs.

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 scenarios (check progress, confirm completion, polling loop) and when-not-to-use instructions with concrete alternatives. It even includes example user queries and workflow context like "Poll until status=3...".

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, implying potential side effects, but the description describes a read-only inspection tool with no mention of destructiveness. This contradiction severely undermines transparency; score is 1 per guidelines.

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 (purpose, when to use/not use, returns, workflow). Every sentence adds value, and the 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 absence of an output schema, the description fully explains what is returned (fields like version, custom_params_schema). It also outlines the prerequisite (search_scrapers) and subsequent step (run_scraper), making the tool's role complete.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description itself does not add additional meaning to the parameter beyond what the schema already provides (the workflow hint about obtaining slug from search_scrapers is in the schema, not the description).

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

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

The description clearly states the verb 'Get' and the resource 'full specification of a specific CoreClaw scraper'. It distinguishes itself from siblings like search_scrapers by noting it returns full specification, not summaries, and explicitly says when to use it versus web_search.

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

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

Provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections with concrete examples and alternatives (search_scrapers, web_search). It also specifies the tool must be called before run_scraper, forming a clear 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?

Discloses the return format with fields, user scoping ('current user's'), and pagination. However, does not address the destructiveHint annotation (true) which is surprising for a list operation; no contradiction but a gap in behavioral context.

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

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

Well-structured with sections (summary, WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Concise and front-loaded; every sentence adds value without 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?

Despite no output schema, the description includes a RETURNS section listing fields, workflow context, and usage guidance. Edge cases (empty results) not specified but overall complete for a simple list tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; it only mentions pagination and optional filters, which are already in the schema.

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

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

Clearly states the verb 'list', resource 'historical CoreClaw scraper runs', and adds scope 'current user's' and features (pagination, filters). Distinguishes from siblings like get_run_status and search_scrapers by specifying what it lists and what it does not.

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' with example user intents and 'WHEN NOT TO USE' specifying alternative tools (get_run_status for live status, search_scrapers for scrapers). Also provides a workflow hint for continuing prior work.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true. The description adds that a new run_slug is produced (not destructive to original), returns specific fields, and is for transient failures. No contradiction, and it provides useful 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 (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). It is concise, front-loaded, and 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?

For a tool with 1 parameter and no output schema, the description covers return format, workflow, prerequisites, and context about failures. It is complete and leaves no essential gap.

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

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

Schema coverage is 100% with a clear description and example for the single parameter (run_slug). The description doesn't add extra param semantics, 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 it re-runs a previous CoreClaw scraper run with identical parameters, producing a new run_slug. It distinguishes from siblings like run_scraper (for new inputs) and run_task (for brand-new 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 (re-execute, retry, repeat after failure) and WHEN NOT TO USE (inputs need to change, brand-new run). Also provides workflow: preceded by list_runs or get_run_status, followed by get_run_status/get_run_results.

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 it's asynchronous, returns a run_slug for tracking, and describes the workflow. This provides useful 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 (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence adds value 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?

Despite lacking an output schema, the description specifies return fields (run_slug, status). It explains the full workflow: prerequisite (get_scraper_details), polling (get_run_status), and retrieval (get_run_results). All 4 parameters are thoroughly documented.

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

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

The input schema has 100% coverage, and the description adds critical guidance: where to obtain values (get_scraper_details), not to invent version, and consulting the custom_params_schema. This goes well beyond the schema descriptions.

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

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

The description clearly states 'Start an asynchronous CoreClaw scraper run' with specific verb and resource. It distinguishes from siblings like rerun and run_task by explicitly mentioning alternatives in the WHEN NOT TO USE section.

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

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

The WHEN TO USE section provides explicit context (e.g., '跑一下 amazon scraper'), and the WHEN NOT TO USE lists exclusions (rerun, run_task) and prerequisite (must get_scraper_details first).

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 (creates a run) and non-idempotent. Description adds that it is a terminal call, returns run_slug and status, and suggests workflow. 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 (WHEN TO USE, WHEN NOT TO USE, RETURNS, WORKFLOW). Every sentence is information-dense and earns its place.

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

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

Given one parameter, no output schema, and annotation coverage, description fully covers purpose, usage, return format, and next steps in workflow.

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, task_slug, with schema description and example. Description adds value by distinguishing task_slug from scraper_slug and noting parameters are stored with task.

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?

Explicitly states it runs a pre-configured saved task, distinguished from similar tools like run_scraper and rerun. Verb+resource: 'run a pre-configured saved task' is specific and 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?

Provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections with examples and specific alternatives (run_scraper, rerun). Clear context for tool selection.

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

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

Description describes a read-only search operation, but annotations have destructiveHint: true and readOnlyHint: false, contradicting the description. This is a serious inconsistency that undermines transparency.

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

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

The description is well-structured with sections and front-loaded purpose, but is slightly verbose with repeated examples. Could be trimmed without losing value.

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

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

Given the tool is simple with few parameters and no output schema, the description fully covers the return format (JSON array with slug, title, description, tags) and workflow (first step in scraping pipeline). 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?

Schema covers both parameters with descriptions, but the description adds value beyond schema: it explains the empty string for listing all scrapers and provides examples. Schema coverage is 100%, so baseline is 3; the added context merits a 4.

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

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

The description clearly states the tool searches a specific marketplace (CoreClaw) for scrapers by keyword, with explicit verb 'Search' and resource 'scraper marketplace'. It distinguishes from siblings like web_search and get_scraper_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?

Includes explicit WHEN TO USE and WHEN NOT TO USE sections, with examples, alternative tools, and triggers. Provides clear guidance on when to use this tool vs siblings.

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