workflow-templates 저장소의 AI 워크플로 템플릿을 MCP 호출 가능 도구로 만듭니다. 모든 MCP 클라이언트(WorkBuddy, Claude Desktop, Cursor 등)가 템플릿을 직접 나열하고, 계약을 조회하며, 템플릿을 실행해 구조화된 결과를 얻을 수 있습니다.
디지털 파이프라인의 설계자 · 네 번째 블록: 모든 파이프라인을 "플러그 앤 플레이"로
도구 | 설명 |
| 저장소 내 모든 사용 가능한 템플릿 나열(버전 / 설명 / 실행 가능 여부) |
| 템플릿의 입력/출력 JSON Schema 및 처리 파이프라인(DAG) 개요 조회 |
| 템플릿 동기 실행: JSON 입력, 구조화된 데이터 + 보고서 출력 |
| 비동기 실행(권장): 즉시 task_id 반환, 백그라운드 실행 |
| 비동기 작업 상태 폴링(running / done / error) |
예시 세션:
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，返回指标 + 风险信号 + 报告비동기 버전이 필요한 이유: WorkBuddy / Claude Desktop 등 클라이언트는 단일 도구 호출에 요청 타임아웃 제한이 있습니다. 그런데 템플릿의 실제 실행(여러 번의 LLM 호출)은 보통 1~2분이 걸리므로, 동기 호출은 타임아웃됩니다. 비동기 버전은 이 제한을 우회합니다.
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 │ 模板仓库：契约 + 提示词 + 脚本（数据权威）
└───────────────────────┘핵심 설계:
템플릿 저장소를 단일 진실 원천으로 유지: 템플릿 추가/수정은 workflow-templates만 변경하면 되고, 본 서비스는 변경할 필요 없음
자동 검증: run.py에 --auto-review 인자 추가. MCP 자동 실행 시 수동 개입을 건너뛰고, 출력에 review_note 표시를 포함해 호출 측이 핵심 수치를 검증
실행 격리: 실행마다 임시 입력 파일을 생성(사용 후 삭제), 출력은 템플릿의 output/에 저장
pip install -e .
python -m workflow_mcp.server # stdio（默认）
python -m workflow_mcp.server --transport streamable-http전제 조건: workflow-templates 저장소가 로컬 E:\NEMB\workflow-templates에 있어야 함(환경 변수 WORKFLOW_TEMPLATES_HOME으로 덮어쓸 수 있음). 템플릿에 포함된 .env(예: OpenRouter 키)는 run.py가 자동으로 로드합니다.
엔드투엔드 테스트(재무 분석 템플릿을 실제로 한 번 실행함):
python examples/client_test.py # stdio 协议方式
python examples/inproc_test.py # 进程内客户端方式（CI / 沙箱环境更稳）examples/workbuddy_mcp.json을 C:\Users\33033\.workbuddy\mcp.json의 mcpServers에 병합하고, 커넥터 관리 페이지에서 workflow-mcp에 대해 「신뢰」를 클릭하여 활성화합니다. 이후 대화에서 바로 "재무 분석 템플릿 실행해줘"라고 말하면 됩니다.
저장소 | 역할 | MCP 생태계에서의 위치 |
workflow-templates | 템플릿 저장소(콘텐츠 표준) | workflow_mpc가 도구로 래핑mcp |
workflow-mcp | 템플릿 실행기(본 서비스) | 지식 노동 파이프라인 MCP |
digital-twin-mcp | 장치 데이터 MCP | 장치 데이터 파이프라인 MCP |
factory-twin-viz | 시각화 프런트엔드 | 임의 MCP 데이터 소비 |
v0.1: list / get / run 세 가지 도구 + --auto-review(현재)
v0.2: 템플릿 출력 DB 저장(결과 추적 가능), 동시 실행 큐, 실행 n8n 버전 템플릿 가져오기
v0.3: digital-twin-mcp와 결합한 "장치 건강 보고서" 템플릿(데이터 파이프라인 × 지식 노동 파이프라인)
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.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
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
