Skip to main content
Glama

delegate

Hands coding tasks to another AI agent that reads the project and writes code in its own loop, keeping your context clean. Use it for tests, refactors, error fixes, and boilerplate.

Instructions

Hand a coding task to another AI model running as a full agent via local opencode: it reads the project, explores, and writes the code in its own tool loop, none of which enters your context. Use it instead of writing the code yourself for: tests for code that already exists; a mechanical refactor (rename, signature change, import rewrite, API migration); lint/type/build errors (paste the error output); boilerplate or scaffolding (CRUD endpoints, config, schemas, adapters, fixtures); a port between languages or frameworks; the same edit repeated across 3 or more files; reading a large file or directory to answer one narrow question; the survey half of an audit. Runs inline by default and returns when done; Claude Code backgrounds calls past 2 minutes, other hosts wait. Pass background:true to get a job id at once, then poll check_delegation. Pass continue_session (returned by a previous delegation) to keep the same agent session instead of re-exploring. Name file paths in task; never paste their contents. model/directory/agent/autoApprove default from config — omit them. Review what comes back before reporting it done.

Input Schema

NameRequiredDescriptionDefault
taskYesSelf-contained instructions: the goal, the file paths to read or change, constraints, and how to check the result (e.g. which tests to run). The agent has not seen this conversation
agentNoopencode agent to use (defaults to config defaultAgent)
filesNoPaths to attach to the agent's prompt (inline only; ignored with background:true). Rarely needed: the agent reads paths named in task itself
modelNoprovider/model, e.g. opencode/deepseek-v4.1-flash-free. Omit to use the configured default; don't raise it to a premium tier — split the task instead
profileNoNamed preset from config profiles (see get_delegate_config) that sets model, agent, variant, directory and autoApprove together
directoryNoAbsolute path of the project to work in (defaults to config defaultDirectory, else the server's working directory)
backgroundNoRun detached and return a job id immediately; poll check_delegation (default false)
autoApproveNoLet the agent edit files and run commands without asking (defaults to config autoApprove, true). When false nobody is there to approve, so actions that need approval can stall or be refused
continue_sessionNoSession id from a previous delegation's result, to continue in that agent session

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

A4.5/5.0
Behavior3/5

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

No annotations, so the description carries the full burden and does well on several fronts: context isolation, inline-vs-background execution, the 2-minute host-specific timeout, and job-id polling. It is weaker on the mutation side — it never says the agent will edit files in the working tree or that those edits are not reversible, and the approval risk is only implied by 'Review what comes back before reporting it done'.

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?

Front-loaded with the core purpose, then trigger conditions, then runtime behavior, then invocation tips. Despite its length, every clause is a distinct decision input — no restatement of the name or filler prose.

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 9-parameter, no-output-schema delegation tool this is thorough: it covers what the remote agent does with your repo, how the call returns (inline vs job id), how to resume a session, and which params to leave alone. Nothing needed to invoke it correctly is missing.

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 real operational guidance: 'Name file paths in task; never paste their contents', 'model/directory/agent/autoApprove default from config — omit them', and that continue_session came from a previous delegation's result. It supplies decision rules the schema alone does not.

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 resource ('Hand a coding task to another AI model running as a full agent') and immediately characterizes the mechanism ('reads the project, explores, and writes the code in its own tool loop, none of which enters your context'). This distinguishes it cleanly from ask_model and from doing the work in-context.

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?

Enumerates eight concrete trigger conditions ('tests for code that already exists', 'mechanical refactor', 'lint/type/build errors', 'same edit repeated across 3 or more files'), and explicitly says to use it 'instead of writing the code yourself'. It also routes to siblings: poll check_delegation for background jobs, use continue_session rather than re-exploring, and omit config-defaulted params.

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