Workflow
Server Details
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Jonnyton/Workflow
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.2/5 across 5 of 5 tools scored. Lowest: 2.6/5.
Each tool has a distinct resource (graph/page) and action (read/run/write), with no overlap or ambiguity.
All tools follow a consistent verb.resource pattern with lowercase and dot separation, making them easily predictable.
Five tools is well-scoped for a workflow server, covering the essential operations without being too few or too many.
The set covers read, write, and run for graphs and pages, but lacks explicit delete operations, which is a minor gap.
Available Tools
5 toolsread.graphRead GraphBRead-onlyIdempotentInspect
Read Workflow graph state without changing it.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional comma-separated goal tag filter. | |
| limit | No | Maximum number of records to return. | |
| query | No | Optional search text. | |
| author | No | Optional goal author filter. | |
| target | No | What to read: status, graphs, graph, goals, goal, or runs. | status |
| goal_id | No | Optional shared-goal identifier. | |
| graph_id | No | Optional graph/universe identifier. | |
| run_status | No | Optional run status filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds minimal value by restating 'without changing it.' It does not disclose additional behaviors like performance, pagination, or return format, but does not contradict annotations.
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. While concise, it could be slightly more informative without losing brevity (e.g., mentioning key parameters). Still, it avoids wordiness.
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 read tool with 8 optional parameters and no output schema, the description is incomplete. It does not explain that the 'target' parameter switches between different aspects (status, graphs, goals) or how filters combine. The agent lacks critical context 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 100%, so the baseline is 3. The description adds no parameter-specific context beyond what the schema already provides; it does not explain how filters or target choices affect output.
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 reads graph state without mutation, using a specific verb and resource. It distinguishes from siblings like 'run.graph' (execution) and 'write.graph' (modification), and annotations further confirm read-only intent.
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 (e.g., 'run.graph' or 'write.graph'). There is no mention of context or exclusion criteria, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read.pageRead PageBRead-onlyIdempotentInspect
Read or search Workflow wiki pages.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional wiki page slug or path. Empty searches by query. | |
| query | No | Optional search text or ambient relevance terms. | |
| category | No | Optional wiki category filter for searches. | |
| max_results | No | Maximum result count. | |
| universe_id | No | Optional target universe page substrate. | |
| changed_since | No | Optional ISO timestamp for feed freshness filtering. With an empty page/query/category, returns pages changed after this timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no behavioral context beyond stating 'Read or search,' which is consistent but not additive. With annotations, a score of 3 is appropriate.
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?
Description is a single sentence with no wasted words. However, it could be slightly more informative without becoming verbose. Very concise.
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?
No output schema exists, but description doesn't hint at return format (e.g., page content, search results list). With 6 optional parameters and no explicit usage pattern, the description is incomplete for a complex tool.
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%; all parameters have descriptions. The tool description adds no extra parameter meaning beyond what the schema already provides. Baseline 3 applies.
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 'Read or search Workflow wiki pages,' using a specific verb and resource. It distinguishes from siblings like write.page (write) and read.graph (graph), making purpose 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?
No guidance on when to use this tool versus alternatives (e.g., read.graph, write.page). No context on prerequisites or when to choose search vs read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run.graphRun GraphBInspect
Run a Workflow graph branch.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_id | No | Optional graph/universe identifier. | |
| run_name | No | Optional display name for the run. | |
| inputs_json | No | Optional JSON object containing run inputs. | |
| branch_def_id | Yes | Branch definition identifier to run. | |
| recursion_limit_override | No | Optional per-run recursion limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Does not disclose behavioral traits beyond annotations, such as return values, side effects, or error handling. Annotations indicate mutation but no additional context.
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 sentence with no redundancy, efficiently conveys the core purpose.
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?
Sufficient for a simple tool with well-documented schema, but missing return value information and broader workflow context.
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 description adds no additional meaning beyond what's already documented 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?
The description 'Run a Workflow graph branch' clearly identifies the action and resource, distinguishing it from sibling tools like 'read.graph' and 'write.graph'.
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; lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write.graphWrite GraphAInspect
Create or queue Workflow graph state.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Human-readable shared-goal name. | |
| tags | No | Optional comma-separated shared-goal tags. | |
| text | No | Request text to queue. | |
| target | Yes | What to write: goal or request. | |
| graph_id | No | Optional target graph/universe identifier. | |
| branch_id | No | Optional target branch identifier. | |
| visibility | No | Shared-goal visibility, usually public. | public |
| description | No | Optional shared-goal description. | |
| request_type | No | Workflow request type. | general |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'queue' behavior but does not explain queuing implications. No contradiction with annotations.
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, directly stating the tool's function with no extraneous words. It is perfectly concise and front-loaded.
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 9 parameters and no output schema, the description is minimal. It does not explain return values or the meaning of 'queue'. The schema covers parameters well, but behavioral context is lacking.
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 the description adds no extra parameter context beyond the schema. The description does not clarify relationships between parameters, maintaining a baseline score.
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 'Create or queue' and the resource 'Workflow graph state', distinguishing it from sibling tools like read.graph, run.graph, and write.page.
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, nor any exclusions or prerequisites. An agent would not know when to choose write.graph over write.page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write.pageWrite PageCInspect
Write, patch, or file a Workflow wiki page.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filing kind: bug, patch_request, feature, or design. | |
| page | No | Wiki page slug or path for page writes. | |
| tags | No | Optional comma-separated tags. | |
| repro | No | Optional reproduction notes for filed issues. | |
| title | No | Filing title when creating a bug, patch, feature, or design page. | |
| content | No | Full page content for a page write. | |
| dry_run | No | Preview consolidation-style wiki writes when supported. | |
| category | No | Wiki category for full page writes. | |
| expected | No | Optional expected behavior for filed issues. | |
| filename | No | Wiki filename for full page writes. | |
| new_text | No | Replacement text for a targeted page patch. | |
| observed | No | Optional observed behavior for filed issues. | |
| old_text | No | Existing text to replace for a targeted page patch. | |
| severity | No | Optional severity for filed issues. | |
| component | No | Optional affected component for filed issues. | |
| force_new | No | Bypass duplicate detection for filed issues. | |
| log_entry | No | Optional wiki log entry for full writes or patches. | |
| workaround | No | Optional workaround for filed issues. | |
| universe_id | No | Optional target universe page substrate. | |
| expected_sha256 | No | Optional full-page hash guard for patches. | |
| reporter_context | No | Optional reporter context for filed issues. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only, not idempotent, and not destructive. The description adds no behavioral context beyond 'write/patch/file', such as interaction with existing pages, overwrite behavior, or auth requirements. With annotations present, bar is lower, but description adds minimal value.
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, making it concise and front-loaded. However, with 21 parameters, it is overly terse and omits critical information about the three distinct operations. It earns its place but lacks sufficient detail.
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 tool's complexity (21 parameters, three modes, no output schema), the description is incomplete. It does not explain which parameters apply to writing vs patching vs filing, nor does it cover return values or error scenarios. The agent would likely struggle to use this tool correctly without additional documentation.
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. However, the description completely fails to explain how the 21 parameters map to the three modes (write, patch, file). For example, which parameters are for filing issues versus page creation? No parameter grouping or usage hints are provided, making it less helpful than 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 is for 'Write, patch, or file a Workflow wiki page,' specifying the verb (write/patch/file) and resource (wiki page). It distinguishes from siblings like 'write.graph' by targeting wiki pages instead of graphs. However, the three distinct operations are bundled without differentiation, slightly reducing clarity.
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 like 'write.graph', nor does it explain which mode (write vs patch vs file) to choose under what circumstances. There is no mention of when not to use it or prerequisites, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!