ThriftyRelay

Overview Schema Source Related Servers Discussions Admin

Run Remote Task

remote_task

Destructive

Run ordered file, command, and coding steps on the user's PC in one call, batching related work to reduce tool cards and return results for review.

Instructions

Run work on the user's PC. Steps run in order in one call; batch related work to keep tool cards few. Do direct work yourself: read or search to look at files, edit, write, or patch for focused changes, run for commands, code for several reads at once, and call for any other Desktop Commander tool. Use one codex step for investigation or changes across several files. It needs execution=async; then call remote_inspect with only its task_id to wait for the answer, review, and usage. A step cannot see an earlier step's result in the same call. When a file's content decides the next step, read it in one call and act in the next. execution=sync waits for the steps; execution=async returns a task ID. Use async for codex and for commands that may run longer than about a minute. When an administrator has registered an admission policy, run, call, and code steps, and paths outside the workspace or marked sensitive, need the user's approval: remote_task answers APPROVAL_REQUIRED with a task_id, then call open_approval and wait with remote_inspect. Each field's description covers the rest, including quota approval and request_id reuse. For relevant tasks, use the Codex Skills catalog from MCP instructions and read only selected SKILL.md files. If the catalog is not visible, use a run step with: node /app/src/skills/catalog.mjs; discover once per relevant task, not for unrelated chat.

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": {
      "steps": "<steps>"
    },
    "name": "remote_task"
  }
}

Input Schema

Name	Required	Description	Default
`steps`	Yes
`scratch`	No	Create a per-task temporary directory under the configured work area. Relative paths and the {{scratch}} token resolve there; absolute paths still pass admission. This does not change run/call/code or Codex permissions, and Codex steps reject it: name an absolute cwd instead.
`execution`	No		sync
`stop_on_error`	No
`task_timeout_ms`	No
`max_exposed_chars`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, it discloses important execution semantics: steps run in order, a step cannot see an earlier step's result in the same call, sync waits while async returns a task ID, and async is required for codex and long-running commands. It also explains the approval flow and quota/request_id handling, all consistent with the destructive/openWorld annotations.

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?

The description is front-loaded with the core purpose and then covers the main usage branches, which is appropriate for a complex orchestrator. It is dense and has some run-on phrasing, and the sentence deferring to field descriptions is not especially useful, but most content earns its place.

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 complex multi-step tool with annotations but no output schema, the description covers selection, step design, async behavior, approvals, and codex usage well. The main remaining gap is that it does not describe the sync return shape or how step results are presented.

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?

The description adds meaning for execution and for step-ordering behavior, including the codex requirement for execution=async. However, with low top-level schema description coverage, it leaves several parameters such as stop_on_error, task_timeout_ms, and max_exposed_chars unexplained beyond their names.

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?

The description states a specific operation: running ordered work on the user's PC in one call, and enumerates the supported step kinds. It also distinguishes this orchestrator from remote_inspect and open_approval by naming when to call them.

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?

It gives explicit routing guidance: use read/search for inspection, edit/write/patch for focused changes, run for commands, code for several reads, and call for other Desktop Commander tools. It also states when to use a codex step, when to choose sync versus async, and what to do on APPROVAL_REQUIRED.

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

Deploy Server