Skip to main content
Glama
Sign In
webEmbedding

webEmbedding

by jongko54
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

cancel_clone_job

Cancel a queued or retry-wait website clone job by moving it to cancelled in the filesystem queue and optionally recording a reason.

Instructions

Move a queued or retry-wait clone job to cancelled.

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": {
      "queue_root": "<queue_root>",
      "job_id": "<job_id>"
    },
    "name": "cancel_clone_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYesJob id returned by enqueue_clone_job.
reasonNoOptional note recorded on the cancelled job.
queue_rootYesDirectory holding the filesystem job queue; created if missing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.13
    • addedInput schema / properties / job_id / description
      Added value: +"Job id returned by enqueue_clone_job."
    • addedInput schema / properties / queue_root / description
      Added value: +"Directory holding the filesystem job queue; created if missing."
    • addedInput schema / properties / reason / description
      Added value: +"Optional note recorded on the cancelled job."
  2. First observedv0.3.12

TDQS

A3.8/5.0
Behavior3/5

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

The annotations already establish a non-read-only, non-idempotent, non-destructive operation, and the description adds the precise state transition and eligible source states. It does not explain behavior for running, terminal, or already-cancelled jobs, including whether ineligible requests fail or have no effect.

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?

A single front-loaded sentence communicates the operation, resource, eligible states, and resulting state without filler. Its brevity does not obscure the core purpose.

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?

For a simple three-parameter cancellation tool, the state-transition description, complete schema, and consistent annotations provide nearly enough information to select and invoke it correctly. The main remaining gap is failure or no-op behavior for jobs outside the two named states, especially with no output schema to clarify results.

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%, and the schema already documents the job ID source, optional cancellation note, and queue directory behavior. The description adds no parameter-specific meaning beyond those structured fields, so the baseline score applies.

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

Purpose4/5

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

The description gives a specific action and resource: moving a clone job to "cancelled." It further narrows the operation to queued or retry-wait jobs, but does not explicitly contrast the tool with siblings such as run_clone_job or load_clone_job.

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 eligible job states provide clear when-to-use context: cancel a job while it is queued or waiting to retry. There is no explicit when-not guidance or routing to list_clone_jobs or load_clone_job for discovering and verifying jobs.

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