The oflow-mcp server is an Agent-native workflow kernel that lets AI agents define, start, execute, and manage text-based workflows with checkpointing, branching, and verifiable step progression.
Template Management
workflow_list_templates — Discover all available workflow templates
workflow_get_template — Retrieve full details and step summaries for a specific template
workflow_create_template — Define and persist a new workflow template with name, description, parameters, steps, and per-step prompts
workflow_validate_template — Check templates for common issues
Instance Management
workflow_start — Instantiate a workflow from a template with required parameters and an optional alias
workflow_list_instances — Browse instances filtered by status (active/completed/all) or template name
workflow_status — View full instance state including step history, outputs, and checkpoint status
workflow_bind — Attach a human-friendly alias to a workflow instance ID
Execution & Interaction
workflow_current — Retrieve the current step and its rendered prompt for an active instance
workflow_advance — Complete the current step by submitting outputs, confirmed conditions, branch keys, and token consumption, then move to the next step
workflow_override_prompt — Replace the prompt for a specific step within an instance without affecting the original template
Observability & Coordination
workflow_events — Query event logs with filtering and summaries
workflow_dashboard — Get a dashboard with checkpoint blockers, risk indicators, and suggested actions
workflow_worklog — Generate a Markdown worklog for audit or handoff
workflow_inbox_save/list/mark — Manage local inbox entries for agent coordination
Click on "Install 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., "@oflow-mcp list available workflow templates"
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.
Agent-native workflow kernel. 工作流不必只能是 Dify、n8n 或扣子。
oflow-mcp is a workflow-only MCP server. It treats workflow as an open execution protocol for AI Agents: text-defined, versionable, checkpointed, recoverable, and callable through MCP tools.
Traditional workflow platforms often center on visual canvases, proprietary node graphs, and hosted platform state. oflow-mcp starts from a different premise:
Agent native: prompts, outputs, checkpoints, and step state are first-class workflow concepts.
Text is the source of truth: workflows are flow.yaml + prompts/*.md, so they can be reviewed, diffed, versioned, and reused.
Verifiable execution: each step can require outputs, natural confirmations, deterministic checks, and persisted state.
Local-first kernel: the first version runs on MCP + filesystem; UI, connectors, triggers, remote execution, and enterprise governance can layer on top later.
Replacement path, not a plugin: the long-term goal is to replace the core capabilities of general workflow tools such as Dify, n8n, and Coze/扣子, starting with the execution kernel.
Related MCP server: agentloop
This first release intentionally excludes:
TAPD, Confluence, GitLab, CI, or IM integrations
memory, inbox, init, or instructions tools from flow-mcp
visual canvas UI
database storage
multi-tenant permissions
npm install
npm run buildnpm startMCP configuration example:
{
"mcpServers": {
"oflow-mcp": {
"command": "node",
"args": ["/path/to/oflow-mcp/dist/index.js"],
"env": {
"OFLOW_MCP_FLOWS_DIR": "/path/to/oflow-mcp/flows",
"OFLOW_MCP_DATA_DIR": "/tmp/oflow-mcp-instances"
}
}
}
}Variable | Default | Description |
|
| Base data directory |
|
| Workflow template directory |
|
| Workflow instance directory |
oflow-mcp exposes only workflow tools:
Tool | Description |
| List available templates |
| Get template details |
| Start a workflow instance |
| Get current step and rendered prompt |
| Complete current step and advance |
| Show full instance status |
| List instances |
| Bind alias to an instance |
| Override one step prompt for one instance |
| Create a template from YAML-like data and prompts |
| Query append-only event log by instance/type/step/limit |
| Show Agent control-plane state, checkpoint blockers, inbox summary, and suggested actions |
| Generate a Markdown worklog from instance state and events |
| Save lightweight inbox entries for an instance |
| List lightweight inbox entries |
| Mark inbox entries as |
| Report template health issues such as unreachable steps and invalid prompt references |
No flow_memory_*, flow_init, TAPD, or Confluence tools are exposed. workflow_inbox_* is a local lightweight inbox for workflow control-plane coordination; it does not call external systems.
flows/
basic-dev/
flow.yaml
prompts/
analyze.md
design.md
verify.mdMinimal flow.yaml:
name: basic-dev
description: Minimal Agent-native development workflow
params:
change_name:
type: string
required: true
steps:
- id: analyze
name: Analyze
checkpoint:
required_outputs:
analysis_summary:
type: string
min_length: 20
optional_outputs:
risk_notes:
type: string
evidence:
- key: test_log
required: true
description: Test log or command output
approvals:
- key: user_confirmed
required: false
description: User approval when needed
conditions:
- natural: analysis_summary has been produced
check: outputs.analysis_summary != null AND len(outputs.analysis_summary) > 20
next: design
- id: design
name: Design
next: nullPrompt variables:
{{change_name}} reads workflow params.
{{steps.analyze.outputs.analysis_summary}} reads prior step outputs.
Unresolved variables are left unchanged for debugging.
Feature | Status |
| Supported |
| Supported |
| Supported |
| Supported |
| Supported |
natural conditions | Supported |
deterministic | Supported subset |
| Supported |
loops | Not supported in first release |
optimization hints | Not supported |
worklog generation | Supported through |
local inbox | Supported through |
memory/external bindings | Not supported |
Supported check expressions:
outputs.foo != null
outputs.foo == null
outputs.foo == 'value'
len(outputs.foo) > N
AND, OR, parentheses
Unsupported expressions fail closed and do not mutate workflow state.
workflow_events accepts:
{
"instance_id": "wf_...",
"type": "step.completed",
"step_id": "verify",
"since": "2026-06-23T00:00:00.000Z",
"until": "2026-06-24T00:00:00.000Z",
"only_failures": false,
"include_payload": false,
"summary": true,
"limit": 50
}limit defaults to 50 and is capped at 200. Malformed JSONL audit lines are skipped so one bad event does not hide the rest. Payloads are omitted by default; use summary=true for safe payload summaries or include_payload=true for full payloads.
workflow_dashboard accepts:
{
"instance_id": "wf_...",
"include_prompt": true,
"include_recent_events": true,
"include_inbox": true,
"verbose": false
}The dashboard reports progress, risk, checkpoint readiness, and structured suggested_actions with action_type, title, reason, tool_hint, and risk. It summarizes outputs with keys and short previews rather than returning full output payloads.
workflow_worklog returns { "markdown": "...", "summary": { ... } }. It supports mode: "summary" | "full" | "handoff" | "release_note" and optional write_file; when writing, paths are resolved under OFLOW_MCP_DATA_DIR. The generated Markdown includes step timeline, output summaries, validation failures, and current state.
workflow_inbox_save/list/mark stores local coordination items under OFLOW_MCP_DATA_DIR/inbox/<instance_id>.json. Entries support priority: "low" | "medium" | "high" | "blocking" and optional step_id; dashboard risk aggregates high/blocking items. Deduplication uses external_id first; otherwise it uses source + type + title + date. These tools do not call Git, CI, TAPD, IM, or review systems.
workflow_validate_template returns { "valid": boolean, "errors": [], "warnings": [] } for control-plane health checks including unreachable steps, invalid checkpoint expressions, undeclared prompt params, missing step references, duplicate evidence/approval keys, empty conditions, unused prompts, branch shape warnings, and missing descriptions. Issues include severity and suggestion when available.
The workflow kernel includes the first P0/P1 hardening batch:
Template names, step ids, instance ids, and aliases are validated before file access.
Template, instance, and event paths are resolved inside their configured base directories to prevent path traversal.
Instances carry a version field and state writes use optimistic locking to reject stale saves.
Running instances store template_snapshot and prompt_snapshots, so later template edits do not change in-flight workflow semantics.
Key runtime transitions are appended to events/<instance_id>.jsonl for audit/debug.
Prompt, outputs, and instance payload sizes are bounded.
workflow_status returns output keys and short previews rather than full outputs by default.
Tool responses are JSON envelopes: { "ok": true, "data": ... } or { "ok": false, "error": ... }.
workflow_list_templates
workflow_start:
{
"template": "basic-dev",
"params": { "change_name": "demo" },
"alias": "demo-run"
}workflow_current with demo-run
workflow_dashboard to inspect blockers and suggested actions
workflow_advance with required outputs, confirmed conditions, and any required evidence/approvals
workflow_events or workflow_worklog for audit/debug
Continue workflow_advance until completed
npm install
npm run build
npm testTemplate not found: set OFLOW_MCP_FLOWS_DIR or copy templates to ~/.oflow-mcp/flows.
Prompt not found: every step requires prompts/<step_id>.md.
Checkpoint validation failed: provide required outputs, confirmed conditions, and any required evidence/approvals. The error envelope may include details.missing_required, details.missing_evidence, details.missing_approvals, and details.suggestions.
No branch matched: pass a condition_result matching the branch keys in next.
Alias already bound: choose another alias or use the existing instance ID.
Complete the current step and advance the workflow after checkpoint validation.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes | Instance ID or alias | |
| outputs | Yes | Step outputs | |
| confirmed_conditions | No | Confirmed natural-language checkpoint conditions | |
| condition_result | No | Branch key for conditional next routing | |
| token_consumed | No | Tokens consumed by this step |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'checkpoint validation' but does not disclose behaviors such as error handling on validation failure, required permissions, idempotency, or whether it is destructive. The description is too brief for a safe understanding.
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, well-structured sentence with no unnecessary words. It is front-loaded with the main action.
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 5 parameters (especially optional ones like condition_result, token_consumed) and no output schema or annotations, the description is incomplete. It does not explain the concept of checkpoint validation, how optional params affect behavior, or what happens after advancement.
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 baseline is 3. The description adds no extra meaning beyond the schema names and descriptions. It does not explain how parameters like 'outputs' or 'confirmed_conditions' are used in context.
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 clearly states what the tool does: 'Complete the current step and advance the workflow after checkpoint validation.' It uses specific verbs (complete, advance) and resource (workflow step), and distinguishes from siblings like workflow_start and workflow_status.
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 when a workflow step is ready for checkpoint validation and advancement, but provides no explicit guidance on when to use this tool versus alternatives like workflow_bind or workflow_start. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bind an alias to a workflow instance.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes | Instance ID | |
| alias | Yes | Alias to bind |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like whether binding overwrites existing aliases, if it requires special permissions, or if it is destructive. None of this is mentioned.
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 wasted words. It conveys the primary action effectively.
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 the lack of output schema and annotations, the description is too minimal. It does not explain return values, error behavior, or how binding affects the workflow instance, leaving the agent underinformed.
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% with descriptions for both parameters. The description adds no additional meaning beyond what the schema already provides, meeting the baseline but not exceeding it.
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 'Bind an alias to a workflow instance' specifies a clear verb (bind) and resource (alias to workflow instance), distinguishing it from sibling operations like workflow_start or workflow_advance.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workflow template by writing flow.yaml and prompts/*.md.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name | |
| description | Yes | Template description | |
| params | Yes | Parameter definitions | |
| steps | Yes | Workflow steps | |
| prompts | Yes | Step prompts keyed by step id | |
| token_budget | No | Optional token budget | |
| overwrite | No | Overwrite existing template |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It hints at the creation process but omits effects, auth needs, destructive potential, or whether existing templates can be overwritten despite the overwrite parameter.
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 sentence with a clear front-loaded verb and resource. It is concise but could benefit from slightly more structure (e.g., listing key parameters or behavior).
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 description is too brief given the tool's complexity: 7 parameters, 5 required, nested objects, and no output schema. It lacks information on return values, side effects, or the process of creating the template.
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 explains all 7 parameters. The description adds no additional meaning or examples beyond the schema.
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 the verb 'Create', the resource 'workflow template', and the method 'by writing flow.yaml and prompts/*.md', which clearly distinguishes it from sibling tools like workflow_list_templates or workflow_get_template.
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?
No guidance is provided on when to use this tool versus alternatives, such as workflow_bind or workflow_start. It lacks context on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current workflow step and rendered prompt. ID may be an instance id or alias. If omitted, uses the most recently active instance.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | No | Instance ID or alias |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates the tool reads data (retrieves step and prompt) but does not cover edge cases like invalid IDs, inactive instances, or potential side effects. The mention of 'most recently active' is helpful but not comprehensive.
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 extremely concise at two sentences, with no unnecessary words. The first sentence states the purpose, and the second provides parameter guidance, both front-loaded and efficient.
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 description lacks an output schema and does not detail the return structure (e.g., format of the step, whether the prompt is a string or object). Given the tool's simplicity (1 optional param, no output schema), the description is incomplete, leaving the agent uncertain about the response format.
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 schema covers 100% of parameters with a description for 'instance_id' ('Instance ID or alias'). The tool description adds value by explaining that the parameter is optional and defaults to the most recently active instance, which is not clear from the schema alone.
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 clearly states the tool retrieves 'current workflow step and rendered prompt', specifying the action and resource. This distinguishes it from sibling tools like workflow_advance (which moves forward) and workflow_start (which initiates a workflow).
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 explains that the instance ID is optional and defaults to the most recently active instance, providing clear guidance on invocation. However, it does not explicitly state when not to use this tool versus alternatives, such as when a specific step is needed or when the instance is inactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workflow template details and step summary.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description barely covers behavior: it mentions 'details and step summary' but doesn't clarify read-only nature, required permissions, or output format.
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?
Single concise sentence with no redundant information. Front-loaded with the main action.
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?
Adequate for a simple getter with one parameter, but lacks detail on return values (no output schema). Incomplete for an agent to fully understand what 'details and step summary' means.
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 covers 100% of parameter documentation. Description adds no extra meaning beyond the parameter name and type already described in the schema.
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?
Description clearly states it retrieves workflow template details and step summary. Distinct from sibling tools like workflow_list_templates and workflow_create_template.
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?
Implied usage for getting details of a specific template, but no explicit when-to-use or when-not-to-use, nor comparison with alternatives like workflow_list_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflow instances, optionally filtered by status and template.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Instance status filter | |
| template | No | Template filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose key behavioral traits such as read-only nature, pagination, rate limits, or default behavior (e.g., 'all' status). The word 'List' implies read-only but is not explicit, and no other behaviors are mentioned.
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 wasted words. It efficiently conveys the core purpose and optional filters.
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 the simplicity (2 optional params, no output schema), the description is too sparse. It omits details like return format, ordering, pagination, or the default status behavior (e.g., what happens if neither filter is provided).
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 description adds no extra meaning beyond restating the optional filters. Baseline is 3 since the schema already documents both parameters adequately.
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 clearly states the verb 'List' and resource 'workflow instances', with optional filters (status and template). It distinguishes from sibling tools like workflow_advance and workflow_start by specifying the list operation uniquely.
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 provides clear context for when to use the tool (listing instances with optional filters) but lacks explicit guidance on when NOT to use it or comparison to alternatives like workflow_status (which might show single instance status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available workflow templates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It only mentions 'list', implying a safe read operation, but fails to disclose any quirks, authentication requirements, or whether the list is complete. Minimal behavioral insight.
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 (4 words) that is front-loaded with the key action and resource. No wasted text.
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 no output schema and no parameters, the description is minimal but adequate for a simple listing. However, it could mention what is returned (e.g., template names or IDs) to set expectations better.
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?
With zero parameters, the schema is fully covered (100%). The description doesn't need to add param details. Baseline 4 is appropriate as it adds no confusion.
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 clearly states it lists available workflow templates, using a specific verb ('list') and resource ('workflow templates'). This distinguishes it from siblings like workflow_create_template (create) and workflow_get_template (get specific).
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 use when you need to see all templates, but lacks explicit guidance on when not to use it or how it compares to alternatives like workflow_get_template for individual retrieval. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Override a step prompt for one workflow instance only.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes | Instance ID or alias | |
| step_id | Yes | Step ID | |
| prompt | Yes | Prompt markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits beyond the vague 'Override', such as whether changes are persistent, reversible, or affect shared templates.
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, concise sentence that immediately communicates the core action and scope, with no superfluous words.
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?
Does not explain the effect of overriding (e.g., temporary vs permanent, impact on original template), leaving agents without crucial context for safe execution.
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%, so baseline is 3. The description adds no extra meaning beyond the schema parameter descriptions, which are already present.
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 clearly states the verb 'Override', the resource 'step prompt', and the scope 'for one workflow instance only', effectively distinguishing it from siblings like workflow_start or workflow_status.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, when-not-to-use, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a workflow instance from a template.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template name | |
| params | Yes | String workflow parameters | |
| alias | No | Optional instance alias |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states it starts an instance but omits details about side effects, permissions, error handling, or irreversible actions.
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. It is concise and gets straight to the point, though it could benefit from slightly more detail without losing conciseness.
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 the lack of output schema and annotations, the description is incomplete. It does not explain return values, error cases, or practical usage considerations for a potentially significant 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?
Schema coverage is 100% with basic descriptions for each parameter. The description adds no additional context beyond the schema, meeting the baseline of 3 for high coverage.
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 clearly states the action (start) and the resource (workflow instance from a template). It distinguishes itself from sibling tools like workflow_advance, workflow_bind, etc., which have different purposes.
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 provides no guidance on when to use this tool versus alternatives. For example, it does not mention prerequisites or scenarios where starting a workflow is appropriate vs. other workflow actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show full workflow instance status.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes | Instance ID or alias |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose read-only nature, authorization needs, or side effects. The description only states the action, lacking transparency about 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?
Extremely concise single sentence, front-loaded with key information. However, it could be slightly more descriptive without being wasteful.
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 the simplicity (1 param, no output schema), the description is minimal. It does not explain what constitutes 'full status' or what the output format is, leaving ambiguity. For a tool with siblings, this incompleteness could mislead.
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% for the single parameter; the schema already describes 'instance_id' as 'Instance ID or alias'. The description adds no additional meaning beyond the schema, meeting baseline.
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 clearly states the action ('Show') and resource ('full workflow instance status'). It distinguishes from siblings like workflow_list_instances (lists instances) and workflow_current (likely current workflow context), so purpose is clear, though 'full' could be more specific.
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?
No guidance on when to use this tool versus alternatives like workflow_current or workflow_list_instances. The description does not mention prerequisites or exclusions.
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. Dates show when Glama detected each change.
v0.1.0workflow_advanceworkflow_bindworkflow_create_templateworkflow_currentworkflow_get_templateworkflow_list_instancesworkflow_list_templatesworkflow_override_promptworkflow_startworkflow_statusEach tool targets a distinct operation: creation, starting, advancing, binding, querying, and overriding. No two tools have overlapping purposes.
All tools use the consistent 'workflow_verb_noun' pattern in snake_case, making the purpose clear and predictable.
With 10 tools, the surface is well-scoped for managing workflow templates and instances, covering all essential operations without unnecessary bloat.
Core CRUD and lifecycle operations are present (create, start, advance, status). Missing delete or stop operations for templates/instances is a minor gap, but the main workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Cloudflare Workers MCP server: agent-workflow-engine
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/openpeng/oflow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server