Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@opencode-delegate-mcp Add JSDoc to every exported function in src/utils/*.ts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let your primary coding agent (Claude Code, Codex) delegate the grunt work to a cheaper model via OpenCode.
Keep architecture, critical logic, and hard decisions on your expensive frontier model — and hand off the high-volume, low-risk work (boilerplate, repetitive edits, tests, lint/type fixes, mechanical refactors) to a cheap model like MiniMax running through OpenCode. It's an agent talking to another agent: your main agent uses a second agent as a subagent, with the model/provider configurable at runtime.
┌────────────────────┐ MCP (stdio) ┌───────────────────────┐ opencode run ┌──────────────────┐
│ Claude Code / │ ──────────────► │ opencode-delegate-mcp │ ───────────────► │ OpenCode + │
│ Codex (primary) │ delegate_task │ (this server) │ --model cheap │ cheap model │
└────────────────────┘ ◄────────────── └───────────────────────┘ ◄─────────────── └──────────────────┘
result: text + session + token usage + actions takenThe problem: frontier models (Claude, GPT-class) are your best tool for architecture, hard bugs, and judgment calls — and expensive overkill for the mechanical majority of real coding work: boilerplate, tests, lint/type fixes, repetitive multi-file edits. Doing all of it with your primary agent burns premium tokens and fills its context with busywork instead of the decisions that actually need it.
What this tool does: it gives your primary agent a tool to hand that busywork to a cheaper model — or a free one — running through OpenCode, without leaving your workflow. The primary agent stays focused on what matters; the cheap model grinds through the repetitive stuff and reports back. Which model does the work is a config change, not a redeploy — switch it any time.
Related MCP server: Relay
The easiest path is the web configurator, which builds a one-line install command for you:
👉 https://mryesiller.github.io/opencode-delegate-mcp/
Or install directly from the terminal — one command, one paste, done:
curl -fsSL https://mryesiller.github.io/opencode-delegate-mcp/install.sh | bash -s -- --model "minimax-coding-plan/MiniMax-M2.5-highspeed" --targets "claude,codex"Prefer to inspect the script before running it? Download first, then run it locally:
curl -fsSL https://mryesiller.github.io/opencode-delegate-mcp/install.sh -o install.sh
less install.sh # read it
bash install.sh --model "minimax-coding-plan/MiniMax-M2.5-highspeed" --targets "claude,codex"The installer will:
Clone + build the server into ~/.local/share/opencode-delegate-mcp.
Write config to ~/.config/opencode-delegate/config.json.
Register the server with the hosts you chose (claude / codex / opencode).
Then restart your agent (or reload its MCP servers).
You don't have to run this yourself — paste the block below into Claude Code, Codex, or any coding agent with shell access. It'll run the command, read the output, and fix common problems (missing prerequisite, unauthenticated provider) itself instead of just reporting them.
Install and register the opencode-delegate-mcp MCP server for me. Use
opencode/deepseek-v4-flash-free(free, no signup) as the default model unless I say otherwise, register it with whichever of Claude Code / Codex you find on my machine, and use "user" scope (available in all my projects) unless I ask for "project" or "local" scope instead.Run:
curl -fsSL https://mryesiller.github.io/opencode-delegate-mcp/install.sh | bash -s -- --model "opencode/deepseek-v4-flash-free" --targets "claude,codex"Then show me the output, flag any warnings (missing OpenCode, unauthenticated provider, PATH issues), and confirm it's registered by running
claude mcp listand/orcodex mcp list. If something fails, diagnose and fix it rather than just reporting it.
The web configurator generates this same prompt for you, kept in sync with whatever model/targets/scope you pick in the form — see the "Prefer to have your AI do it?" card.
By default the installer registers the server globally (user scope) — available in every project on this machine. Pass --scope to change that, and --project-dir to pick which project (defaults to the directory you run the installer from):
curl -fsSL https://mryesiller.github.io/opencode-delegate-mcp/install.sh | bash -s -- --model "…" --scope project --project-dir "$(pwd)"
| Claude Code | Codex | OpenCode |
|
|
|
|
|
|
|
|
| Private to you, this project only (Claude Code's native local scope) | falls back to | falls back to |
Both hosts gate project-scoped config behind a one-time human approval — this isn't optional and an unattended script can't do it for you: Claude Code shows it as "⏸ Pending approval" in claude mcp list until you run claude interactively in that directory and approve it; Codex only loads a project's .codex/config.toml once you've approved that project as trusted, the first time you run codex there. Re-running the installer with a different --scope cleanly moves the registration (Claude Code: removed from every scope before re-adding at the new one; Codex/OpenCode: the old file entry is left as-is, so remove it by hand if you're switching away from project).
Node.js ≥ 18, npm, git, and curl.
OpenCode — the installer sets this up for you automatically if it's missing (see below), no separate step needed.
A provider authenticated (opencode auth login) — unless you use one of OpenCode's free opencode/* models below, which need no signup or API key at all.
The installer detects this and runs OpenCode's official installer for you — no separate step needed. One thing to know: OpenCode's installer adds ~/.opencode/bin to your shell's PATH by editing your rc file, but that only takes effect in new terminal sessions. So right after a fresh install, the opencode command may still say "not found" in your current terminal — that's expected. The delegate MCP itself isn't affected (it's configured with the full path), but to use the opencode command yourself, either open a new terminal tab or run source ~/.zshrc (or your shell's rc file — the installer tells you exactly which one).
Prefer to control this yourself? Pass --no-install-opencode to skip auto-install, or install OpenCode manually first from opencode.ai.
OpenCode ships a handful of free, no-auth-required models under the opencode/ provider. Use one to try delegation immediately, with nothing to configure:
curl -fsSL https://mryesiller.github.io/opencode-delegate-mcp/install.sh | bash -s -- --model "opencode/deepseek-v4-flash-free" --targets "claude,codex"Other free options: opencode/north-mini-code-free, opencode/mimo-v2.5-free. They're on a shared free tier, so expect lower rate limits than a paid provider — switch any time with config set (see Dynamic model / provider switching below) once you've got a key.
Tool | Purpose |
| Hand a self-contained coding task to the cheap model. It can read/write/edit files and run commands in a target directory. Returns the result text, session id, token usage, and the actions it took. |
| Test-focused wrapper: write (and optionally run) tests for a given scope without touching production code. |
| List available |
| Read the current configuration. |
| Change the active model/provider/settings at runtime — no reinstall. |
"Delegate to the cheap model: in
~/code/app, add JSDoc to every exported function insrc/utils/*.ts. Don't change behavior."
The primary agent calls delegate_task with directory: "~/code/app" and your task text; the cheap model does the mechanical work and reports back.
Installing the tools doesn't force an agent to use them — it decides, guided by its instruction file (CLAUDE.md for Claude Code, AGENTS.md for Codex). Add the delegation policy there to control it, and edit the conditions to fit your project.
✅ Delegate — high volume, low risk | ⛔ Keep on the primary agent |
Tests for well-specified behavior ( | Architecture, system design, choosing abstractions |
Boilerplate & scaffolding (CRUD, DTOs, fixtures, mocks) | Security-sensitive code (auth, crypto, secrets, permissions) |
Mechanical edits across many files (renames, prop propagation, import updates) | Concurrency, performance-critical paths, subtle correctness |
Lint / formatting / type-error fixes | Ambiguous / underspecified requirements needing judgment |
Docstrings, comments, README / changelog sections | Public API / interface design, breaking changes |
Straightforward data transforms or migrations with a clear spec | Debugging unknown root causes |
Obvious glue code / format conversions | Anything costly or hard to detect if the edit is wrong |
Rule of thumb: high volume + low risk → delegate. Low volume + high risk → keep it. Unsure → keep it.
📄 Full guide: docs/DELEGATION.md — how triggering works and how to customize the conditions.
📋 Drop-in policy: docs/delegation-policy.md — the exact block to paste into CLAUDE.md / AGENTS.md (this table plus preconditions and briefing tips).
Install it during setup with --policy (or tick the boxes in the web configurator) — idempotent, safe to run more than once:
bash /tmp/ocd-install.sh --model "…" --targets "claude,codex" --policy "claude,codex"You install once; you reconfigure as often as you like. A single config file is read fresh on every call, so switching the cheap model, provider, or any other setting never requires reinstalling. Four equivalent ways:
Web configurator → "Update settings" tab — generates a one-line config set command.
Terminal CLI (works wherever the server is installed):
node ~/.local/share/opencode-delegate-mcp/dist/index.js config set --model openrouter/minimax/minimax-m2.5
node ~/.local/share/opencode-delegate-mcp/dist/index.js config getFrom your agent, via the tool:
// set_delegate_config
{ "default_model": "openrouter/minimax/minimax-m2.5" } // switch provider+model
{ "default_model": "minimax-coding-plan/MiniMax-M2.7-highspeed", "timeout_ms": 900000 }Edit the file directly: ~/.config/opencode-delegate/config.json.
config CLInode dist/index.js config get # print current config
node dist/index.js config path # print config file path
node dist/index.js config set [flags] # patch config (only provided flags change)
--model <provider/model> --agent <name> --variant <name>
--timeout <seconds> --default-dir <path> --opencode-bin <path>
--auto-approve <bool>You can also override per call (delegate_task { model: "...", ... }) or define reusable profiles:
// set_delegate_config
{ "profiles": { "tests": { "model": "minimax-coding-plan/MiniMax-M2.5-highspeed" } } }
// then: delegate_task { profile: "tests", ... }Profiles are merged, not replaced — existing ones survive unless you name them (an empty { "profiles": {} } patch is a no-op, it won't wipe your profiles). To remove a profile, set its value to null:
// set_delegate_config
{ "profiles": { "tests": null } } // removes just "tests"; other profiles are untouched~/.config/opencode-delegate/config.json (override path with OPENCODE_DELEGATE_CONFIG):
Field | Type | Description |
| string | Path/name of the |
| string |
|
| string? | Default OpenCode agent. |
| string? | Default reasoning-effort variant (e.g. |
| boolean | Auto-approve tool permissions so headless delegations don't block (default |
| number | Per-delegation timeout in ms (default |
| string? | Default working directory. |
| object | Named presets: |
The server shells out to opencode run --dir <dir> --model <provider/model> --format json [--auto] "<task>", parses OpenCode's JSON event stream, and returns a compact result (final text, session_id, token/cost usage, and the list of tool actions taken). Provider credentials live in OpenCode's own auth (opencode auth) — this server never stores API keys.
The execution backend is abstracted (Backend interface), so other agent runtimes can be added later. OpenCode is the first.
This server does not store or transmit API keys. Provider auth is delegated to OpenCode.
autoApprove runs the cheap model non-interactively with tool permissions granted, so it can modify files and run commands in the target directory. Point delegations at repositories you trust and review the diffs. Set autoApprove: false to require manual approval (the delegation will then need an interactive OpenCode session).
npm install # installs deps and builds (prepare -> tsc)
npm run build # compile TypeScript to dist/
npm run dev # watch mode
node dist/index.js --versionMIT © mryesiller
Hand off self-contained, high-volume "grunt work" to a cheaper model running through OpenCode, so the primary agent can stay focused on architecture and critical decisions.
The subagent runs non-interactively in a real working directory and CAN read, write, and edit files and run shell commands there (auto-approved by default). Give it a complete, self-contained brief — it does not see your conversation.
Good for: writing repetitive/boilerplate code, mechanical refactors, generating tests, fixing lint/type errors, updating call sites, docstrings, simple migrations. Avoid for: architecture, security-sensitive logic, ambiguous specs, or anything where a wrong edit is costly.
Args:
task (string, required — alias: scope, accepted for parity with delegate_tests; provide one): Complete instructions for the subagent, including acceptance criteria.
directory (string): Absolute path of the repo/dir to work in. Defaults to the server's cwd or config.default_directory.
model (string): Override provider/model, e.g. "minimax-coding-plan/MiniMax-M2.5-highspeed". Defaults to config.default_model.
agent (string): OpenCode agent name to run as.
variant (string): Reasoning-effort variant, e.g. "high" | "minimal".
profile (string): Named preset from config (model/agent/variant/auto_approve).
files (string[]): Paths to attach as context.
session (string): Session id to continue a prior delegation (returned as session_id).
continue_session (boolean): Continue the last session instead of a specific id.
auto_approve (boolean): Auto-approve tool permissions (default from config, usually true).
response_format ('markdown' | 'json'): Output format (default 'markdown').
See also: delegate_tests — same shape, dedicated to test-writing; its required field is named scope instead of task.
Returns structured content: { ok, model, session_id, directory, result, error?, usage{tokens,cost}, actions[], duration_ms }.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Complete, self-contained instructions for the subagent. Required unless `scope` is given instead. | |
| agent | No | OpenCode agent name | |
| files | No | File paths to attach as context | |
| model | No | provider/model override (see list_models) | |
| scope | No | Alias for `task` (delegate_tests uses this name) — provide one or the other | |
| profile | No | Named config profile to apply | |
| session | No | Session id to continue | |
| variant | No | Reasoning-effort variant | |
| directory | No | Absolute working directory for the subagent | |
| auto_approve | No | Auto-approve tool permissions | |
| response_format | No | Output format | markdown |
| continue_session | No | Continue the last session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive hint true and readOnly false. The description adds significant context: subagent can read/write/edit files, run shell commands, auto-approve by default, does not see conversation, and returns structured content. This exceeds annotation info without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, front-loaded with key information. Every sentence adds value, despite length being appropriate for 12 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema (but return structure described), and complexity of delegation, the description covers purpose, usage, behavior, and sibling differentiation comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds usage context to key parameters (e.g., 'task/scope alias for parity with delegate_tests', directory default, model override, etc.), enhancing understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delegates a coding task to a cheaper model, specifying the verb 'delegate' and resource 'coding task'. It differentiates from sibling tool 'delegate_tests' by noting the alias 'scope' and that 'delegate_tests' is for test-writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Good for' and 'Avoid for' sections, guiding when to use the tool. It mentions the subagent is auto-approved and runs non-interactively, and suggests 'delegate_tests' as an alternative for test-writing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test-focused wrapper around delegate_task. The subagent writes (and optionally runs) tests for the given scope while avoiding changes to production code unless strictly required to make tests pass.
Args:
scope (string, required — alias: task, accepted for parity with delegate_task; provide one): What to test — module, files, behaviors, edge cases.
directory (string): Absolute repo path. Defaults to config.default_directory or server cwd.
framework (string): Optional testing framework/runner hint (e.g. "vitest", "pytest").
run_tests (boolean): Ask the subagent to run the suite and report pass/fail (default true).
model / agent / variant / profile / files / session / continue_session / auto_approve: same as delegate_task.
response_format ('markdown' | 'json'): Output format (default 'markdown').
See also: delegate_task — same shape, general-purpose; its required field is named task instead of scope.
Returns the same structured content shape as delegate_task.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Alias for `scope` (delegate_task uses this name) — provide one or the other | |
| agent | No | ||
| files | No | ||
| model | No | ||
| scope | No | What to test: module/files/behaviors/edge cases. Required unless `task` is given instead. | |
| profile | No | ||
| session | No | ||
| variant | No | ||
| directory | No | Absolute working directory | |
| framework | No | Testing framework/runner hint | |
| run_tests | No | Run the suite and report results | |
| auto_approve | No | ||
| response_format | No | markdown | |
| continue_session | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds context that changes to production code are avoided unless strictly required, which is more nuanced than the annotation alone. It also mentions optional run_tests behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, See also, Returns) and front-loaded purpose. While somewhat verbose, every sentence adds value. Could be slightly tighter but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and adequate annotations, the description covers core behavior, parameter semantics, and cross-references delegate_task for completeness. The return value is not detailed but correctly noted as same shape as delegate_task. Minor gap: no explicit mention of error handling or side effects beyond 'avoids production code changes'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 36% schema coverage, the description compensates by listing and explaining many parameters (scope, directory, framework, run_tests, response_format, and the alias task). However, several parameters are only referenced as 'same as delegate_task' without full detail, relying on the agent's knowledge of that sibling. Some meaning is added, but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is a test-focused wrapper around delegate_task, with the subagent writing and optionally running tests while avoiding production code changes. This specific verb+resource combination clearly distinguishes it from the general-purpose delegate_task sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: it is for test writing/running, avoids production code changes unless necessary, and explicitly references delegate_task as an alternative with a different parameter name (task vs scope). This helps the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current delegate configuration (default model/provider, agent, variant, auto-approve, timeout, default directory, and named profiles) plus the config file path. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds value by listing the returned fields (config file path, named profiles) beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists multiple return fields, adequate for a read-only tool. No mention of error cases, but given simplicity, acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description correctly avoids any parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the delegate configuration, listing specific fields (default model/provider, agent, variant, etc.) and explicitly says 'Read-only.' This distinguishes it from sibling tools like set_delegate_config (modify) and delegate_task (execute).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'read-only', implying safe invocation. While no explicit 'when not to use' is given, the sibling tools cover different operations, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List provider/model ids that OpenCode can use, in "provider/model" form (e.g. "minimax-coding-plan/MiniMax-M2.5-highspeed"). Optionally filter to a single provider. Use these ids for the model argument of delegate_task or as default_model in set_delegate_config.
Args:
provider (string): Optional provider id to filter by (e.g. "minimax-coding-plan", "openrouter").
contains (string): Optional case-insensitive substring filter.
limit (number): Max ids to return (default 200).
response_format ('markdown' | 'json'): Output format (default 'markdown').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max ids to return | |
| contains | No | Case-insensitive substring filter | |
| provider | No | Filter to a single provider id | |
| response_format | No | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining return format and filtering behavior, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with an introductory sentence and bullet list for parameters. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with readOnly/idempotent hints and no output schema, the description covers all necessary aspects: purpose, parameters, output format, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds examples and clarifies defaults for all 4 parameters. Schema has 75% coverage with descriptions; description compensates for the gap by adding examples and context, though defaults are already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available provider/model IDs, gives an example format, and explains their use with `delegate_task` or `set_delegate_config`, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies when to use (to get model IDs for delegation) and mentions optional filtering. It lacks explicit when-not or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the active delegation settings at runtime — this is how you dynamically switch the cheap model or provider without reinstalling. Only the fields you pass are updated. Returns the updated config.
Args (all optional):
default_model (string): provider/model used when a call omits one, e.g. "openrouter/minimax/minimax-m2.5".
default_agent (string): default OpenCode agent.
default_variant (string): default reasoning-effort variant.
auto_approve (boolean): auto-approve tool permissions for delegations.
timeout_ms (number): per-delegation timeout in milliseconds.
default_directory (string): default working directory.
opencode_bin (string): path/name of the opencode binary.
profiles (object): map of name -> { model?, agent?, variant?, autoApprove? }. Profiles are MERGED, not replaced — existing ones are kept unless you name them. To ADD or UPDATE a profile, give it a value; to REMOVE one, set its value to null: { "profiles": { "tests": null } }.
| Name | Required | Description | Default |
|---|---|---|---|
| profiles | No | Named presets to merge in; set a name's value to null to remove that profile | |
| timeout_ms | No | ||
| auto_approve | No | ||
| opencode_bin | No | ||
| default_agent | No | ||
| default_model | No | provider/model default | |
| default_variant | No | ||
| default_directory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutable, idempotent, non-destructive. The description adds critical detail: runtime dynamic switching, partial updates, profile merging (not replacement), and null-based removal. This enriches the annotation signals without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then partial update note, then parameter list. Every sentence adds value without redundancy. It is sufficiently detailed yet concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 optional parameters and nested objects, the description covers all fields and behavior (merge/remove). It states the return value ('Returns the updated config'), fulfilling completeness for a configuration update tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%), but the description compensates by explaining all 8 parameters, including the complex profiles object (merge vs remove behavior). It adds clear examples (e.g., 'openrouter/minimax/minimax-m2.5') and specific usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: 'Change the active delegation settings at runtime' with a specific verb ('change') and resource ('delegate configuration'). It distinguishes itself from sibling tools (e.g., get_delegate_config, delegate_task) by focusing on updating configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational guidance: 'Only the fields you pass are updated' and explains profile merging and removal behavior. However, it does not explicitly contrast with siblings like get_delegate_config for reading or delegate_task for delegation, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.3delegate_taskdelegate_testsget_delegate_configlist_modelsset_delegate_configEach tool has a clearly distinct purpose: config read, config write, two specialized delegation tasks (general vs test), and model listing. The two delegation tools are differentiated by required field and documented use cases.
All tools use consistent snake_case with a verb_noun pattern (get_, delegate_, list_, set_). No mixing of conventions.
5 tools is well-scoped for the server's purpose: reading/writing config, listing models, and delegating tasks (general and test-specific). No excess or deficiency.
Covers all core operations for configuring and using delegation. Minor gap: no tool to retrieve results of a past delegation by session ID, but the delegation tools return results synchronously, so it's not a critical omission.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
Make your coding agent better and earn: verified code, paid per use, on a real agent economy.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mryesiller/opencode-delegate-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
