Allows importing workflow templates into n8n for use in automation pipelines.
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., "@workflow-mcp Run the financial-report-analysis template for my company"
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.
Turn the AI workflow templates in the workflow-templates repository into MCP-callable tools — any MCP client (WorkBuddy, Claude Desktop, Cursor, etc.) can directly list templates, inspect contracts, execute templates, and get structured results.
Architect of digital pipelines · Fourth building block: make all pipelines "plug-and-play"
Tool | Description |
| List all available templates in the repository (version / description / executable or not) |
| View the template's input/output JSON Schema and processing pipeline (DAG) overview |
| Execute a template synchronously: JSON in, structured data + report out |
| Async execution (recommended): returns task_id immediately, runs in the background |
| Poll async task status (running / done / error) |
Example session:
1. list_templates → 发现 financial-report-analysis
2. get_template_info(模板id) → 拿到输入契约（需要 company_name / report_path / report_type）
3. run_template_async(模板id, json) → {task_id, status: running}
4. get_task_status(task_id) → 轮询至 done，返回指标 + 风险信号 + 报告Why the async version is needed: clients like WorkBuddy / Claude Desktop impose request timeout limits on individual tool calls, while real template execution (multiple LLM calls) usually takes 1-2 minutes, so synchronous calls time out. The async version avoids this limitation.
Related MCP server: MCP Boilerplate
MCP 客户端（WorkBuddy / Claude Desktop / ...）
│ stdio / streamable-http
┌───────▼───────────────┐
│ server.py (FastMCP) │ list / get / run 三个工具
└───────┬───────────────┘
┌───────▼───────────────┐
│ templates_registry.py │ 扫描 workflow-templates，读取契约元数据
│ runner.py │ 子进程执行模板 run.py（--auto-review 自动化复核）
└───────┬───────────────┘
│
┌───────▼───────────────┐
│ workflow-templates │ 模板仓库：契约 + 提示词 + 脚本（数据权威）
└───────────────────────┘Key design decisions:
The template repository remains the single source of truth: adding or modifying templates only requires changing workflow-templates; this service needs zero changes
Automated review: run.py adds an --auto-review flag; when MCP executes automatically, it skips human interaction, and the output is marked with review_note for the caller to verify key figures
Execution isolation: each run writes a temporary input file (deleted after use), and output is persisted to the template's output/
pip install -e .
python -m workflow_mcp.server # stdio（默认）
python -m workflow_mcp.server --transport streamable-httpPrerequisites: the workflow-templates repository is on this machine at E:\NEMB\workflow-templates (can be overridden with the WORKFLOW_TEMPLATES_HOME environment variable); the template's own .env (e.g., OpenRouter API key) is loaded by run.py itself.
End-to-end test (will actually run the financial report analysis template once):
python examples/client_test.py # stdio 协议方式
python examples/inproc_test.py # 进程内客户端方式（CI / 沙箱环境更稳）Merge examples/workbuddy_mcp.json into mcpServers in C:\Users\33033\.workbuddy\mcp.json, then click "Trust" on workflow-mcp in the connector management page to enable it. After that, you can simply say "run the financial report analysis template for me" in a conversation.
Repository | Role | Position in the MCP ecosystem |
workflow-templates | Template repository (content authority) | Wrapped as tools by workflow-mcp |
workflow-mcp | Template executor (this service) | Brainpower pipeline MCP |
digital-twin-mcp | Device data MCP | Device data pipeline MCP |
factory-twin-viz | Visualization frontend | Consumes any MCP data |
v0.1: list / get / run three tools + --auto-review (current)
v0.2: persist template outputs to a database (traceable results), concurrent execution queue, n8n template import
v0.3: combine with digital-twin-mcp into a "device health report" template (data pipeline × brainpower pipeline)
MIT License
查询异步任务状态：running / done / error；done 时返回完整结果（同 run_template 返回结构）。
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a useful state machine (running/done/error) and that 'done' yields the full run_template-shaped result, which is genuine beyond-schema information. However, it says nothing about result retention, whether the task record expires after completion, or polling expectations.
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?
One compact sentence, front-loaded with the action and the state list, with the payload note trailing. Nothing is redundant and nothing needs trimming.
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?
An output schema exists, so return-value detail is not required, and the description usefully adds that the done-result matches run_template. What is missing for a polling tool is the operational context: how the task_id is obtained and whether/how results expire.
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 0% and the single task_id parameter is undocumented in both schema and description. The description implies task_id comes from the async run flow, but does not state its origin or format explicitly, so it only partially compensates for the coverage gap.
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 the specific verb+resource ('query async task status') and enumerates the three possible states, which makes the tool's job unambiguous. It also ties the 'done' payload back to run_template's return structure, hinting at the async workflow. It stops short of explicitly naming run_template_async as the producer of the task_id.
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: the phrase 'async task status' plus the sibling set (run_template_async) makes the polling role inferable, but there is no explicit 'call this after run_template_async', no indication of when to stop polling, and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看模板的契约：输入/输出 JSON Schema、处理流水线（DAG）概要。
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes |
| Name | Required | Description |
|---|---|---|
No output 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 implies a read-only 'view' operation and describes returned contract components, but does not state permission requirements, whether the operation is safe, or any rate/caching behavior. For a metadata retrieval tool with zero annotation coverage, this is a notable 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?
A single front-loaded sentence that states the resource and enumerates the returned contract components without any filler. Every phrase 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?
An output schema exists, so the description need not detail return values, and it does name the main return components (I/O schemas, DAG overview). However, it omits usage guidance and parameter semantics, leaving enough gaps that the definition is only minimally viable for an agent deciding when and how to call it.
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 0% for the single required parameter template_id, and the description does not mention or explain it at all. The parameter name is self-evident enough to avoid a score of 1, but the description adds no semantic value beyond what the schema already exposes.
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 and resource: '查看模板的契约' (view a template's contract), and enumerates what the contract includes (input/output JSON Schema, DAG overview). This clearly distinguishes it from list_templates and run_template in meaning, though it does not explicitly name or contrast with those siblings.
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 says what the tool returns but gives no guidance on when to use it versus list_templates or run_template. There are no preconditions, no when-not-to-use notes, and no mention of alternatives, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出 workflow-templates 仓库中所有可用的工作流模板（含版本、描述、是否可执行）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the returned fields (version, description, executability), implying a safe read-only listing, but never states absence of side effects, permissions, or ordering/pagination behavior.
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 front-loaded sentence that names the scope and the useful output fields with zero filler. Every clause 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?
An output schema exists and covers return values, so the description need not explain them; for a zero-parameter read tool this is nearly complete, with only the sibling-routing guidance 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, so the schema-heavy baseline of 4 applies; there is nothing to disambiguate and the description correctly adds no parameter noise.
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 ("工作流模板"), scoped to the workflow-templates repository. It clearly differs from get_template_info (single template detail) by being a repository-wide enumeration, though it never names that sibling 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?
Usage is only implied: the enumeration framing suggests calling this before drilling into a specific template, but the description gives no explicit when-to-use guidance or reference to get_template_info as the follow-up. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行指定工作流模板。input_json 为符合该模板输入契约的 JSON 字符串（如财报分析模板需 company_name / report_path / report_type）。
返回：success、data（结构化输出，含 human_review_required 标记）、report（报告文本）、artifacts（落盘路径）。 注意：自动化执行会标记 review_note，请调用方核验关键数字。 长耗时模板（如含多次 LLM 调用）在带请求超时限制的客户端下请改用 run_template_async。
| Name | Required | Description | Default |
|---|---|---|---|
| input_json | Yes | ||
| template_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does reasonably well: it warns that automated runs set a review_note and that callers must verify key figures, and it discloses the async fallback for timeout-bound clients. It says nothing about permissions, idempotency, or cost/side effects of template execution, which keeps it out of the top band.
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?
Front-loaded with the action, then parameter contract, then return fields, then cautions and the async escape hatch. Every block earns its place, though the return-field enumeration partly duplicates the output schema.
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 an output schema exists, the return-value summary is redundant but harmless; the important additions (review_note caveat, timeout/async routing, input_json contract) are all present. Only minor gaps remain, such as template_id semantics and any authorization requirements.
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 0%, so the description must compensate, and it does for input_json: it explains the parameter is a JSON string conforming to the template's input contract and gives a worked example (company_name / report_path / report_type). template_id is left unexplained, keeping it short of a 5.
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+resource ('执行指定工作流模板' – execute the specified workflow template) that is immediately distinguishable from the read-only siblings list_templates/get_template_info. It also hints at the async sibling, though without formally naming it as the alternative for a distinct use case.
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?
Explicitly names the condition that should route the agent elsewhere: long-running templates (multiple LLM calls) under clients with request timeouts should use run_template_async instead. That is a concrete when-to-use-other rule, though there is no inverse statement of when run_template is the right choice beyond the implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
异步执行指定模板：立即返回 task_id，执行在后台进行，用 get_task_status 轮询结果。
适用场景：WorkBuddy / Claude Desktop 等客户端对单次工具调用有请求超时限制， 而模板真实执行（多次 LLM 调用）可能超过该限制。
| Name | Required | Description | Default |
|---|---|---|---|
| input_json | Yes | ||
| template_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers the essential trait: execution is asynchronous, control returns immediately with a task_id, and results must be retrieved by polling. It does not cover permission/auth requirements or any rate limits, so it is strong but not complete.
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?
Front-loaded with the core async contract in the first clause, followed by the polling instruction and the scenario rationale. Every sentence earns its place with 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?
An output schema exists, so return values need not be described, and the async/polling model is well covered. However, with zero schema description coverage the description should at least sketch the shape of input_json; that omission leaves a real gap for correct invocation.
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 0% for two required parameters, so the description must compensate and does not. Neither template_id nor the free-form input_json string (presumably a serialized inputs object) is explained, leaving the agent to guess the expected format of input_json.
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+resource ('异步执行指定模板') and immediately clarifies the differentiating behavior: it returns a task_id rather than the result. This cleanly distinguishes it from the sibling run_template (synchronous execution) without the agent needing to open either schema.
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?
Explicitly names the alternative ('用 get_task_status 轮询结果') and gives a concrete when-to-use scenario (client request timeouts where multi-LLM-call execution exceeds the limit). It does not explicitly state the inverse case ('use run_template for short/fast templates'), so the routing logic is clear but not fully spelled out.
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.
v0.1.0get_task_statusget_template_infolist_templatesrun_templaterun_template_asyncScored across 5 tools
Each tool targets a distinct operation: list_templates (enumerate), get_template_info (inspect contract), run_template (sync execute), run_template_async (async execute), get_task_status (poll). The sync/async pair is clearly differentiated by explicit timeout guidance in the descriptions, so no realistic misselection.
All names follow a clean verb_noun snake_case pattern (list/get/run/get). Minor inconsistency: list_templates uses a plural noun while get_template_info uses singular, and 'info'/'status' suffixes differ slightly, but this is readable and predictable.
Five tools is well-scoped for a template-consumer/executor server, with each tool earning its place (discovery, inspection, sync exec, async exec, polling). No redundant or filler tools.
Covers the full discover-inspect-execute-monitor lifecycle, including an async path for long-running templates. Minor gap: no cancel/abort operation for a running async task, which could strand agents waiting on a hung task.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
