Skip to main content
Glama
Sign In
scrapy-mcp

scrapy-mcp

by eitan3
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cancel_crawl

Stop an active crawl immediately while preserving any results already collected. Cancel a running Scrapy job by its job ID to halt further scraping without losing progress.

Instructions

Stop a running crawl by killing its worker process. Results so far are kept.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>"
    },
    "name": "cancel_crawl"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the destructive act of killing the worker process and the side effect that results are kept. This goes beyond a vague 'cancel' and gives the agent meaningful expectations about consequences.

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

Conciseness5/5

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

Two short sentences, front-loaded with the core action and immediately followed by the most important side effect. No filler or redundancy.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the key aspects: what it stops, how it stops it, and what persists. It doesn't mention whether cancellation is reversible or what is returned, but those are not critical for this simple operation.

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

Parameters3/5

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

The schema has one required parameter (job_id) but zero description coverage. The description does not explicitly define job_id, though the tool name and context make it inferable as the crawl's ID. It would benefit from stating 'the ID of the crawl to cancel' or referencing start_crawl.

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

Purpose5/5

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

The description clearly states the action (stop a running crawl), the mechanism (killing its worker process), and the outcome (results kept). This is a specific verb+resource+scope statement that distinguishes cancel_crawl from siblings like start_crawl and crawl_status.

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

Usage Guidelines4/5

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

The description implies the use case: when a crawl is running and must be stopped. It does not explicitly contrast with alternatives, but the purpose is so singular that the context is clear. It would benefit from mentioning 'use crawl_status to check if a crawl is running', but the baseline is solid.

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

Deploy Server

Other Tools