MCP 工具全表
Vyane 作为 MCP server 暴露的全部工具 —— 给 Claude Code / Codex 等客户端调用
Vyane 内置一个 MCP server(基于 FastMCP,走 stdio),把自己的派发、编排、看板、会话等能力打包成一组 vyane_* 工具。把 Vyane 挂进 Claude Code、Codex CLI 或任何 MCP 客户端后,这些工具就出现在客户端的工具列表里,像调本地函数一样直接调用——不需要自己拼 HTTP 请求,也不需要记 CLI 参数。
MCP 是什么
MCP(Model Context Protocol)是一套让 AI 客户端调用外部工具的标准协议。Vyane 这一层的作用:让一个 AI(比如 Claude Code 里的主对话)能把子任务转派给别的模型、跑多模型编排、读写任务看板——全靠调这些工具完成。
怎么启动
不带任何子命令直接跑 vyane,启动的就是 MCP server(stdio 传输):
uv run vyane一般不用手动跑——你在 MCP 客户端(Claude Code、Codex 等)的配置里把 Vyane 登记为一个 stdio server,客户端会自己拉起它。想验证本机 MCP 能不能正常启动,用 uv run vyane mcp-smoke --json。
当前 server 一共注册了 19 个工具,下面按用途分组列全。工具名、作用、关键参数都以源码真实注册为准。
工具名对照
客户端里若看到 vyane_workflow_v2 这类别名,以本页为准:v2 编排引擎的工具名就是 vyane_workflow,老的线性流水线是 vyane_workflow_legacy。
派发与编排
把任务交给模型执行,是这组工具的核心。
| 工具名 | 作用 | 关键参数 |
|---|---|---|
vyane_dispatch | 把一个任务派给某个执行目标(模型 / harness),返回结果。最常用的单发工具。 | provider(目标选择器,可写 harness / provider / target/model)、task(任务描述)、sandbox(read-only / write / full)、session_id(接续 native runtime 会话)、vyane_session(接续 Vyane topic 会话)、model / profile / reasoning_effort、failover、async_mode(异步跑,返回 run_id) |
vyane_broadcast | 把同一任务并行派给多个模型,一次拿回所有结果。用于共识评审、多视角分析、A/B 对比。 | task、providers(模型列表,支持 provider/model 或带选项的 dict)、compare(加结构化对比:相似度 / 速度排名 / 各家独有措辞)、sandbox、response_schema_id(统一结构化输出契约) |
vyane_collaborate | 多 agent 迭代协作:agent 互审彼此产出、给反馈、迭代到收敛。比 dispatch(单发)和 workflow(线性流水线)更进一步。 | task、pattern(review 实现→评审→修订环 / consensus 多视角并行+综合 / debate 正反辩论+仲裁)、providers(角色→模型 的 JSON 映射)、max_rounds、list_patterns(列出可用模式) |
vyane_orchestrate | 管理 Phase 1 编排任务的生命周期:拆解、分配、执行、评审、合并。 | action(plan / phase-plan / phase-materialize / assign / execute / status / review / merge)、task、task_id、topology(star / pipeline / parallel-team)、max_dev_teams、collaboration_template |
vyane_workflow | 跑一段 JS 编排脚本(v2 引擎,Deno 沙箱)。脚本里的每个 agent() 调用都经 kernel 准入后落到派发。 | script(JS 脚本文本)、args(暴露给脚本的 JSON)、sandbox_default、budget_tokens / budget_usd(预算硬闸)、timeout(墙钟秒,超时硬杀)、resume_from(按 journal 前缀回放,不重复烧配额) |
vyane_workflow_legacy | 老的线性流水线工作流(v1):多个 provider 顺序执行,后一步能引用前一步产出,状态落盘可恢复。 | workflow(工作流名,如 review / consensus)、task(起始输入)、list_workflows(列出可用工作流)、resume_id(恢复此前失败 / 暂停的工作流) |
dispatch 接续上下文
多轮对话接续用 session_id(接 native runtime 会话)或 vyane_session(接 Vyane topic 会话)——把上一次结果里返回的 id 传回来即可。异步跑用 async_mode,它会立刻返回一个 run_id,后续用下面的任务管理工具查状态。
异步任务管理
vyane_dispatch 开了 async_mode 后会在后台跑,返回一个 run_id。这组工具用来盯这些后台任务。
| 工具名 | 作用 | 关键参数 |
|---|---|---|
vyane_task_status | 查一个异步派发任务的状态。 | run_id、include_output(任务完成时是否连完整输出一起返回) |
vyane_task_list | 列出当前所有活跃(非终态)的异步任务,按启动时间排序。 | 无(可选 owner_user_id 作 owner 范围) |
vyane_task_cancel | 取消一个正在跑的异步任务。 | run_id |
vyane_task_pause | 暂停一个正在跑的异步任务(当前 adapter 调用结束后不再继续)。 | run_id |
vyane_task_resume | 恢复一个被暂停的异步任务。 | run_id |
会话与历史
保存跨轮上下文、回看派发记录。
| 工具名 | 作用 | 关键参数 |
|---|---|---|
vyane_session | 管理持久化的 Vyane topic 会话(话题级任务会话,不绑定模型 / harness,可 resume / handoff)。 | action(create / list / history / message / bind / archive)、session_id、title、content(写消息时)、agent_id、runtime_session_id(绑定 native 会话) |
vyane_history | 查派发历史和分析数据:近期结果(含完整输出),或聚合统计。 | limit、provider(按模型过滤)、status(success / error)、hours(近 N 小时)、stats_only(只要聚合统计)、costs(带 token 用量 + 估算美元的成本明细) |
vyane_feedback | 给某次派发结果打分,分数会聚合进路由偏好——评分高的模型今后被优先路由。 | run_id、rating(1-5)、comment、list_recent(改成看近期反馈而非提交) |
看板(Beacon)
读写 Beacon 任务看板。真值源是 Git 仓里的结构化文件,这几个工具经共享 ledger API 操作。
| 工具名 | 作用 | 关键参数 |
|---|---|---|
vyane_board_status | 读看板 issue 列表,支持多维过滤和排序。 | board_dir(看板目录)、state / project / priority / assignee / label(逗号分隔过滤)、mine(只看分给 by 的进行中 / 待审卡)、sort / reverse / limit |
vyane_board_show | 读单张 issue 的详情。 | board_dir、issue_id |
vyane_board_render | 预览看板渲染产出但不写文件(dry run)。 | board_dir、mode(仅 dry_run)、include_content |
vyane_board_write | 执行一个看板写操作(建卡 / 认领 / 记录 / 完成等)。 | action(log / take / done / drop / cancel / new)、title(新建时的标题)、issue_id、project / priority / desc / labels、mode(默认 dry_run,真写要显式 commit_no_push 或 commit_push)、by、message / next |
写看板默认不落盘
vyane_board_write 的 mode 默认是 dry_run——只演算不真写。真正要落盘,必须显式传 commit_no_push(提交不推)或 commit_push(提交并推)。这一层是故意的防误写设计。
诊断
| 工具名 | 作用 | 关键参数 |
|---|---|---|
vyane_check | 查各模型 CLI 是否可用,并展示当前生效配置:codex / gemini / claude 的可用性、活跃 profile、检测到的调用方平台、被排除的 provider。 | diagnose(传一段任务描述,会展示每个 provider 的四信号打分明细,用来诊断路由决策) |
都带 owner 隔离
上面几乎每个工具都接受一个可选的 owner_user_id 参数,用来做多用户 / 多身份的数据隔离——任务、会话、历史、反馈都按 owner 分开存放。单人自用时不用管它,走默认即可。