Skip to main content
Glama
Sign In
ClawdCursor

ClawdCursor

by AmrDab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

task

Destructive

Submit a whole natural-language desktop instruction to ClawdCursor's internal agent, then wait within a timeout and poll, abort, or resume it when paused.

Instructions

Deprecated (removed in 1.6): drive the other tools from your own agent instead. Requires the clawdcursor agent daemon to be running (binds 127.0.0.1:3847 with an LLM configured). Hand clawdcursor a WHOLE natural-language task and let its internal agent loop execute it (accessibility first, screenshots when the screen has no readable structure). BOUNDED-SYNC: waits up to timeout seconds (default 45) — a longer task returns {status:"running"} with progress while it CONTINUES in the background; re-call with the SAME instruction to keep waiting (re-attaches, never restarts), {action:"status"} to poll, {action:"abort"} to stop it. At a roadblock (sign-in, 2FA, CAPTCHA, a step it may not take) the task PAUSES for the user and returns {status:"paused", waitingFor}: keep re-calling to wait, never restart; {action:"resume"} if the user tells you they finished. If the daemon isn't running you get a clear error telling you how to start it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "task"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionNoDefault "run" (submit/continue the instruction). "status" → poll the running task (cheap, poll at 1–2 Hz). "abort" → stop the running task. "resume" → continue a task paused for the user, when they tell you they finished. Required: run: instruction.
timeoutNoMax seconds to WAIT for completion before returning a running receipt (default 45, clamped 1–50). The task keeps running — this only bounds the wait.
instructionNoNatural-language task description, e.g. "open Notepad and type hello", "go to github.com", "send email in Outlook". Required for action "run" (the default); ignored for status/abort.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.24
    • changedInput schema / properties / action / description
      Previous value: -"Default \"run\" (submit/continue the instruction). \"status\" → poll the running task (cheap, poll at 1–2 Hz). \"abort\" → stop the running task. \"resume\" → continue a task paused for the user, when they tell you they finished."New value: +"Default \"run\" (submit/continue the instruction). \"status\" → poll the running task (cheap, poll at 1–2 Hz). \"abort\" → stop the running task. \"resume\" → continue a task paused for the user, when they tell you they finished. Required: run: instruction."
  2. First observedv1.5.16

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag non-readonly, destructive and openWorld, but the description adds behavior those annotations cannot express: the daemon prerequisite and its bind address, bounded-sync waiting capped at `timeout` with background continuation, the pause-on-roadblock contract (sign-in, 2FA, CAPTCHA), and the concrete error when the daemon is down. This is exactly the kind of operational context the annotations leave out.

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?

Long but dense and front-loaded: deprecation, then daemon prerequisite, then the core behavior, then the resumption/pause protocol. There is mild redundancy in repeating the 'keep re-calling to wait, never restart' instruction in both the timeout and pause passages, but no sentence is filler.

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 3-parameter tool with no output schema, the description supplies the missing return contract inline ({status:"running"} with progress, {status:"paused", waitingFor}) and the error path when the daemon is absent. An agent has everything it needs to call this correctly, including how to recover from a long-running or paused state.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by defining the re-attach semantics — re-calling with the same instruction continues waiting and 'never restarts' — and by mapping the paused/waitingFor state onto the `resume` action. The timeout and action values themselves are already fully documented in the schema, so this is an increment rather than a rewrite.

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 and scope: 'Hand clawdcursor a WHOLE natural-language task and let its internal agent loop execute it', plus how it executes (accessibility first, screenshots as fallback). This clearly distinguishes it from the sibling tools (accessibility, browser, computer, window) which are single-capability primitives, and the deprecation notice at the front tells the agent it is the orchestrator, not the executor.

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?

Explicit when-to-use and when-not-to-use: deprecated in favour of driving the other tools from your own agent, requires the `clawdcursor agent` daemon, and select a different action (status/abort/resume) per situation. It also names the exact continuation protocol (re-call with the SAME instruction, never restart) and the user-driven case for `resume`.

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