Stop a running or pending documentation crawl by job ID without modifying stored corpus or history. No effect on jobs already finished.
Cancel a running or pending crawl job by job ID. The previously stored corpus and crawl history are left untouched. Has no effect on jobs already in a terminal state.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID returned by crawl_site |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=false, idempotentHint=true), the description adds useful behavioral facts: the stored corpus and crawl history are left untouched, and terminal-state jobs are unaffected. This reassures the agent about side effects, though it doesn't cover the return value or confirming state after cancellation.
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?
Three short sentences, front-loaded with the core action, each contributing a distinct fact (action, preserved data, terminal-state no-op). 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 one-parameter cancel operation with annotations covering the safety profile and no output schema to explain, the description is nearly complete. Missing only post-cancellation state/return detail, which is minor.
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 the single job_id is fully documented there (including its origin from crawl_site). The description's 'by job ID' adds nothing 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?
States a specific verb ('Cancel') and resource ('crawl job') plus the qualifying scope ('running or pending'). An agent can immediately distinguish it from siblings like get_job_status or crawl_site.
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?
Clearly states the applicable states (running or pending) and explicitly rules out terminal-state jobs, which is real when-to-use guidance. It does not name an alternative tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.