Click on "Deploy 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., "@Legion Workflow MCP refactor all API calls in src/ to use the new fetch wrapper"
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.
多子代理"军团"工作流服务器（MCP）。给 opencode 客户端提供一个 brigade_run 工具：把一个软件工程任务交给一队子代理并行完成——架构师拆 DAG → 影子目录隔离实现 → 产物 + exec 机器验收 → 审查闸门 → summary.md 汇总。适合大范围重构、批量修复、多方案对比这类单会话干不动、又不想手动开 N 个会话的活。
危险命令过滤器只作用于机器验收命令（accept 里的 exec: 条目）：递归删除用户目录/盘根、格式化、注册表与卷影破坏等会被拦截并标记 BLOCKED。它不覆盖子代理会话内部自己执行的命令——子代理通过 opencode run 运行。注意：accept 里的 exec: 由系统以 shell 在任务工作目录执行（写任务在影子副本，只读任务在真实项目目录），过滤器只拦已知破坏模式，不是沙箱。
写任务默认全权限，不继承宿主审批：实现/测试等写任务会在影子副本里写入 .opencode/opencode.json，把 permission 强制设为 allow，并禁用该副本里发现的 MCP 服务；该文件只存在于影子副本，不会回写你的项目。可用 LEGION_PERMISSION 覆盖（仅字符串，如 ask/deny；设为 ask 时无人值守运行可能因等待审批而超时）。只读任务（勘察/调研/设计/审查）不写该配置，沿用宿主 opencode 配置；"只读"是提示词约束而非沙箱，越界写入会被检测记录但不会被阻止。请像对待任何自主编码代理一样对待它：先备份，或在隔离/低权限环境中运行。
提示词注入面：brigade_run 的 goal 与 hints 会原样拼进架构师提示词，架构师生成的任务描述又会拼进各 worker 提示词；仓库文件与联网搜索结果同样进入上下文。不要把不可信文本直接当作 goal，也不要在含不可信内容的仓库上无人值守运行——worker 在影子目录内是 allow 权限，可能执行其中的指令。
写任务的影子副本机制会把 cwd 指向的目录按排除规则复制到工作区（默认跳过 node_modules、.git、build、dist、.opencode 等，可用 LEGION_EXCLUDE 追加）；.env 等未排除文件也会被复制，落在 BRIGADE_RUNS_ROOT/shadow 下并默认保留约 3 天，请按敏感数据对待。请在具体项目目录上运行（盘根/用户主目录/系统目录/UNC 路径会被拒绝）。
协调层 Redis 只应使用专用本地实例：默认端口 6390，启动时先连 127.0.0.1:6390，连不上才尝试拉起 redis-server。redis-server 需在 PATH 中，或用 BRIGADE_REDIS_BIN 指定完整路径；未安装时约 3 秒后自动降级为单实例（功能可用，跨实例互斥与在飞统计失效；首次调用也可能因此多等约 3 秒），也可用 BRIGADE_REDIS=0 显式关闭。不要把 BRIGADE_REDIS_PORT 指向承载其他数据的实例。
Related MCP server: pi-mcp
Windows（进程树管理依赖 taskkill/tasklist；Linux/macOS 未适配）
Node.js ≥ 18（确保 node 在 PATH 中；MCP 配置里用的是裸命令 node）
本机安装并登录 opencode CLI
把整个 LegionWorkflowMcp 文件夹放到任意固定位置（目录必须可写：MCP 台账 workflow-mcp/.mcp-runs、运行产物与影子副本 brigade/runs、Redis 数据 brigade/.redis 默认都落在包内。只读位置请用 BRIGADE_RUNS_ROOT / BRIGADE_MCP_STATE_DIR 外移，并设 BRIGADE_REDIS=0；本包零依赖，无需 npm install），然后在全局配置 ~/.config/opencode/opencode.json（或 .jsonc）里注册（把路径换成你的实际位置）：
{
"mcp": {
"brigade": {
"type": "local",
"command": ["node", "C:/your/path/LegionWorkflowMcp/workflow-mcp/server.js"],
"enabled": true,
"timeout": 120000
}
}
}重启 opencode 客户端后即可看到工具。
工具 | 说明 |
| 出动军团执行任务（异步：立即返回 mcpId）。参数： |
| 按 mcpId 查询进度（每任务明细） |
| 列出历史运行 |
| 按 mcpId 停止本机台账内的一次运行（停止其进程树；原生 runId 不支持， |
| 使用说明与参数模板 |
变量 | 默认 | 说明 |
| （无） | 子代理默认模型 id，格式 |
| （无） | 额外保护目录（逗号/分号分隔，如 |
| （无） | 影子复制/发布时额外排除的目录名（逗号/分号分隔；默认已排除 |
|
| 写任务影子目录里 worker 的 opencode |
| 自动探测 | opencode 可执行文件完整路径（先探测 npm 全局安装，再回退 PATH 中的 |
| （直连） | 子代理抓页的 HTTP 代理 |
| 包内 | 原生运行台账/影子副本/报告根目录（server 与引擎两侧都读它；建议绝对路径） |
| 包内 | MCP 层 |
|
| 协调层 Redis 专用端口（只连 |
| PATH 里的 | redis-server 可执行文件路径；未安装则约 3 秒后降级为单实例 |
| 未设置（启用） | 设为 |
注册时在 mcp 条目加 "environment": { ... } 即可生效。
验收命令过滤器对所有 accept 里的 exec: 条目始终生效（不可配置关闭；不覆盖子代理内部命令，见上）：删除用户主目录/C:\Users（含通配符与前缀星形态）、任何盘符根、vssadmin/wbadmin/bcdedit/reg 破坏、robocopy /MIR、cipher /w、diskpart、format、takeown/icacls（命令位即拦）、管道投喂删除用户目录等（272 例矩阵回归锁定）。受保护目录（LEGION_PROTECTED 命中项、家目录变量形态、C:\Users\<name> 及其常见子目录）的递归删除会被拦截，不再有"深层子路径一律放行"的豁免；盘根单独拦截。注意字面 C:\Users\<name> 内置只覆盖到下一层（如 Documents），要覆盖整棵树请把该目录加入 LEGION_PROTECTED。保护树之外的普通产物目录（build/、tmp/、node_modules/ 等）才会放行。改拦截规则请同步更新 brigade/cp/danger-matrix-test.js 并保持 mismatches=0。
npm run test:danger # 危险门 272 例回归：mismatches=0 退出 0；任何不匹配退出 1
node -e "const{spawn}=require('child_process');const c=spawn(process.execPath,['workflow-mcp/server.js'],{stdio:['pipe','pipe','pipe']});let seen=false,done=false;const fin=(code)=>{if(done)return;done=true;try{c.kill()}catch{};process.exit(code)};const check=()=>{if(seen)fin(0)};c.stdout.on('data',()=>check());c.stderr.on('data',d=>{if(String(d).includes('ready on stdio'))seen=true;check()});c.on('error',()=>fin(1));c.on('exit',()=>fin(seen?0:1));setTimeout(()=>fin(seen?0:1),5000)" # 启动自检：看到 ready on stdio 退出 0；5 秒内没看到或异常退出则退出 1LegionWorkflowMcp/
├─ workflow-mcp/server.js # MCP 服务器（stdio）
├─ brigade/
│ ├─ brigade.js # 战役入口（server 派生的子进程）
│ ├─ planner.js / roles.js # DAG 拆解与角色提示词
│ ├─ subagent.js # opencode CLI 子代理驱动
│ ├─ mcp/websearch.js # 子代理联网搜索/抓页小工具（可用 WEBSEARCH_PROXY）
│ └─ cp/ # 执行管线（调度/隔离/验收/危险门/协调…）MIT — 可自由使用、修改与再分发。
列出军团历史运行（最新在前）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a list operation and that results are ordered newest first, but omits pagination, result limits, or explicit read-only status beyond what '列出' implies.
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?
A single, short sentence that is front-loaded with the action and resource, then adds the only meaningful modifier (newest first). No words are wasted.
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 zero-parameter, low-complexity list tool with no output schema, the description gives enough to invoke it correctly and understand the ordering. It could clarify return shape or pagination, but those are minor gaps for this simple listing operation.
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?
The tool has zero parameters, so there is no parameter semantics to document. The baseline for 0 params is 4, and the description correctly adds no unnecessary parameter details.
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?
States a specific verb and resource: '列出军团历史运行' (list brigade historical runs). It also adds scope/order '最新在前' (newest first), which distinguishes it from siblings like brigade_run (start a run), brigade_status (current status), and brigade_stop.
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 implies usage for reviewing historical runs, but gives no explicit when-to-use guidance, no when-not-to-use conditions, and does not name alternative tools such as brigade_status for current state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
出动多子代理军团执行一个软件工程任务（架构师拆解→影子目录隔离实现→产物+exec 机器验收→审查闸门→summary.md）。子代理通过本机 opencode CLI 运行，默认使用 opencode 当前配置的模型（可能产生费用）（可用 model 参数或 LEGION_MODEL 环境变量覆盖）。异步：立即返回 mcpId，用 brigade_status 轮询。
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 工作目录绝对路径，改动会合并回这里（必填） | |
| goal | Yes | 要完成的目标，一句话（必填） | |
| hints | No | 给架构师的补充约束 | |
| model | No | 子代理使用的模型 id，格式 provider/model（如 opencode/beam-free，以你本机可用模型为准）；不填则用 opencode 当前默认模型或 LEGION_MODEL 环境变量。注意：默认模型可能是付费模型，会产生费用，请自行确认 | |
| noTest | No | 关闭测试环节 | |
| noReview | No | 关闭审查环节 | |
| timeoutSec | No | 单任务超时秒数，默认 900 | |
| maxParallel | No | 并发子代理数，默认 3，上限 8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that this is asynchronous (returns mcpId immediately), that sub-agents use the local opencode CLI, that costs may be incurred, and that the default model is overridable via model param or LEGION_MODEL. It omits permission/auth requirements and how the cwd is affected, but the cost and async warnings are genuinely valuable behavioral context.
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?
It is a single dense but front-loaded paragraph that opens with the core action and pipeline, then layers cost and async notes. Nothing is padded, though the parenthetical cost caveat appears twice, slightly reducing efficiency.
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 an 8-parameter, no-output-schema, no-annotation tool, the description supplies the pipeline, async contract, and cost model an agent needs to invoke it responsibly. Return-value details beyond mcpId are minimal, but polling via brigade_status covers the follow-up, leaving only minor gaps.
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 description coverage is 100%, so the schema already documents all 8 parameters including model defaults, timeouts, and concurrency limits. The description largely restates the model/cost behavior already present in the schema and adds no further parameter semantics, making the baseline 3 correct.
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?
States a specific verb and resource — launching a multi-sub-agent brigade for a software engineering task — and even outlines the internal pipeline (architect → shadow-dir implementation → verification → review gate → summary). It distinguishes itself from siblings by naming brigade_status as the mechanism to poll results.
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 explains the async execution model and explicitly routes the agent to brigade_status for polling, which is the key usage decision. It does not, however, contrast with brigade_template or state when NOT to run a full brigade, so the sibling guidance is partial rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询军团运行状态：每任务状态/耗时/尝试次数、运行阶段（planning/running/done/failed/interrupted）、输出日志尾部、summary 路径。run 传 brigade_run 返回的 mcpId 或原生 runId。
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | mcpId 或原生 runId（必填） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does describe the returned content (tasks, phases, log tail, summary path), which is genuinely useful, and 查询 implies read-only. However it never states safety profile, whether it polls/wait, or behavior for a finished/failed run, and there is no output schema to fill that gap.
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?
Two sentences, both front-loaded with the highest-value information (what status reports, then how to supply the run id). The parenthetical phase list is compact and earns its space; no filler.
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 single-parameter read tool with no annotations and no output schema, the description covers purpose, return contents, and argument provenance well. Remaining gaps are minor: no statement of read-only semantics or behavior when the run has already terminated.
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% and the schema already says 'mcpId 或原生 runId（必填）'. The description repeats the same accepted-value information for `run` almost verbatim, adding only the provenance hint that mcpId comes from brigade_run. Baseline 3 is appropriate when the schema does the documenting.
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?
Names a specific verb (查询) and resource (军团运行状态) and enumerates exactly what is surfaced: per-task status/duration/attempts, run phase, log tail, summary path. That enumeration clearly separates it from brigade_list (enumerating runs) and brigade_run (starting one), though no sibling is named explicitly.
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 second sentence tells the agent what to pass to `run` (the mcpId returned by brigade_run, or a native runId), which implicitly positions this as the follow-up call after brigade_run. It gives clear context but states no exclusions and does not contrast with brigade_list or brigade_stop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
终止一个正在运行的军团任务树。
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | brigade_run 返回的 mcpId（必填） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says the task tree must be '正在运行的' (currently running), implying a condition, but does not disclose side effects on child tasks, authentication requirements, idempotency, error behavior, or what happens to incomplete tasks.
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 a single, front-loaded sentence with no redundant wording. It is appropriately sized for a one-parameter operation and every word earns its place.
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 seemingly destructive termination tool with no annotations and no output schema, the description is too sparse. It omits what happens to the task tree, error conditions, permission needs, and the expected result, leaving the agent without necessary 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?
Schema description coverage is 100%, and the schema already documents 'run' as the required mcpId returned by brigade_run. The description adds no additional parameter meaning beyond what is in the schema, so the baseline of 3 is appropriate.
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 states a specific verb ('终止' / terminate) and resource ('军团任务树' / brigade task tree), making the tool's purpose clear. It does not explicitly distinguish itself from sibling tools like brigade_status or brigade_list, but the action is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives such as brigade_status, brigade_list, or brigade_run. It does not state prerequisites, when termination is appropriate, or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
军团工作流的使用说明与参数模板（什么时候该用 / 怎么轮询）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It hints at behavior by mentioning polling ('怎么轮询'), which is useful context for an agent coordinating the workflow, but it never states that this is a read-only informational resource or what happens on invocation. Modest but incomplete disclosure.
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?
A single short sentence with the resource front-loaded and the two key topics (when to use, how to poll) bracketed at the end. No waste, nothing padded.
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 zero-parameter guide tool with no output schema, the description should at least characterize the shape of what comes back (template fields, polling cadence). It gestures at the content but leaves the return format entirely undefined, which is a real gap for a tool whose whole value is its payload.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The 'parameter template' phrasing refers to the tool's content, not to inputs, so no parameter semantics are actually required.
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 names a specific resource — usage instructions and a parameter template for the brigade workflow — which is distinct from the run/status/list/stop siblings. However it states the resource as a noun phrase with no verb and never explicitly says 'call this to get X', so sibling differentiation is implied 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It claims to contain 'when to use' guidance (什么时候该用), which implies the tool is a routing aid, but the description itself does not tell the agent when to invoke this tool versus brigade_run or brigade_status. Usage is left to be discovered from the tool's payload rather than stated in the definition.
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.
v1.1.0brigade_listbrigade_runbrigade_statusbrigade_stopbrigade_templateScored across 5 tools
五个工具分别对应异步任务的启动、状态查询、历史列表、终止与使用说明，动作与目标资源都各不重复，边界清晰。brigade_status 与 brigade_list 虽然都涉及运行记录，但一个是单次运行详情、一个是历史清单，不会混淆。
全部采用 brigade_ 前缀加单一动词/名词的 snake_case 命名（run/status/list/stop/template），模式高度统一。没有大小写或动词风格混杂的情况。
作为一个异步工作流编排服务，5 个工具正好覆盖一次任务完整生命周期所需的核心操作，没有冗余也没有明显拆得过细。每个工具都承担独立职责。
启动、轮询、列表、终止、使用模板构成完整闭环，异步任务的主要动线都有覆盖。轻微缺口在于没有直接读取完整日志/产物的工具（仅返回 summary 路径），但可通过外部方式补偿。
Hosted coding agent: start, follow up on and stop tasks that can open GitHub pull requests.
Start and manage Reason cloud coding agents, projects and sessions from any MCP client.
Scoped agent execution. Server-side credentials, policy, budgets and verifiable receipts.
Execution control plane for agents: capabilities, durable jobs, budgets, receipts, and BYOK.
