Skip to main content
Glama

delegate

Send code-change tasks to a cost-effective worker that edits an isolated worktree, runs checks, and returns verified uncommitted changes for review.

Instructions

Make any code change: use this for every edit, including small, mechanical, "quick" or multi-file ones; those are exactly what the cheap worker is for, and your tokens cost the user far more than its. One call: task = what to change, which files, how to check. The worker edits an isolated worktree, runs the checks, and lands an OK result (uncommitted) in your working tree; read the result block instead of re-checking. Pass difficulty, rated from the issue as the time an engineer new to the code needs to fix and test it: easy < 15 min, medium < 1 h, hard > 1 h. For multi-step work pass plan + steps instead of task. Plan format: one "# " line, then per step a "## " heading followed by "files: ", "do: ", "done-when: " (optional "dont:", "needs: ", "difficulty: easy|medium|hard"), each key at the start of its line, not a bullet. In done-when, backticked text is run as a shell command that must succeed; put only commands in backticks.

Input Schema

NameRequiredDescriptionDefault
noteNoExtra guidance for this run, at most 300 characters
planNoInstead of task: plan file path, relative to the repository root
taskNoThe change in plain words: what to change, which files, how to check. One step, no plan file needed
waitNoDefault true: return when every group settles or one is BLOCKED. false: return RUNNING at once; then jobs(action="wait")
briefNoA research result to start from: its id (e.g. r5k2q) or its text. The worker gets it instead of re-exploring
filesNoWith task: files or directories it touches, comma-separated (default: the whole repo)
stepsNoWith plan: "3" one step, "3-5" a range in one job, "1-2,3,4" comma-separated groups, each its own job, run in parallel unless files overlap or needs: orders them
sourceNoThe user's request or the issue text, verbatim, or the repo-relative path of a file holding it. The worker checks the task against it and reports where they disagree
done_whenNoWith task: how to check it; `backticked` shell commands must succeed (default: the repo's tests)
difficultyNoTime an engineer new to the code needs: easy < 15 min, medium < 1 h, hard > 1 h. Picks the worker model; a plan step's difficulty: wins

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden: it discloses the isolated-worktree execution model, that checks are run, that the result lands uncommitted in the caller's tree, that the agent should read the result block instead of re-checking, and the BLOCKED/RUNNING settling behavior. That covers exactly the traits an agent needs before invoking a mutating tool.

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?

No filler sentences and the most important rule is first, but it is packed into long semicolon-chained sentences, and the dense inline plan-format spec is harder to scan than a short bulleted block would be.

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 10-parameter mutating tool with no annotations and no output schema, the description covers execution model, return semantics ('result block'), and the full plan/steps protocol. It stops short of describing what a landed result or a BLOCKED group actually looks like, and says nothing about permission or conflict handling.

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 3 baseline is already met; the description goes further by specifying the plan file format (heading, files/do/done-when keys, needs:, dont:), the difficulty bucketing, the steps grouping grammar ('3-5', '1-2,3'), and that backticked done-when text is executed as a shell command. Minor deduction for not clarifying note/brief/source interaction with each other.

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: 'Make any code change' and explicitly extends it to small, mechanical, and multi-file edits, which implicitly separates it from research/land siblings. An agent can tell this is the general edit-delegation tool without opening the schema.

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 an explicit rule ('use this for every edit') plus the rationale (cheap worker vs. expensive orchestrator tokens), and names the branching condition: use plan + steps instead of task for multi-step work. It also names jobs(action="wait") as the follow-up when wait=false.

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