cancel_taskCancel a queued task by task_id. Side effects: changes task state. Xcatcher refunds cost_points when a queued task is successfully cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID to cancel. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses specific side effects: 'changes task state' and 'refunds cost_points' on success. This adds meaningful context about the mutation and its financial implication, though it does not detail failure states or state transitions.
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 exceptionally concise: two sentences that front-load the action and then provide essential side-effect information. Every word adds value, and there is no redundancy or unnecessary detail.
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 mutation tool, the description covers the core purpose, scope (queued), side effects, and financial outcome. The presence of an output schema means return values need not be explained. It could optionally mention failure behavior for non-queued tasks, but the current information is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage of the single parameter (task_id) with its own description. The tool description only repeats this as 'by task_id', adding no additional meaning beyond the schema. Baseline 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel a queued task'), the resource ('task'), and the method ('by task_id'). It also adds side effects, which fully defines the tool's purpose and distinguishes it from sibling tools like get_task_status or create_crawl_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly limits usage to 'queued task', providing a clear context and exclusion of non-queued tasks. It also mentions the refund condition, which implies success only for queued tasks. However, it does not explicitly name alternatives or state when not to use it, though no other sibling tool offers cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct purpose, with explicit guidance for when to use accountless vs API-key variants. Even closely related tools like get_task_status and wait_for_task are differentiated by their polling behavior, so an agent can reliably select the correct one.
Most tools follow a consistent verb_noun pattern in snake_case (create_crawl_task, get_task_status, list_crawl_tasks). The one exception is x402_topup, which places the protocol prefix before the verb, breaking the pattern slightly but still remaining readable.
With 17 tools, the count is slightly above the typical 3-15 range, but the service supports two distinct payment paths (API-key and accountless x402), each requiring a parallel set of status/result tools. The count feels justified by the scope, with no obvious bloat.
The tool set covers the full lifecycle of creating, monitoring, retrieving, and managing crawl tasks, including both payment flows. It includes task creation, status polling, result preview/download, cancellation, listing, balance checks, and payment top-ups, leaving no critical gaps for the stated purpose.