@mrrlin-dev/external-agents

Overview Schema Source Related Servers Discussions Admin

dispatch

Run a specified agent by ID with a prompt, optionally overriding transport (read-only/edit/generate), attaching files and cwd, and escalating to a stronger tier only when needed.

Instructions

Run a specific agent by id with a prompt. transport ('generate_new' | 'edit_exists' | 'read_only') overrides the default. With cwd, edit_exists is preferred when declared; otherwise generate_new is preferred. escalate_to_pro=true uses the same-provider strong-tier entry instead.

read_only: use when the agent must NOT be able to write — e.g. a reviewer dispatched into a live repo it is judging. Selects a declared read_only command, or an implicit generate_new (HTTP has no filesystem access at all). An entry with only edit_exists and no read_only errors rather than silently falling back to the write-capable command.

ROUTING NOTE: for the same task, weak-tier free-tier models (Gemini flash, Groq Qwen, DeepSeek, OpenRouter :free) are usually correct AND fast enough. Use dispatch against Claude Opus, Codex Pro, or any strong-tier subscription model ONLY when the task genuinely needs frontier capability. escalate_to_pro is a retry lever, not a default. If a weak agent's output is wrong, first ask whether the SPEC was ambiguous (fix the spec, re-dispatch weak) before escalating tier — reaching for stronger models hides prompt-engineering failures behind expensive compute.

cwd: absolute path of an existing directory (e.g. a git worktree) for an edit_exists agent to run IN and edit files in place. When an agent declares edit_exists, supplying cwd selects it by default. generate_new (HTTP) ignores cwd and has no filesystem access. When cwd is a git repo, the returned files list is the git-changed set, not the whole tree.

files: array of {path, lines?, label?} entries. Their contents are read from disk and prepended to the prompt as a structured context block. CRITICAL for generate_new agents (they have ZERO filesystem access — without files they hallucinate code shapes). Optional for edit_exists: direct CLIs can inspect cwd themselves; attach files only when you need to constrain or highlight context. Paths resolve relative to cwd. IMPORTANT: when using files, ALWAYS pass cwd (the repo root) — it serves as the containment basedir for path resolution and security. Without cwd, paths resolve against the MCP server process cwd, which is likely wrong.

By default this refuses a prompt larger than agent_id's known token-per-minute ceiling (the same declared/observed limit pick_agents checks before seating one) instead of sending it and getting a live HTTP 413. Pick a different (or larger-ceiling) agent_id, or set allow_oversized_prompt=true to send it anyway.

Input Schema

Name	Required	Description
`cwd`	No
`files`	No	Attach file contents to the prompt so the agent sees real code, not hallucinated shapes. Each entry: { path: 'relative/or/absolute', lines?: '10-50', label?: 'short name' }. Paths resolve relative to cwd (or process cwd). The contents are prepended to the prompt as a structured context block. Essential for generate_new agents (no filesystem access); optional for edit_exists because direct CLIs can read cwd.
`prompt`	Yes
`agent_id`	Yes
`transport`	No
`escalate_to_pro`	No
`allow_oversized_prompt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.63.0Oct 23, 2026

addedInput schema / properties / allow_oversized_prompt
```
Added value: +{
+  "type": "boolean"
+}
```
addedInput schema / properties / cwd
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / files

Added value: +{
+  "description": "Attach file contents to the prompt so the agent sees real code, not hallucinated shapes. Each entry: { path: 'relative/or/absolute', lines?: '10-50', label?: 'short name' }. Paths resolve relative to cwd (or process cwd). The contents are prepended to the prompt as a structured context block. Essential for generate_new agents (no filesystem access); optional for edit_exists because direct CLIs can read cwd.",
+  "items": {
+    "properties": {
+      "label": {
+        "description": "Display label in the context block. Defaults to the path.",
+        "type": "string"
+      },
+      "lines": {
+        "description": "Line range, e.g. '10-50'. Omit for entire file.",
+        "type": "string"
+      },
+      "path": {
+        "description": "File path (absolute or relative to cwd)",
+        "type": "string"
+      }
+    },
+    "required": [
+      "path"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / transport / enum

Previous value: -[
-  "generate_new",
-  "edit_exists"
-]New value: +[
+  "generate_new",
+  "edit_exists",
+  "read_only"
+]

First observedv0.29.0Jul 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the oversized-prompt refusal and the resulting 413 avoidance, path containment/security behavior via cwd, that generate_new has zero filesystem access, that an entry with only edit_exists and no read_only errors instead of silently falling back, and that the returned files list is the git-changed set rather than the whole tree. These are non-obvious traits an agent could not infer from the schema.

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?

Purpose is front-loaded and each paragraph maps to a parameter or behavior, so the structure is clean. It runs long and repeats the 'generate_new has no filesystem access' point three separate times, which is more verbosity than the complexity strictly requires.

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 7-parameter execution tool with no annotations and no output schema, this covers what an agent needs: transport selection precedence, escalation policy, file-context requirements, containment rules, error behavior, and prompt-size limits. Even the return value's meaning (git-changed set vs whole tree) is explained without an output schema.

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 description coverage is only 14%, so the description must compensate, and it does for cwd, files, transport, escalate_to_pro, and allow_oversized_prompt — including the default-selection logic (cwd + edit_exists preferred) and relative-path resolution rules. agent_id and prompt get no elaboration beyond the opening sentence, which is the only real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: 'Run a specific agent by id with a prompt.' That is unambiguous and easy to tell apart from pick_agents (selection) or list_agents (enumeration). It never names a sibling explicitly, so differentiation is implicit rather than stated.

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?

Explicit when-to-use rules are everywhere: use read_only 'when the agent must NOT be able to write, e.g. a reviewer dispatched into a live repo it is judging,' use escalate_to_pro only for genuine frontier tasks, attach files for generate_new but only sparingly for edit_exists. The routing note even prescribes a diagnostic order (fix the spec before escalating tier), which is unusually strong guidance.

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

Deploy Server

dispatch

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools