Prosp

Cancel discovery

cancel_discovery

DestructiveIdempotent

Cancel a running discovery job by its jobId, freeing its slot so a new find_prospects can start. Credits are refunded ONLY when the run had delivered zero prospects at cancel time; if prospects were already delivered you keep them and are not refunded (they stay retrievable via get_discovery_results). Only the job's owner may cancel; cancelling an already-finished job is a harmless no-op that returns its current state.

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_discovery"
  }
}

Input Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: the precise credit-refund rule, the fact that delivered prospects survive cancellation and remain retrievable, the owner-only authorization requirement, and the no-op semantics on completed jobs. These are exactly the consequences an agent needs before invoking a destructive tool.

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?

The action and its slot-freeing consequence are front-loaded, followed by refund policy, authorization, and idempotency in descending order of importance. No filler sentences; each clause carries distinct operational information.

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?

With an output schema present, return values need not be explained, and the description covers the risky aspects (cost, ownership, irreversibility limits, no-op behavior) thoroughly. The only meaningful omission is guidance on where a valid job_id comes from.

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 coverage is 0% for the single required job_id, so the description carries the full burden of explaining it. It only restates "by its jobId" without giving the identifier's source (e.g. from find_prospects or get_discovery_status) or any format expectation, leaving the agent to infer how to obtain a valid value.

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?

Opens with a specific verb+resource+identifier: "Cancel a running discovery job by its jobId", then states the downstream effect (freeing a slot so a new find_prospects can start). It is clearly distinguishable from adjacent read-only siblings like get_discovery_status and get_discovery_results.

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

Usage Guidelines5/5

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

Gives explicit conditions for use (freeing a slot to start another find_prospects), states the side-effect policy that governs whether to bother (refund only if zero prospects delivered), and routes the agent to get_discovery_results for prospects already delivered. It also pre-empts a common misuse case by declaring that cancelling a finished job is a harmless no-op.

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

All Prosp tools Inspect

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

Need Help?