Skip to main content
Glama
Sign In

RunHarvester

by com.runharvester
OverviewDiscussionsAdmin

Cancel an owned active request or active structured-extraction run

data_cancel_request
Destructive

Cancels a pending, running, or CAPTCHA-solving page request. If the page is already completed, the endpoint can still cancel active dependent AI extraction runs without deleting the retained page result. Pending page cancellations attempt an immediate base-debit refund; running page cancellations are left for the existing refund-recovery flow. Requires scope 'scrape:write'. Returns {ok,status,data,meta}; API failures return {ok:false,status,error}.

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": {
      "id": "<id>"
    },
    "name": "data_cancel_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesUUID of the target request or batch, as returned in the id field when it was created or listed.
idempotency_keyNoOptional. Generate a unique value before a write and retain it for an exact-body retry; replay is free and a different body returns 409 IDEMPOTENCY_CONFLICT.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / id / description
      Added value: +"UUID of the target request or batch, as returned in the id field when it was created or listed."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true / idempotentHint=false annotations by disclosing the refund model (immediate base-debit refund for pending vs. refund-recovery flow for running), that retained page results are not deleted, and the required 'scrape:write' scope. It also gives both success and failure return shapes, which is valuable given no output schema exists.

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

Conciseness4/5

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

Front-loads the core action, then layers state-specific behavior, auth, and return shape in four tight sentences with no filler. Density is high but each sentence carries distinct operational information; only the return-shape clause is arguably boilerplate across the API.

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

Completeness5/5

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

For a destructive mutation with no output schema, the description covers the state-dependent outcomes, the non-destructive side effect (results retained), the permission requirement, and the response envelope. An agent has everything needed to decide to call it and to interpret the outcome.

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?

Schema description coverage is 100%, with both id and idempotency_key documented in-schema including UUID format and replay/409 semantics, so the baseline is 3. The description adds no parameter-level meaning beyond noting the target can be a request or batch via state behavior, so it neither compensates for nor exceeds the schema.

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?

States a specific verb (cancels) and precise resource scope: pending, running, or CAPTCHA-solving page requests, plus dependent AI extraction runs for already-completed pages. This is clearly distinguishable from sibling reads (data_get_request) and data_retry_request without opening any schema.

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?

Gives concrete when-to-use context by state (pending, running, CAPTCHA-solving, already-completed with dependent extraction runs), which is exactly the branching an agent needs. It stops short of naming alternatives such as data_retry_request for restarting rather than cancelling, so it is clear context but not a full when/when-not map.

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

All RunHarvester toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources