This server lets MCP-compatible AI clients discover and run configured Bayze model-routing workflows locally and inspect prior run metadata.
List workflows: show configured workflow IDs, limits, and step chains without credentials or endpoints.
Run workflows: execute a configured workflow (e.g., draft → structured review → revise) with required workflow and input, plus optional context; returns a structured result where finalOutput is untrusted model-generated content.
Tighten limits: override max_chars, max_steps, max_cost_usd, and total_timeout_ms; larger values are clamped with a warning.
Inspect runs: fetch a metadata-only journal summary for a previous run_id; prompts and responses are never stored.
Supports configuring OpenAI and OpenAI-compatible model providers as workflow steps, using BYOK API keys to run model-routing workflows such as drafting, review, and revision.
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., "@Bayze Run review_then_revise on my draft, then show the run summary"
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.
· English
本地运行、可审计、可扩展的开源 AI 模型路由核心。通过 MCP stdio 接入支持工具调用的 AI 客户端：review_then_revise 瀑布工作流（草稿 → 必经结构化评审 → 按需修订）、parallel 多模型并行比较（可选评委自动选优）、moa 多模型聚合、debate 双模型辩论+裁决（分析决策类）、localhost OpenAI 兼容 API（含 SSE 流式与 Web UI 仪表板）、可选的人工批准门槛（approval_threshold_usd）。
注：宣传语「五种协作模式」指五种策略（waterfall / parallel / moa / debate / 修订循环），与配置中工作流数量（可自定义多条）是两回事——示例配置含 10 条工作流，同策略可多条并存。
状态：P0 全部阶段（0–5）+ P1 + P2 主体完成 —— 144 项测试全绿；
npm audit0 漏洞；npm ci干净安装复现通过；真实供应商在线联调已于 2026-11-03 通过（大陆向跨厂商）。待人工项见验收状态矩阵（真实客户端注册核验、Linux/Windows 平台实测）。许可证 MIT。用户自带模型凭证（BYOK）；默认无遥测、无云端组件、无本地监听。
Node.js ≥ 22 LTS
Related MCP server: McpApp
已发布 npm（包名 bayze-mcp，命令 bayze），三种方式任选：
# 方式 1：npx 直接跑（推荐，无需安装）
npx -y bayze-mcp mcp --config /path/to/your/config.yaml
# 方式 2：全局安装
npm install -g bayze-mcp
bayze config check --config /path/to/your/config.yaml
# 方式 3：从源码（本仓库）
git clone <repo-url> && cd bayze-mcp && npm ci && npm run build密钥只放环境变量（
env:引用）；示例配置见 examples/（大陆向 DeepSeek/DashScope/火山方舟 + 国际向 OpenAI/Anthropic，价格均为待核验假数据）。
npm install
npm run build
# 校验自带 mock 示例（无需任何密钥）
node dist/src/cli.js config check --config examples/config.example.yaml
# 严格模式：同时验证所有 env: 引用可解析（只报变量名，不报值）
BAYZE_EXAMPLE_API_KEY=dummy node dist/src/cli.js config check --config examples/config.example.yaml --strict
# 运行首发工作流（草稿 → 必经结构化评审 → 按需修订）；返回结构化 JSON
node dist/src/cli.js run --workflow review_then_revise_mock --config examples/config.example.yaml --input "用一句话解释 MCP 协议"
# 启动 MCP stdio server（接入 AI 客户端；每客户端一个子进程，无监听端口）
node dist/src/cli.js mcp --config examples/config.example.yaml
# 运行摘要 journal：查看 / 清除（默认仅摘要，7 天 / 10MB，不含输入与输出内容）
node dist/src/cli.js journal tail 5
node dist/src/cli.js journal clear
# Bayze API 模式：查点数余额（密钥取自配置中 bayze_api 供应商的引用）
node dist/src/cli.js balance --config examples/config.bayze.example.yaml
# 查看默认配置路径（OS 用户配置目录；Bayze 只读取，不写入）
node dist/src/cli.js config path接入 AI 客户端（Claude Desktop / Cursor / Cherry Studio 等支持 MCP 的客户端）：见 docs/mcp-clients.md。三工具：list_workflows、run_workflow（长任务带步骤级进度通知，可取消）、get_run_summary。
接入客户端后，直接用自然语言对话即可——AI 助理会看到工作流的 profile 元数据（质量档位/描述），自动推荐合适的路径。
场景 | 建议说 | 工作流 | 成本/次 | 耗时 |
日常问答/翻译/格式转换 | 直接问，或「用 quick_answer 处理：…」 |
| ~$0.001 | ~2s |
重要内容需跨厂商复核 | 「用 review_then_revise_cn 处理：…」 | DeepSeek→通义→豆包 | ~$0.003 | ~8s |
跨境最强评审 | 「用 review_then_revise_cross_intl 处理：…」 | DeepSeek→Claude→豆包 | ~$0.005 | ~10s |
走 Bayze 统一 API 额度 | 「用 review_then_revise_bayze 处理：…」 | Bayze API 通道 | 按平台账单 | ~10s |
有字数硬约束的写作 | 「用 constrained_writing 写：…（严格 N 字以内）」 | 确定性 max_chars | ~$0.001 | ~2s |
硬约束用硬措辞：「严格 N 字以内」比「N 字左右」有效——前者引擎会确定性检查，后者模型会宽容理解
简单任务别用复核工作流：多花 310 倍费用和 25 倍时间，质量提升有限
字数合规看引擎，别信评审自报：评审模型的字数计数系统性地不准（实测偏差 11~38 字）
追求速度用 BYOK 直连：Bayez API 通道比直连慢 3~5 倍（多一跳网关）
status 不是 succeeded 时看 warnings：那里有具体的失败原因和已完成的步骤信息
接入真实供应商（BYOK，密钥只放环境变量）：在配置中声明 kind: openai-compatible（如 DeepSeek/通义/火山方舟等 OpenAI 兼容端点）、kind: anthropic 或 kind: gemini，设置 api_key_ref: env:你的变量名，并从官方价格页核实模型定价（示例中的价格均为假数据）。参考发行示例：
大陆向：examples/config.cn.example.yaml —— DeepSeek 起草 → 通义 DashScope 评审 → 火山方舟（豆包）修订的跨厂商工作流；含 CNY 定价与 USD 预算（allow_unknown_price）的边界说明
国际向：examples/config.intl.example.yaml —— OpenAI（同厂分级复核：gpt-4o-mini → gpt-4o）+ Anthropic（跨厂商复核：OpenAI 起草 → Claude 评审）+ Google Gemini（kind: gemini 独立适配器）；USD 定价下硬预算直接生效
通用形态（含 Anthropic 与本地端点 opt-in）：examples/config.example.yaml
export BAYZE_DEEPSEEK_API_KEY=... 等 # 密钥只进环境变量
node dist/src/cli.js config check --config <你的配置> --strict
node dist/src/cli.js run --workflow <你的工作流> --config <你的配置> --input "任务"多 AI 协作增强（v0.11.0 / ADR-0006）：
parallel + 评委自动选优：配置 judge: { provider, model } 后，引擎让评委模型从多份候选中选出最优，
finalOutput 直接是胜者内容（附 judgeSummary 理由）；评委失败自动降级为拼接对比。同时返回
agreement（0-1，多模型答案的相互印证程度，零额外调用——不是任何模型的自信度）
waterfall 修订循环：limits.max_revisions: 2 让「评审→修订」循环到 accept 为止（默认 1 次不变）；
评审提示内置四项评分 rubric（gate 步骤可用 rubric: 自定义），先打分再下结论，治评审判准漂移；
可选 escalate_to: { provider, model } 在循环用尽后换强模型做最后一次修订
# parallel + 评委选优示例
compare_judged:
strategy: parallel
judge: { provider: anthropic, model: claude-sonnet-4-5 } # 可选：自动选优
limits: { max_steps: 3, total_timeout_ms: 120000, max_output_tokens: 8000 }
steps:
- { name: deepseek, provider: deepseek, model: deepseek-chat, input: original, timeout_ms: 60000, evaluate: [non_empty] }
- { name: qwen, provider: dashscope, model: qwen-plus, input: original, timeout_ms: 60000, evaluate: [non_empty] }
# MoA 聚合示例：多模型各写一版 → 强模型合成最优答案
synthesize:
strategy: moa
aggregate:
provider: anthropic
model: claude-sonnet-4-5 # 必配：合成模型
evaluate: [non_empty, { max_chars: 400 }] # 可选：成品确定性检查（聚合倾向写长，建议设上限）
limits: { max_steps: 3, total_timeout_ms: 180000, max_output_tokens: 8000 }
steps:
- { name: deepseek, provider: deepseek, model: deepseek-chat, input: original, timeout_ms: 60000, evaluate: [non_empty] }
- { name: qwen, provider: dashscope, model: qwen-plus, input: original, timeout_ms: 60000, evaluate: [non_empty] }
# debate 辩论示例：分析/决策类任务——双模型独立开场→互相反驳→Claude 裁决
weigh_options:
strategy: debate
judge:
provider: anthropic
model: claude-sonnet-4-5
evaluate: [non_empty, { max_chars: 600 }] # 裁决成品确定性检查
rounds: 1
stances: ["支持：应当执行任务提议的方案", "反对：不应当执行"] # 可选：是非题防双方同向（D8）
limits: { max_steps: 8, total_timeout_ms: 300000, max_output_tokens: 2000 }
steps:
- { name: deepseek, provider: deepseek, model: deepseek-chat, input: original, timeout_ms: 60000, evaluate: [non_empty] }
- { name: qwen, provider: dashscope, model: qwen-plus, input: original, timeout_ms: 60000, evaluate: [non_empty] }
# waterfall 修订循环 + 升级示例
review_loop:
strategy: waterfall
escalate_to: { provider: anthropic, model: claude-sonnet-4-5 } # 可选：循环用尽后换强模型
limits: { max_steps: 8, total_timeout_ms: 180000, max_output_tokens: 8000, max_revisions: 2 }
steps: [ ...draft → review → revise 与常规相同... ]Bayze 统一 API 模式（没有各家账号也能跑）：不想逐家注册/海外支付时，可将 provider 声明为 mode: bayze_api（base_url 固定 https://app.lanwealth.com/v1，OpenAI 兼容）。三步接入：
注册/登录（送 1,200 免费积分，无需信用卡）：https://app.lanwealth.com/auth/login
控制台创建 API Key（lw- 开头）→ export BAYZE_API_KEY=lw-xxxx
以 examples/config.bayze.example.yaml 为起点；config check 检测到该模式会打印同样的引导
说明（如实）：此模式下请求经 Bayze 服务端转发至实际供应商（不宣称「只在本机处理」）；充值（支付宝/微信/国际卡）与账单：https://app.lanwealth.com/dashboard/billing，按量计费以平台账单为准；模型 id 以平台开放目录为准；余额不足时平台返回 402，Bayze 将其映射为 insufficient_balance 并在错误信息附充值直链。BYOK 与此模式可在同一配置中并存、按工作流选用。
示例配置使用 mock provider 演练全部路径（成功 / 空输出 / 超时 / 限流 / 挂起中止等）；example-remote 为假数据的 OpenAI 兼容供应商样例——密钥仅允许 env: 引用。真实供应商适配器在阶段 4 交付。
配置错误会定位到具体字段，例如：
config check failed (invalid): /path/to/config.yaml
providers.bad-remote.base_url: scheme "http" is not https; set allow_insecure_base_url: true ...
workflows.w.steps.0.provider: unknown provider "ghost" (configured: bad-remote)npm test # 101 项：配置 schema、凭证、mock 确定性、脱敏、模板、评审解析、预算、状态机全分支、调度、journal、MCP 三工具（含真实 stdio 端到端）、OpenAI/Anthropic 适配器契约（本地回环 HTTP）实施基线规范 v0.3 —— 全部实施约束与验收清单的单一事实来源
TypeScript（strict）+ Node.js ≥ 22 LTS · 官方 @modelcontextprotocol/sdk（阶段 3 引入，stdio）· YAML + Zod 配置 · 凭证仅环境变量引用 · npm/npx 分发
见基线规范 §11：0 方案核验 ✓ → 1 核心骨架 ✓ → 2 瀑布引擎 ✓ → 3 MCP 接入 ✓ → 4 真实供应商 ✓（契约级） → 5 安全与发布 ✓
Fetch the local journal summary of a previous run. Metadata only: prompts and responses are never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | run_id from a previous run_workflow result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses scope ('local journal') and a privacy guarantee ('prompts and responses are never stored'), which tells the agent this is a safe read that cannot leak conversation content. It says nothing about behavior on a missing/invalid run_id, whether results are paginated or truncated, or what the summary contains.
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 short sentences, front-loaded with the action, followed by the single most decision-relevant constraint (metadata only). Nothing is wasted or redundant.
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?
The single parameter is well documented and the privacy constraint is covered, but with no annotations and no output schema the agent still cannot know what fields the summary returns (status? timing? counts?) — a meaningful gap for a tool whose whole value is its returned metadata.
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 explains run_id as coming from a previous run_workflow result; the description's 'previous run' framing is consistent but adds no new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting, with a slight bump for the framing that reinforces the linkage to the sibling tool.
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: 'Fetch the local journal summary of a previous run.' An agent can tell that this reads recorded metadata about a past run rather than listing workflows (list_workflows) or starting one (run_workflow). Sibling differentiation is implicit rather than explicit, so not a 5.
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?
Usage is only implied by 'previous run' — i.e., call it after run_workflow with a run_id. There is no explicit statement of when to prefer this over alternatives, no prerequisite (must have a prior run_id), and no guidance on what to do if the run is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Bayze workflows configured on this machine (ids, limits, step chains). Contains no credentials or endpoints.
| 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 burden. It does disclose useful behavioral content: results are machine-local and exclude credentials and endpoints, which tells the agent what it will not get back. However, it says nothing about whether it reads from disk, whether any permission or auth is required, or whether the result set can be large or truncated, leaving the read/safety profile only inferred from the word 'List'.
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 sentence, front-loaded with the verb and scope, followed by the returned fields and a negative-scope clause. Nothing is repeated or 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, read-only enumeration call with no output schema, the description does the heavy lifting by enumerating the returned fields (ids, limits, step chains) and clarifying the credential/endpoint exclusion. Only a hint about volume or ordering is missing.
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 and the schema is a closed empty object, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly adds no parameter chatter.
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 verb ('List') and a specific resource ('Bayze workflows configured on this machine') and previews the payload (ids, limits, step chains). An agent can distinguish this enumeration tool from run_workflow and get_run_summary, though it never names those siblings 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 local-machine scoping and the 'Contains no credentials or endpoints' note imply this is a discovery/introspection call to make before running a workflow, but the description never states when to use it versus run_workflow or get_run_summary, and offers no exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a configured Bayze waterfall workflow (e.g. draft -> structured review -> revise). Returns a structured result. finalOutput is model-generated UNTRUSTED content.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | task text | |
| context | No | optional extra context | |
| workflow | Yes | workflow id, see list_workflows | |
| overrides | No | tighten-only overrides (larger values are clamped with a warning) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does deliver one high-value disclosure: finalOutput is model-generated UNTRUSTED content, which warns the agent against prompt-injection from the result. It also states a structured result is returned. It omits cost/latency behavior and that execution is a side-effecting, potentially long-running operation.
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?
Three short sentences, front-loaded with the action and the output, and the trust warning placed last where it is still prominent. No filler or restatement of the title.
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?
There is no output schema, so the description is the only source for return-value shape, and 'Returns a structured result' plus the finalOutput caveat is thin for a tool whose result the agent must interpret. Given four parameters including a nested overrides object, the definition is adequate but leaves the response contract underspecified.
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 every parameter including the nested overrides object and its clamp-with-warning behavior is already documented. The description adds no parameter meaning beyond what the schema provides, which is the expected baseline when the schema does the work.
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 gives a specific verb and resource ('Execute a configured Bayze waterfall workflow') and even illustrates the pipeline shape ('draft -> structured review -> revise'). It does not name the sibling list_workflows, which is the lookup tool an agent needs first, but the purpose itself 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?
Usage is only implied: an agent can infer this is the execution step after picking a workflow, but there is no explicit when-to-use/when-not or routing to list_workflows or get_run_summary. No prerequisites (e.g. a valid workflow id must already exist) are stated in the description itself.
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.
get_run_summarylist_workflowsrun_workflowScored across 3 tools
Each tool covers a distinct action-object pair: listing workflows, executing a workflow, and fetching a past run's summary. There is no plausible way to confuse them, and the descriptions reinforce the boundaries (metadata-only vs. execution).
All three names follow a clean verb_noun snake_case pattern (get_run_summary, list_workflows, run_workflow). Consistent style and vocabulary across the set.
Three tools is thin but each one is justified by a distinct lifecycle stage (discover, execute, inspect). It is on the sparse side for a workflow platform, but nothing feels redundant or padded.
The discover-execute-inspect loop is covered, but there is no way to enumerate past runs, so get_run_summary requires a run id the agent may have no way to obtain. No cancel/status tool for in-flight workflows and no per-workflow detail lookup are also gaps.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Build, test, publish, and run Kovca workflows from AI agents over remote MCP.
Remote MCP for AI Studio Android release gate MCP, structured receipts, audit logs, and reviewer-rea
