webEmbedding

Overview Schema Source Related Servers Discussions Admin

enqueue_clone_job

Queue a source-first website clone job in a filesystem-backed async queue for later worker execution, with configurable retries and job metadata.

Instructions

Persist a source-first clone job into a filesystem-backed async queue for later worker execution.

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>",
      "url": "<url>"
    },
    "name": "enqueue_clone_job"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Public http(s) URL to clone when the job runs.
`metadata`	No	Free-form JSON stored with the job, e.g. a ticket id.
`clone_args`	No	Additional clone_reference_url arguments stored with the job (same names as that tool, e.g. wait_seconds, breakpoint_profiles).
`output_dir`	No	Directory the job writes its clone and reports into.
`queue_root`	Yes	Directory holding the filesystem job queue; created if missing.
`max_attempts`	No	Maximum run attempts before the job is marked failed (1-10, default 2).
`retry_delay_seconds`	No	Seconds to wait before retrying a failed attempt (default 30).

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.3.13Nov 9, 2026

addedInput schema / properties / clone_args / description

Added value: +"Additional clone_reference_url arguments stored with the job (same names as that tool, e.g. wait_seconds, breakpoint_profiles)."

addedInput schema / properties / max_attempts / description

Added value: +"Maximum run attempts before the job is marked failed (1-10, default 2)."

addedInput schema / properties / metadata / description

Added value: +"Free-form JSON stored with the job, e.g. a ticket id."

addedInput schema / properties / output_dir / description

Added value: +"Directory the job writes its clone and reports into."

addedInput schema / properties / queue_root / description

Added value: +"Directory holding the filesystem job queue; created if missing."

addedInput schema / properties / retry_delay_seconds / description

Added value: +"Seconds to wait before retrying a failed attempt (default 30)."

addedInput schema / properties / url / description

Added value: +"Public http(s) URL to clone when the job runs."

First observedv0.3.12Nov 2, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds real value by disclosing the persistence target and that work is deferred to a worker, but it does not address duplicate-submission behavior (relevant given idempotentHint=false) or what identifier a caller gets back to track the job later.

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?

One front-loaded sentence with the verb first and no filler. It is appropriately sized for a queue-write operation, though a short clause on the tracking handle would have earned the fifth point.

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

Completeness3/5

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

For a mutating, non-idempotent enqueue with nested object parameters and no output schema, the description covers what the tool does and where it writes. It leaves open the two things a caller most needs to know: whether resubmitting the same URL creates a duplicate job, and how to reference the job afterwards (job id vs. filesystem path).

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

Parameters4/5

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

Schema description coverage is 100%, so the seven parameters, their bounds, and defaults are already fully documented in the schema; the description correctly avoids restating them. Baseline credit applies since the schema carries the semantic load.

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 verb-and-resource pair ("Persist a source-first clone job") and adds the mechanism ("filesystem-backed async queue for later worker execution"), which separates it from the synchronous clone_reference_url and from run_clone_job. It never names a sibling explicitly, so an agent must infer the boundary from the wording rather than being told.

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

Usage Guidelines3/5

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

"for later worker execution" implies the deferred/async case, which is useful context for choosing it over an immediate clone. However, there is no explicit when-to-use statement, no mention of the related list_clone_jobs / run_clone_job siblings, and no guidance on when a queued job is preferable to a direct call.

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