Skip to main content
Glama

Delegate task to OpenCode agent

delegate_task

Delegate software-engineering tasks to an OpenCode agent that explores the repository, returns a summary and structured findings, and can edit files and run tests when permitted.

Instructions

Delegate a software-engineering task to an OpenCode agent (DeepSeek by default) that runs in the same workspace. The agent explores the repository itself and returns a concise summary plus structured findings. Read-only agents (deepseek-researcher, deepseek-reviewer) cannot modify files; deepseek-coder can edit and run tests. Set allow_edits=false to force edit tools off for this call. Returns { status, session_id, summary, findings, files_changed }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory. Defaults to CLAUDE_PROJECT_DIR / the server working directory.
taskYesThe task to delegate, written as a clear instruction.
agentNoAgent to use (default: deepseek-researcher). See list_agents.
modelNoOverride the model, e.g. "deepseek/deepseek-v4-pro".
pathsNoStarting path hints relative to the workspace. Hints only, not a restriction.
timeoutNoExecution timeout in milliseconds (default from bridge config).
allow_editsNoWhen false, edit/write tools are disabled for this call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only include openWorldHint, so the description carries the burden. It discloses that read-only agents cannot modify files, coder agents can edit and run tests, and that allow_edits=false disables edit tools. It also states the return object shape. This adds meaningful behavioral context beyond the minimal annotation, though it doesn't mention potential side effects like long execution times or concurrency limits.

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 a few dense sentences, front-loaded with the core purpose, then agent capabilities, then return format. There is no fluff; each sentence adds useful information. It could be slightly more structured with separators, but it is concise and effective.

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?

With 7 parameters and no output schema, the description compensates well by listing the return fields (status, session_id, summary, findings, files_changed) and explaining agent behavior. It does not cover error handling or timeout specifics, but the essential information for calling the tool correctly is present. Minor gaps remain but are not critical.

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. The description adds value by clarifying agent capabilities (deepseek-researcher/reviewer vs coder) and the effect of allow_edits, which goes beyond the schema's generic descriptions. It also reiterates the 'hints only' nature of paths, reinforcing schema content. This exceeds the baseline.

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 verb ('Delegate'), a specific resource (OpenCode agent in the same workspace), and the outcome (returns a summary plus structured findings). It clearly distinguishes this from the sibling session-management tools like create_session or send_message by framing it as a task delegation that includes agent exploration and structured findings.

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?

The description explains when to use different agents (read-only vs coder) and how to force edit tools off via allow_edits=false, which is useful. However, it does not explicitly contrast this tool with siblings such as create_session or send_message, so an agent might not know when to choose delegation over direct session operations. Usage context is implied but not fully explicit.

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