Conductor MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.9
Disambiguation5/5
Tools are clearly grouped by resource (event, task, workflow) and each tool has a distinct purpose. There is no overlap between tools, and descriptions make it easy to differentiate them.
Naming Consistency5/5
All tool names follow a consistent resource_verb_noun pattern (e.g., event_get_event_handlers, task_create_task_definition, workflow_get_workflow_by_id). This provides predictability and clarity.
Tool Count4/5
With 19 tools, the set is slightly above the typical 3-15 range but still reasonable for a comprehensive workflow orchestration server covering event handling, task management, and workflow lifecycle operations.
Completeness4/5
The tool surface covers major operations for event handlers, task definitions, and workflow executions. Minor gaps exist, such as explicit workflow definition update and task execution result retrieval, but the overall coverage is good.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it gets metadata, but does not mention whether the operation is read-only, requires specific permissions, or has side effects. The name implies a read, but no explicit assurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences. The first sentence provides the main purpose. However, the second sentence merely restates the parameter definition, which is redundant and could be omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. However, it lacks context such as whether the workflow must exist, or behavior if not found. For a simple tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal value beyond the schema: it repeats 'workflow_name' as 'the name of the workflow'. No format, constraints, or examples are provided for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving metadata for a Conductor workflow by name, in JSON format. It distinguishes from sibling tools like 'workflow_get_workflow_by_id' which uses a different identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., using ID instead of name). There is no mention of prerequisites or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It states the output format but does not disclose idempotency, side effects, or error behavior. For a read-only get operation, this is passable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence plus an args line. It is front-loaded with the purpose, but lacks structured sections like use cases or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description covers the core action. However, it omits important context such as prerequisites (execution ID must exist), error conditions, and differentiation from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It identifies the parameter as a 'uuid' which adds some meaning beyond the schema, but does not elaborate further. The parameter is simple, but the description adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'workflow execution' with the key identifier 'execution id'. However, it does not distinguish from sibling getters like 'workflow_get_workflow_by_name' which retrieves the workflow definition rather than an execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 typical usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explains retrying from the last failed task and the resume_subworkflow_tasks parameter, but lacks details on side effects (e.g., new execution ID, re-running tasks) or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no redundant information. The docstring format is efficient, though a bit more brevity could be achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality and parameters. However, with an output schema present, it should mention the return type (e.g., a new execution ID). The presence of many sibling workflow tools suggests more complete guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds clear meaning: workflow_id is a uuid of the execution, and resume_subworkflow_tasks controls subworkflow resumption. This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retries a failed workflow execution from the last failed task, using a specific verb and resource. This distinguishes it from siblings like workflow_restart_workflow or workflow_resume_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., restart, resume). The description does not provide context for appropriate use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool retrieves all task definitions, which is straightforward. However, it does not mention potential impacts (e.g., performance with large datasets, pagination, or read-only nature). The behavior is adequately transparent but not enriched beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is front-loaded and clearly communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is adequate. It tells exactly what the tool does. However, it could be slightly more complete by noting that it returns all definitions without any filtering, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). Per guidelines, the baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets all task definitions' uses a clear verb and specifies the resource. It implicitly distinguishes from sibling tools like task_get_task_by_id (single) and task_get_task_definition_for_tasktype (filtered). However, it lacks any additional clarifying details, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as task_get_task_by_id or task_get_task_definition_for_tasktype. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Gets metadata', implying a read operation, but fails to mention what happens if the task ID is invalid, authentication requirements, or rate limiting. This lack of detail reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences: the first defines the tool's purpose, the second details the input parameter. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with an output schema, the description covers the essential purpose and input. However, it lacks mention of error handling or edge cases, which would improve completeness given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by specifying that task_id is 'The uuid representing the task id'. The schema only defines type string, so this clarification is valuable given the low schema coverage (0%). The single parameter is well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets the metadata for a conductor workflow task in json format based on that task's id', providing a specific verb (Gets) and resource (conductor workflow task metadata) with a clear scope (by id). This differentiates it from sibling tools like task_get_logs or task_get_all_definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention when not to use it or suggest companion tools like task_get_task_logs for further details. It only implies basic usage with a task ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only states 'gets' (implying read-only) but lacks details on permissions, performance, or response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no extraneous words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool with an output schema, the description is largely complete. Could elaborate on 'status details' but output schema likely fills gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, so schema coverage is 100%. The description adds no parameter info but doesn't need to; baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets current status details for all conductor workflow task queues, using a specific verb ('Gets') and resource. It distinguishes from sibling tools which deal with individual tasks, task definitions, or workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description implies it's for viewing task queue status but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the update action but lacks details on side effects, authorization needs, rate limits, or behavior when updating to invalid statuses. The minimal disclosure leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with a clear opening sentence followed by a structured args list. Each sentence adds value, though the args list could be integrated more tightly. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (reducing the need to explain return values), the description provides adequate context. However, it could mention idempotency or partial update behavior to be fully complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all parameters, including the enum values for status and the optional nature of output_data and logs. This adds value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the status of a task execution, with a specific verb ('Updates') and resource ('task execution status'). It distinguishes itself from sibling tools like task_get_task_by_id or task_create_task_definition by focusing on status updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's typically used by workers, providing context, but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic read operation; no disclosure of side effects, permissions, or rate limits. Minimal beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is mostly concise with purpose upfront. Minor redundancy in 'Args:' block that repeats schema. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with output schema, description covers scope (user-defined tasks) and parameter meaning. Adequate given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds meaning: 'taskType is synonymous with task name' and clarifies it's a string representing the desired taskType. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Gets the task definition for the given taskType', explains synonym, and restricts to user-defined tasks. Distinguishes from siblings like task_create_task_definition and task_get_all_task_definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context (user-defined tasks) but does not explicitly guide when to use this tool vs alternatives like task_get_task_by_id or task_get_all_task_definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states the workflow will pause and can be resumed later, but lacks details on side effects (e.g., whether immediate or after current step), prerequisites, or behavior if already paused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and an Args section. No wasted words, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is adequate but leaves gaps: it doesn't reference the output, nor does it specify behavior for edge cases like pausing an already paused workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block explains workflow_id as 'the uuid representing the execution of the workflow to pause', which adds format and context beyond the schema's simple string type. Schema coverage is 0%, making this compensation valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pauses a running workflow execution') and the resource. It also mentions that the workflow can be resumed later, distinguishing it from terminating tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (pause a running execution) but does not explicitly compare with sibling tools like resume or terminate. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the 'range of time' limitation but omits critical behavioral traits such as pagination, rate limits, authentication requirements, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured, starting with the purpose, then query syntax, examples, and parameter details. It could be slightly tighter but effectively communicates what is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input is thoroughly documented, and the output schema exists (not shown), so the description need not detail return values. However, it lacks behavioral information like pagination or result limits, which is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a string 'query' parameter with no description (0% coverage). The description extensively explains the query format, supported fields, operators, and examples, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for workflow executions based on payload and other parameters, with a specific verb and resource. It distinguishes from siblings that retrieve by ID or list all workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains query syntax and that leaving query empty returns all executions, but does not explicitly guide when to use this tool versus other workflow retrieval tools like workflow_get_workflow_by_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions creating a new execution but does not disclose what happens to the original execution (e.g., status change, termination). Side effects and permission requirements are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus concise bullet-style Args. Front-loaded with the main purpose. Every sentence is necessary and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not shown; description covers basic purpose and parameters. However, it lacks behavioral context (e.g., idempotency, effect on original execution) which is important for a restart action. Not fully complete given the tool's complexity and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining both parameters: workflow_id as 'The uuid representing the execution' and use_latest_definitions as 'If True, use the latest workflow definition instead of the original version'. Brief but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Restarts' and the resource 'workflow execution', and specifies it creates a new execution with the same input. It distinguishes from siblings like retry (which resumes from failure) and resume (from pause).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it restarts from the beginning and creates a new execution with the same input, but does not explicitly state when to use this tool versus alternatives like retry or resume. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions continuing from where paused. It does not disclose behavioral traits like idempotency, prerequisites (must be paused), or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no wasted words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema (though not shown) which might cover return values. However, description lacks prerequisites and error conditions, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining workflow_id is the UUID of the execution to resume, compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Resumes' and the resource 'paused workflow execution', and distinguishes from sibling tools like pause_workflow and terminate_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for paused workflows, but no explicit when-to-use, when-not-to-use, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains idempotency strategies and parameter roles but does not explicitly state that this tool creates a new workflow execution (a mutation) or discuss side effects, permissions, or rate limits. The behavior is partially transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a clear purpose sentence followed by an Args section. It is efficient, with each parameter receiving a single line. No redundant or unnecessary text, though it could be slightly more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and the main action. However, it lacks guidance on when to use this tool versus other workflow tools (e.g., workflow_create_workflow_definition). Since an output schema exists, return values are not needed, but the absence of usage context reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds substantial meaning. It explains each parameter: workflow_name as the definition name, correlation_id for uniqueness, priority with ordering, idempotency_key and idempotency_strategy with three strategies, and data as a dictionary of arguments. This goes far beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Starts a new execution of a conductor workflow by its name', providing a specific verb ('starts') and resource ('workflow execution'). This distinguishes it from sibling tools that read, pause, or terminate workflows, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or recommend scenarios. The agent must infer usage from the purpose statement alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Creates or updates' without disclosing whether updates are partial or full replacements, idempotency, or required permissions. For a mutation tool, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, bullet points of minimum fields, and an example. It is front-loaded with purpose, though slightly verbose with the 'Args' line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It adequately covers the parameter usage and provides a working example. However, it could mention that the tool can also update existing definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully by listing minimum fields (name, description, retryCount, etc.) and providing an example. This adds essential meaning beyond the generic object schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates or updates a task definition' with specific verb and resource. It distinguishes from sibling read-only tasks like task_get_all_task_definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating/updating task definitions but does not explicitly state when to use vs. alternatives or provide exclusions. It lacks guidance on idempotency or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states it returns log entries, but does not disclose any behaviors like pagination, rate limits, or data freshness. It is basic but accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; two sentences front-loading the main action and then the parameter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists to document return values, the description sufficiently covers the tool's purpose and parameter. However, it could note the scope (e.g., task execution logs only).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds: 'task_id: The uuid representing the task execution id', clarifying the parameter's purpose beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets execution logs for a specific task' with a specific verb and resource. It distinguishes from sibling tools that deal with task definitions, workflows, or status updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to fetch logs vs. other task operations. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description says it stops and marks as terminated, but does not disclose whether termination is irreversible, fails if already terminated, or triggers side effects. For a destructive action, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with immediate purpose and parameter details. No filler; every word serves a purpose. Very efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists for return value, description adequately covers purpose and key parameters. Minor omission: no mention of error cases or prerequisites, but tool is simple enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains workflow_id as UUID of execution and reason as optional, adding meaning beyond schema types. With 0% schema coverage, this compensates well, though constraints on workflow_id format are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it terminates a workflow execution and marks it as terminated. The verb 'terminates' and resource 'workflow execution' are specific. Among siblings like pause, resume, restart, this is distinct in action and finality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs. alternatives. The description implies termination is final, but doesn't contrast with pause or retry. Agent might need to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool is read-only ('Gets'), but does not disclose potential side effects, authentication needs, or rate limits. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the action and result with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists (per context signals), the description is complete enough to convey the tool's purpose and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter meaning. Baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a short description of all existing conductor workflows, using a specific verb ('Gets') and resource ('short description of all existing conductor workflows'). This distinguishes it from sibling tools that target specific workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list all workflows, but it does not explicitly provide guidance on when to use this tool versus alternatives like workflow_get_workflow_by_id or workflow_get_workflow_by_name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that event handlers define how Conductor responds to external events and can trigger workflows or actions. However, it does not disclose any side effects, authentication needs, or pagination behavior. As a read operation, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a main sentence and an extra paragraph providing context. While the extra paragraph is helpful, it could be trimmed without losing essential information. The structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The description explains the tool's purpose and parameters adequately. For a simple get tool with two optional parameters, it is sufficiently complete, though it could mention that it returns a list of handlers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description adds clear plain-language explanations for both parameters: 'event' (optional filter by name) and 'active_only' (returns only active handlers, default True). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Gets all event handlers or filters by event name and active status', which clearly specifies the action (get) and resource (event handlers). The sibling tools are all task and workflow-related, so this tool is distinct in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates filtering by event and active status, which helps with when to use. However, it does not explicitly state when not to use or mention alternatives, but given the tool's focus on event handlers vs sibling tools, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses key behaviors: workflow creation versioning rules, task input/output mapping (always a Map, output wrapped in 'result'), SWITCH task produces no output, constraints on expressions and input parameters. This provides comprehensive transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long due to multiple full examples and extensive rules. While well-structured with sections and bullet points, it could be more concise by summarizing key points and moving examples to a separate reference. Many sentences repeat similar concepts (e.g., input parameter assignments).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the workflow_definition parameter and the presence of an output schema (not shown but indicated), the description covers all necessary aspects: constructs, rules, examples, and error-prone behaviors. No gaps are apparent for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'workflow_definition' as an object with additionalProperties, offering no semantic detail. The description fully compensates with detailed examples, rules, and documentation of constructs (do_while, switch, inline), input parameter referencing via $.var, and expression syntax. It adds immense meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a workflow definition from the provided workflow_definition dict param.' The verb ('creates') and resource ('workflow definition') are specific, and the tool is easily distinguished from sibling tools like workflow_get_workflow_by_id or workflow_start_workflow_by_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use constructs (do_while, switch, inline) and important rules (unique taskReferenceName, version increment for updates, input mapping). While it doesn't explicitly compare with sibling tools, it effectively tells the agent how to use the tool correctly and highlights common pitfalls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![conductor-mcp MCP server](https://glama.ai/mcp/servers/conductor-oss/conductor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/conductor-oss/conductor-mcp)

Score Badge

Copy to your README.md:

[![conductor-mcp MCP server](https://glama.ai/mcp/servers/conductor-oss/conductor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/conductor-oss/conductor-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/conductor-oss/conductor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server