Conductor MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (tasks, workflows, events) and actions (create, get, list, manage execution), but there is some overlap between 'list_workflows' and 'search_workflows' which could cause confusion as both retrieve workflow executions with filtering capabilities. Descriptions help differentiate them, but the boundary is not entirely clear.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'create_task_definition', 'get_workflow_status', and 'pause_workflow'. All tools use snake_case with clear verbs (create, get, list, pause, restart, etc.) and nouns (task, workflow, event), making them predictable and easy to understand.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a workflow orchestration server like Conductor, covering task and workflow definitions, executions, and management. It feels comprehensive without being overwhelming, though it borders on the upper limit of typical scoping.
Completeness5/5
The tool set provides complete coverage for the Conductor domain, including CRUD operations for task and workflow definitions, lifecycle management for workflows (start, pause, resume, restart, retry, terminate), and detailed retrieval of execution data and logs. No obvious gaps are present, enabling agents to handle full workflows effectively.
Average 3.1/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'the task definition including configuration and metadata', which gives some output context, but lacks details on error handling, permissions, rate limits, or whether it's a read-only operation. For a tool with no annotations, this leaves significant behavioral 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 concise and front-loaded, with two sentences that directly state the purpose and return value without unnecessary details. Every sentence earns its place, though it could be slightly more structured by explicitly separating purpose from output.
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 low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return value, but lacks context on usage guidelines, behavioral traits, or error handling. Without annotations or output schema, more completeness would be beneficial for agent understanding.
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?
The input schema has 100% description coverage, with 'taskName' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 tool's purpose: 'Get the definition of a task by name' specifies the verb (get) and resource (task definition). It distinguishes from siblings like 'get_task_details' or 'list_task_definitions' by focusing on retrieving the full definition rather than logs, status, or a list. However, it doesn't explicitly differentiate from 'get_workflow_definition' in terms of task vs. workflow scope.
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. It doesn't mention when to choose 'get_task_definition' over 'get_task_details' or 'list_task_definitions', nor does it specify prerequisites or exclusions. The agent must infer usage from the name and context 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 the full burden of behavioral disclosure. It states the tool returns log entries but doesn't specify format, pagination, rate limits, authentication requirements, or error handling. For a read operation with zero annotation coverage, this leaves critical behavioral traits undocumented, though it doesn't contradict any annotations.
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 and front-loaded, consisting of two clear sentences that directly state the tool's function and output. There's no unnecessary information or redundancy, making it efficient to parse, though it could be slightly more structured by explicitly separating purpose from behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format of log entries, potential limitations, or how it fits into the broader context of task management with many sibling tools. For a tool with no structured behavioral data, more detail is needed to guide effective use.
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?
The input schema has 100% description coverage, with 'taskId' clearly documented as 'The unique task execution ID'. The description adds no additional parameter semantics beyond this, such as examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the heavy lifting.
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 tool's purpose with a specific verb ('Get') and resource ('execution logs for a specific task'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_task_details' or 'get_task_definition', which might also retrieve task-related information, leaving some ambiguity about its unique role.
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. It doesn't mention any prerequisites, such as needing a valid task ID from another operation, or clarify its scope relative to siblings like 'get_task_details' (which might include logs or other metadata). This lack of context could lead to confusion in tool selection.
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 carries full burden but only states it returns metadata without detailing format, pagination, or sorting. It doesn't cover behavioral traits like permissions needed, rate limits, or whether it's a read-only operation, which is a significant gap for a listing tool.
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, efficient sentence that front-loads the core action and purpose. Every word earns its place with no redundancy or waste, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a listing tool. It lacks details on return format, pagination, or error handling, which are crucial for agent usage. The simplicity of the tool partially mitigates this, but more context is needed.
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 100%, so the schema fully documents the single parameter 'access' with its enum values. The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high coverage.
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 ('List') and resource ('all registered task definitions'), specifying it returns metadata about tasks registered in Conductor. It distinguishes from siblings like 'get_task_definition' by implying a bulk listing, but doesn't explicitly differentiate from 'list_workflow_definitions' or 'list_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 is provided on when to use this tool versus alternatives like 'get_task_definition' for a single task or 'list_workflow_definitions' for workflows. The description lacks explicit when/when-not instructions or prerequisites, leaving usage context implied.
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 full burden but only states it 'Returns metadata about all workflows,' lacking details on pagination, rate limits, authentication needs, or error handling. It doesn't disclose behavioral traits like whether it's read-only (implied but not stated) or performance characteristics, leaving significant gaps for a list operation.
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 two concise sentences that directly state the tool's purpose and return value without redundancy. It's front-loaded with the core function and efficiently communicates essential information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a list tool with filtering parameters. It doesn't explain what 'metadata' includes, how results are structured, or handling of large datasets (e.g., pagination). For a tool with three parameters and complex sibling context, more detail is needed to guide effective use.
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 100%, with clear descriptions for all three parameters (access, tagKey, tagValue). The description adds no parameter semantics beyond what the schema provides, such as explaining filter combinations or default behaviors. Baseline 3 is appropriate as the schema adequately documents parameters.
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 ('List') and resource ('all registered workflow definitions'), specifying it returns metadata about workflows. It distinguishes from siblings like 'get_workflow_definition' (singular) and 'list_workflows' (instances vs definitions), though not explicitly. However, it lacks explicit sibling differentiation, keeping it at 4 instead of 5.
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 like 'get_workflow_definition' for a single definition or 'list_workflows' for workflow instances. It mentions filtering parameters but doesn't explain when filtering is appropriate or necessary, leaving usage context implied at best.
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 burden of behavioral disclosure. It states the workflow continues from where it was paused, which is useful, but fails to cover critical aspects such as required permissions, potential side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 two sentences, front-loaded with the core purpose and followed by a clarifying detail. Every word contributes directly to understanding the tool's function, with no redundant or extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, return values, and differentiation from sibling tools, making it insufficient for an agent to fully understand how to use it effectively in context.
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?
The schema description coverage is 100%, with the single parameter 'workflowId' fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.
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 action ('Resume') and target resource ('a paused workflow execution'), with the specific scope of continuing from where it was paused. However, it does not explicitly differentiate from siblings like 'restart_workflow' or 'retry_workflow', which might have overlapping purposes, preventing a score of 5.
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 implies usage for paused workflows but provides no explicit guidance on when to use this tool versus alternatives like 'restart_workflow' or 'retry_workflow'. It lacks context on prerequisites, exclusions, or scenarios where this is the preferred choice, offering minimal direction.
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 of behavioral disclosure. It states the tool starts a workflow and returns an execution ID, but lacks critical details: whether this is a mutating operation (implied but not confirmed), required permissions, rate limits, error conditions, or what happens if the workflow fails to start. For a tool that likely triggers backend processes, this is a significant gap.
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 two concise sentences that front-load the core action and outcome. There's no fluff or redundancy. However, it could be slightly more structured by explicitly stating it's a mutating operation or listing key parameters, though this isn't required for full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (starting workflows with 5 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain the return value format beyond 'execution ID', error handling, or side effects. For a tool that initiates potentially long-running processes, more context on behavior and outcomes is needed to be fully helpful to an agent.
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 100%, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond implying 'workflowName' is required (matching the schema) and mentioning the return value. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 action ('Start a new workflow execution') and resource ('workflow'), making the purpose immediately understandable. It distinguishes from siblings like 'create_workflow_definition' (which defines workflows) and 'list_workflows' (which lists existing ones). However, it doesn't explicitly contrast with 'restart_workflow' or 'resume_workflow', which are also initiation-related operations.
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. It doesn't mention prerequisites (e.g., needing an existing workflow definition), contrast with similar tools like 'restart_workflow' (for failed executions) or 'resume_workflow' (for paused ones), or specify typical use cases. The agent must infer usage from the name and context 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 the full burden of behavioral disclosure. It states the tool stops the workflow and marks it as terminated, which implies a destructive action, but doesn't cover critical aspects like whether termination is reversible, permission requirements, side effects, or error handling. For a mutation tool with zero annotation coverage, this is a significant gap, scoring a 2.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action, making it easy to parse. Every part of the sentence earns its place by conveying essential information, resulting in a perfect score of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error cases, or usage context. For a tool that terminates workflows, more information is needed to ensure safe and correct usage, leading to a score of 2.
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?
The input schema has 100% description coverage, with clear documentation for both parameters. The description doesn't add any meaning beyond the schema, such as explaining parameter interactions or providing examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 action ('terminate') and resource ('workflow execution'), making the purpose evident. It distinguishes from siblings like 'pause_workflow' or 'restart_workflow' by specifying it stops and marks as terminated, but doesn't explicitly contrast with alternatives like 'cancel_workflow' if present. This is clear but lacks explicit sibling differentiation, warranting a 4.
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. It doesn't mention prerequisites, such as needing a running workflow, or compare to other termination-related tools. Without any context on usage scenarios or exclusions, it leaves the agent to infer when this is appropriate, resulting in a score of 2.
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 burden of behavioral disclosure. It states the tool can create or update, implying mutation, but doesn't cover permissions required, whether updates are idempotent, what happens on conflicts, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the key action ('Create or update a task definition') and adds clarifying behavior. There's no wasted text, but it could be slightly more structured by separating creation and update scenarios for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on what a task definition includes, how to format the JSON object, what happens on success/failure, or how this integrates with sibling tools like workflows. This leaves significant gaps for an AI agent to use it correctly.
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 100%, so the schema already documents the single parameter 'definition' as a 'Complete task definition as a JSON object'. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.
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 ('create or update') and resource ('task definition'), making the purpose understandable. It distinguishes from siblings like 'get_task_definition' or 'list_task_definitions' by focusing on mutation rather than retrieval. However, it doesn't specify what a 'task definition' entails or how it differs from 'workflow definition' tools, keeping it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new or updating existing task definitions, but provides no explicit guidance on when to use this versus alternatives like 'update_task_status' or 'create_workflow_definition'. It mentions the update behavior but doesn't clarify prerequisites, error conditions, or typical use cases, leaving usage somewhat ambiguous.
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 burden of behavioral disclosure. It states the tool returns task status, input/output, and execution details, which is helpful. However, it lacks critical information such as whether this is a read-only operation (implied but not stated), error handling (e.g., for invalid task IDs), performance characteristics, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 and front-loaded, consisting of two sentences that directly state the purpose and return values without any fluff. Every word earns its place, making it easy for an agent to parse quickly. This efficiency is exemplary for tool descriptions.
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 low complexity (single parameter, no nested objects) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more behavioral context (e.g., read-only nature, error cases) to compensate. The description covers basic functionality but leaves gaps in operational understanding, making it just sufficient for simple use cases.
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?
The input schema has 100% description coverage, with the single parameter 'taskId' well-documented as 'The unique task execution ID'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 'Get details' and resource 'specific task execution by task ID', making the purpose immediately understandable. It distinguishes from siblings like get_task_logs (logs) and get_workflow_status (workflow-level status), though not explicitly. However, it could be more specific about what distinguishes it from get_task_definition (definition vs. execution details).
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 like get_task_definition or get_task_logs. It mentions the task ID parameter but doesn't explain prerequisites (e.g., needing an existing task execution) or contextual usage (e.g., for monitoring or debugging). This leaves the agent without clear direction on selection among similar tools.
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 burden of behavioral disclosure. It states the tool returns a list of executions but omits critical details like pagination behavior, rate limits, authentication requirements, or whether it's read-only. For a list operation with zero annotation coverage, this is a significant gap in 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 two sentences with zero waste—it directly states the purpose and return value. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 moderate complexity (5 optional parameters) and lack of annotations/output schema, the description is minimally adequate. It covers the basic action and return type but misses behavioral context like pagination or error handling. With no output schema, it should ideally explain the return structure more, but it's passable for a list operation.
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 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying filtering exists, which is already covered in the schema. This meets the baseline of 3 where the schema does the heavy lifting.
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 ('List') and resource ('workflow executions') with the action of filtering. It distinguishes from siblings like 'search_workflows' by focusing on listing with filters rather than broader search functionality. However, it doesn't explicitly contrast with 'get_workflow_status' or other getters, keeping it at 4 rather than 5.
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 mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives like 'search_workflows' or 'get_workflow_status'. It lacks explicit context about use cases, prerequisites, or exclusions, leaving the agent with minimal direction.
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 'update' implying mutation but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to existing data. The description is minimal and lacks crucial operational context for a mutation tool.
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 two sentences, front-loaded with the core purpose and followed by usage context. It's efficient with zero waste, though slightly sparse. Every sentence earns its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 5 parameters (including nested objects), the description is incomplete. It doesn't explain return values, error handling, or behavioral implications, leaving significant gaps for agent understanding.
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 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional meaning.
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 'update' and resource 'status of a task execution', making the purpose evident. It distinguishes from siblings by focusing on status updates rather than creation, retrieval, or workflow control. However, it doesn't explicitly differentiate from all siblings (e.g., 'retry_workflow' might also update status).
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 provides implied usage context ('typically used by workers to update task status'), suggesting it's for worker processes during task execution. However, it lacks explicit guidance on when to use this versus alternatives like 'retry_workflow' or 'terminate_workflow', and doesn't specify 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the update behavior if a workflow exists, which is useful, but fails to cover critical aspects: it doesn't specify required permissions, whether changes are reversible, potential side effects, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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—two sentences that directly state the tool's function and its update behavior. Every word earns its place with no redundancy or fluff, making it easy to parse and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested objects) and lack of annotations and output schema, the description is insufficient. It doesn't explain what a 'workflow definition' entails, how to structure the JSON, error conditions, or what the tool returns. For a create/update operation with significant implications, more context is needed to guide effective use.
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 100%, so the input schema fully documents both parameters ('definition' and 'overwrite'). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain the structure of the 'definition' object or clarify the 'overwrite' default behavior further. Baseline 3 is appropriate when the schema handles parameter documentation.
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 ('create or update') and resource ('workflow definition'), making the purpose understandable. It distinguishes this tool from read-only siblings like 'get_workflow_definition' by indicating it modifies data. However, it doesn't explicitly differentiate from 'update_task_status' or other mutation tools, keeping it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning that existing workflows will be updated, suggesting it's for both creation and modification scenarios. However, it provides no explicit guidance on when to use this versus alternatives like 'create_task_definition' or 'update_task_status', nor does it mention prerequisites or exclusions, leaving the agent to infer context.
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 burden of behavioral disclosure. It mentions that restarting creates a new execution, which implies mutation, but lacks details on permissions, side effects, error handling, or what happens to the original execution. This is inadequate for a mutation tool with zero annotation coverage.
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 two concise sentences with zero waste, front-loading the core action and efficiently explaining the outcome. Every sentence earns its place by adding value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits like permissions, side effects, or response format, leaving significant gaps for an AI agent to understand how to use it correctly.
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 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what the schema provides, such as clarifying parameter interactions or usage examples, which aligns with the baseline score when schema does the heavy lifting.
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 specific action ('Restart a workflow execution from the beginning') and the resource ('workflow execution'), distinguishing it from siblings like 'retry_workflow' or 'resume_workflow' by emphasizing it creates a new execution rather than continuing an existing one.
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 like 'retry_workflow' or 'resume_workflow', nor does it mention prerequisites or exclusions. It states what the tool does but not when it's appropriate.
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 burden of behavioral disclosure. It mentions 'advanced search' and 'complex queries' but lacks critical details such as pagination behavior (implied by parameters but not described), rate limits, authentication requirements, or what the output looks like. This is inadequate for a search tool with no annotation coverage.
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 that efficiently convey the core functionality and key features. It's front-loaded with the main purpose and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with query syntax) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances like how pagination works in practice. For a search tool with no structured output information, this leaves significant gaps for an agent.
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?
The schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema by hinting at query syntax complexity but doesn't provide additional semantics or examples beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
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 tool's purpose as 'Advanced search for workflow executions using query syntax' with the verb 'search' and resource 'workflow executions'. It distinguishes from siblings like 'list_workflows' by emphasizing advanced query capabilities, though it doesn't explicitly name the sibling for comparison.
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 context through 'Advanced search' and 'complex queries with multiple criteria', suggesting this is for detailed filtering beyond basic listing. However, it doesn't explicitly state when to use this versus alternatives like 'list_workflows' or provide clear exclusions, leaving some ambiguity.
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 of behavioral disclosure. It mentions the tool can 'get all event handlers or filter,' but doesn't specify whether this is a read-only operation, if it requires authentication, what the return format is (e.g., list, pagination), or any rate limits. For a tool with no annotations, this is a significant gap in 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 concise and well-structured in two sentences: the first states the purpose and filtering options, and the second explains what event handlers are. Every sentence adds value without redundancy, making it efficient and 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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and filtering, but lacks details on behavioral aspects like return format, permissions, or error handling. Without annotations or output schema, more context would be beneficial for completeness.
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?
The description mentions filtering by 'event and active status,' which aligns with the two parameters in the schema (event, activeOnly). Since schema description coverage is 100%, the schema already documents these parameters fully. The description adds no additional semantic context beyond what the schema provides, so the baseline score of 3 is appropriate.
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 tool's purpose: 'Get all event handlers or filter by event and active status.' It specifies the verb ('Get') and resource ('event handlers'), and explains what event handlers are ('define how Conductor responds to external events'). However, it doesn't explicitly differentiate from sibling tools (e.g., get_task_definition, get_workflow_definition), which prevents a score of 5.
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 context by mentioning filtering options ('filter by event and active status'), but doesn't provide explicit guidance on when to use this tool versus alternatives like get_task_definition or get_workflow_definition. It also doesn't mention prerequisites or exclusions, leaving usage somewhat ambiguous.
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 of behavioral disclosure. It states the tool retries from the last failed task, which implies mutation and potential side effects, but doesn't cover permissions, rate limits, error handling, or what happens to in-progress tasks. For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core action and scope. It wastes no words, directly stating what the tool does without redundancy. This is appropriately sized for a tool with clear parameters and no complex output schema.
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 complexity (mutation with 2 parameters) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but misses behavioral details like side effects or return values. For a mutation tool, more context on permissions or outcomes would improve completeness, but it's not entirely incomplete.
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 100%, with clear descriptions for both parameters. The description doesn't add any semantic details beyond the schema, such as explaining the implications of 'resumeSubworkflowTasks' or providing examples. Baseline 3 is appropriate since the schema adequately documents parameters, but no extra value is added.
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 action ('Retry') and target ('a failed workflow execution'), specifying it resumes 'from the last failed task'. It distinguishes from siblings like 'restart_workflow' or 'resume_workflow' by focusing on retrying after failure, though it doesn't explicitly name these alternatives. This provides a specific verb+resource+scope, making the purpose well-defined.
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 context ('failed workflow execution') but doesn't explicitly state when to use this tool versus alternatives like 'restart_workflow' or 'resume_workflow'. It suggests applicability to failed executions but lacks guidance on prerequisites, exclusions, or specific scenarios. This leaves usage somewhat open to interpretation without clear boundaries.
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 this is a read operation ('Get') and describes the return content, but does not disclose behavioral traits such as error handling (e.g., if workflow not found), permissions required, rate limits, or whether it's idempotent. For a read tool with zero annotation coverage, this is a significant gap in behavioral context.
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 two sentences, front-loaded with the core purpose and followed by return details. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
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 moderate complexity (read operation with 2 parameters), no annotations, and no output schema, the description is partially complete. It covers the purpose and return content but lacks behavioral details like error handling or permissions. It is adequate as a minimum viable description but has clear gaps in context.
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 100%, so the schema already documents both parameters (workflowName and version) with descriptions. The description adds marginal value by implying the version parameter defaults to latest, but does not provide additional semantics beyond what the schema offers. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Get the definition'), resource ('workflow'), and scope ('by name and version'), distinguishing it from siblings like get_workflow_status or list_workflow_definitions. It explicitly mentions what is returned ('complete workflow definition including all tasks and configuration'), which adds clarity beyond just the name.
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 retrieving a specific workflow's definition by name and version, but does not explicitly state when to use this tool versus alternatives like list_workflow_definitions or get_task_definition. It provides some context but lacks clear exclusions or named alternatives.
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 of behavioral disclosure. It mentions that the workflow 'can be resumed later', which adds some context about the pause state. However, it lacks details on permissions required, whether the pause is immediate or delayed, error conditions, or what happens to in-progress tasks, leaving significant gaps for a mutation tool.
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 two concise sentences that are front-loaded with the main action and outcome. There is no redundant or unnecessary information, making it efficient and easy to understand.
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 complexity as a mutation operation with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and effect but lacks details on behavioral aspects like error handling or return values, which are important for an agent to use it correctly.
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?
The schema description coverage is 100%, with the parameter 'workflowId' clearly documented in the schema. The description does not add any additional meaning or details about the parameter beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 specific action ('Pause') and resource ('a running workflow execution'), distinguishing it from siblings like 'resume_workflow' or 'terminate_workflow'. It also mentions the outcome ('can be resumed later'), which adds clarity about the tool's effect.
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 context by specifying 'a running workflow execution', suggesting it should be used when a workflow is active. However, it does not explicitly state when to use this tool versus alternatives like 'terminate_workflow' or 'restart_workflow', nor does it provide exclusions or prerequisites for usage.
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 provided, the description carries the full burden. It discloses that it returns 'complete workflow execution details including tasks, input/output, and current status', which adds behavioral context beyond the input schema. However, it does not cover aspects like error handling, permissions, or rate limits, leaving gaps for a tool with no annotations.
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 two sentences, front-loaded with the core purpose and followed by details on return values. Every sentence adds value without redundancy, making it efficient and well-structured.
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 no annotations and no output schema, the description provides good context by specifying what is returned (details including tasks, input/output, status). However, it lacks information on error cases or response structure, which could be important for a tool with no structured output schema.
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 100%, so the schema already documents both parameters (workflowId and includeTaskDetails). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or usage tips, meeting the baseline for high coverage.
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 ('Get') and resource ('workflow execution by its ID'), specifying it returns 'current status and details' and 'complete workflow execution details including tasks, input/output, and current status'. This distinguishes it from siblings like list_workflows (which lists multiple workflows) or get_task_details (which focuses on tasks).
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 'by its ID', suggesting it's for retrieving a specific workflow execution, but it does not explicitly mention when to use this versus alternatives like search_workflows or list_workflows. No exclusions or prerequisites are provided, leaving some ambiguity.
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/opensensor/conductor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/opensensor/conductor-mcp)

Score Badge

Copy to your README.md:

[![conductor-mcp MCP server](https://glama.ai/mcp/servers/opensensor/conductor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/opensensor/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/opensensor/conductor-mcp'

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