MeshArc

Cancel a running job

cancel_job

DestructiveIdempotent

Stop a crawl, run or batch that is still going. Use it when the work should not finish: a crawl started too wide, a run blocking the next start_run (which answers 409 meanwhile), a batch of the wrong URLs. To check a job without stopping it use get_job. Inputs: kind and id come from the 'job' object, or a crawl_site crawl_id with kind='crawl'. A run also needs project_id; list_runs shows which run is still going. Effect: queued work is dropped and the page in hand finishes. Pages already read stay. A stop cannot be undone; run the work again to resume. A finished job is left alone, so asking twice is harmless. Needs write access; a read-only connection is refused with code 'read_only'.

Input Schema

Name	Required	Description
`id`	Yes	The job's id.
`kind`	Yes	'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs).
`project_id`	No	A run's project id; required for a run, ignored otherwise.

Output Schema

Name	Required	Description
`id`	No	The job's id.
`code`	No	Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.
`kind`	No	crawl, run or batch.
`note`	No	What a stop keeps and drops.
`error`	No	Only when the call failed: what went wrong, in words an assistant can act on.
`detail`	No	Only on a failure: the API's own wording, when the error was rephrased.
`status`	No	Only on a failure: the HTTP status code.
`outcome`	No	'cancelled' (it had not started), 'cancelling' (it stops after the page in hand), or the status of a job that had already ended.
`project_id`	No	A run: its project.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 7, 2026

changedInput schema / properties / id / description

Previous value: -"The job's id, from that 'job' object, or a crawl_site answer's crawl_id."New value: +"The job's id."

changedInput schema / properties / kind / description

Previous value: -"What the job is: 'crawl' (crawl_site), 'run' (start_run, recrawl_pages) or 'batch' (scrape_urls); the 'job' object a tool returned names it."New value: +"'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs)."

changedInput schema / properties / project_id / description

Previous value: -"Required for a run: the project it belongs to (the 'job' object carries it). Ignored for a crawl or a batch."New value: +"A run's project id; required for a run, ignored otherwise."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "What a cancel did.",
+  "properties": {
+    "code": {
+      "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.",
+      "title": "Code"
+    },
+    "detail": {
+      "description": "Only on a failure: the API's own wording, when the error was rephrased.",
+      "title": "Detail"
+    },
+    "error": {
+      "description": "Only when the call failed: what went wrong, in words an assistant can act on.",
+      "title": "Error"
+    },
+    "id": {
+      "description": "The job's id.",
+      "title": "Id"
+    },
+    "kind": {
+      "description": "crawl, run or batch.",
+      "title": "Kind"
+    },
+    "note": {
+      "description": "What a stop keeps and drops.",
+      "title": "Note"
+    },
+    "outcome": {
+      "description": "'cancelled' (it had not started), 'cancelling' (it stops after the page in hand), or the status of a job that had already ended.",
+      "title": "Outcome"
+    },
+    "project_id": {
+      "description": "A run: its project.",
+      "title": "Project Id"
+    },
+    "status": {
+      "description": "Only on a failure: the HTTP status code.",
+      "title": "Status"
+    }
+  },
+  "title": "CancelOut",
+  "type": "object"
+}

AddedOct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well past the annotations: it explains what actually happens (queued work dropped, in-flight page completes, already-read pages retained), that the stop is irreversible, that re-asking on a finished job is harmless, and that write access is required with a specific 'read_only' refusal code. The annotations declare destructive/idempotent, but the description supplies the operational detail an agent needs.

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?

Well front-loaded – purpose, usage, inputs, effect, permissions in that order – and each sentence carries distinct information. It is longer than typical, though the density is justified for a destructive, idempotent operation.

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?

Given an output schema exists, the description need not cover return values, and it fills all remaining gaps: inputs sourcing, side effects, reversibility, idempotency behavior, and authorization requirements. Nothing an agent needs to invoke this correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds sourcing meaning the schema lacks: kind and id come from the 'job' object, a crawl_site crawl_id maps to kind='crawl', and project_id is required only for runs, with list_runs pointed to as the way to find an active run.

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 and resource set ('Stop a crawl, run or batch that is still going'), naming the three job kinds it governs. It also explicitly distinguishes itself from the read-only alternative get_job, so an agent can separate the two without inspecting schemas.

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 concrete triggering scenarios (crawl started too wide, run blocking a start_run that returns 409, wrong-URL batch) and an explicit exclusion with the alternative to use instead ('To check a job without stopping it use get_job'). When-to-use and when-not are both covered.

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

All MeshArc tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.