The Sequential MCP Server is a task orchestration server designed to manage and execute complex workflows for AI agents, handling task dependencies, execution order, retries, and progress tracking.
Task Management
Create tasks (single or batch) with names, descriptions, dependencies, metadata, retry limits, and optional parent tasks for subtask hierarchies
Update, delete, retrieve, and list tasks; filter by status (pending, in_progress, completed, failed)
Get subtasks of a parent task
Task Execution
Mark tasks as in progress, completed (with results), or failed (with error messages)
Reset tasks to pending; retry failed tasks up to their configured maxRetries limit
Dependency Management
Get all tasks ready to execute based on completed dependencies
Check whether a specific task's dependencies are satisfied
Workflow Management
Create, retrieve, list, and delete workflows (named groups of tasks)
Workflow Execution
Start workflow runs that auto-detect initially ready tasks
Advance runs to unlock next tasks after completions/failures
Retrieve run details, list all runs, and get next executable tasks scoped to a workflow
Clean up old workflow runs by age or count
System & Utilities
Get statistics about tasks and workflows
Clear all tasks and workflows
Manually save state to persistent JSON storage
Automatically log all tool calls for auditing and debugging
Retrieve server version information
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sequential MCP Server Create a deployment workflow with tasks: Build, Test, Deploy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Version: 4.6.0
Task Orchestrator MCP is a powerful task orchestration server designed specifically to enhance LLM agents. It provides structured task management, dependency tracking, and workflow execution โ turning chaotic, non-deterministic LLM tool calls into reliable, sequential, and parallel-capable processes.
Whether you're building complex multi-step features, deployment pipelines, or long-running agent workflows, this server gives the LLM a cognitive scaffold to think and act more effectively.
LLMs excel at generating ideas but often struggle with:
Maintaining consistent order across tool calls
Remembering dependencies between steps
Managing long-running, stateful processes
Avoiding duplicate or out-of-order actions
Task Orchestrator solves these problems by acting as an external executive function:
Declares tasks with clear dependencies
Automatically handles execution order
Supports hierarchical subtasks (parent/child)
Provides persistent state across conversations
Enables safe parallel execution of independent tasks
Related MCP server: Agent Board
๐ Task Management โ Create, update, track tasks with rich metadata, priority, and order
๐ Rich Dependencies โ Unified dependency model with types (hard/soft/conditional/external), failure policies, and metadata
๐๏ธ Hierarchical Support โ Parent tasks with subtasks (LLM-friendly hierarchy)
๐ฏ Workflow Orchestration โ Group tasks into named workflows with automatic progression
โฑ๏ธ Execution Tracking โ Start/complete times, durations, retries
๐พ Persistent Storage โ JSON or SQLite backend
๐งน Cleanup Tools โ Handle orphaned, duplicate, or stale tasks (common with LLM usage)
๐ Introspection Tools โ Dependency graphs, Mermaid export, blocked tasks, critical path analysis
๐ง Dynamic Management โ Add, remove, update dependencies, move tasks at runtime
๐ Statistics & Logging โ Full visibility into agent activity
{
"name": "dashboard-feature-2024",
"taskIds": ["parent-id", "subtask-1-id", ...]
}Create the parent task first
Use the returned ID as parentTaskId for children
Subtasks can start immediately (no blocking on parent in_progress)
Parent completes when subtasks are done
You no longer need perfect sequencing โ declare dependencies and let the server guide execution.
This is an excellent idea.
As an LLM myself, I can say with confidence that tools like Task Orchestrator are transformative. They address one of the fundamental limitations of current-generation models: the gap between creative reasoning and reliable execution.
By externalizing task state, dependency graphs, and execution flow, this server allows the LLM to focus on what it does best โ problem decomposition, creative solutions, and high-level planning โ while the orchestrator enforces correctness, persistence, and progress tracking.
It effectively turns a single LLM call into a persistent, stateful agent capable of long-horizon work. I believe systems like this will become standard infrastructure for advanced AI agents. The combination of hierarchical tasks, workflows, and cleanup tools makes it particularly robust for real-world LLM usage patterns.
Highly recommended. This is exactly the kind of tool that bridges the gap between "smart chatbot" and "reliable autonomous agent."
โ Grok
// 1. Create parent
{ "name": "Build User Dashboard" }
// 2. Create subtasks using parent's ID
{ "name": "Design Dashboard Layout", "parentTaskId": "a0669b20-..." }
// 3. Start the workflow with start_workflow_execution (tasks are automatically marked in progress when ready)
// 4. Work on ready tasks using complete_task / fail_tasknpm install -g agent_mcp_task_orchestratorThen configure in your MCP client config:
{
"mcpServers": {
"task-orchestrator": {
"command": "agent_mcp_task_orchestrator"
}
}
}Note: Storage automatically uses ~/.task-orchestrator/storage/ directory. No configuration needed.
git clone https://github.com/HefnySco/agent_mcp_task_orchestrator.git
cd agent_mcp_task_orchestrator
npm install
npm run buildThen configure with the local path:
{
"mcpServers": {
"task-orchestrator": {
"command": "node",
"args": ["/path/to/agent_mcp_task_orchestrator/dist/index.js"]
}
}
}Note: Storage automatically uses ~/.task-orchestrator/storage/ directory. No configuration needed.
TASK_ORCHESTRATOR_STORAGE_BACKEND: Storage backend type (json or sqlite, default: json)
TASK_ORCHESTRATOR_LOG: Enable file logging for tool requests and LLM responses (true to enable, default: disabled)
TASK_ORCHESTRATOR_OUTPUT_DIR: Custom directory for activity logs (default: ~/.task-orchestrator/output, only used when TASK_ORCHESTRATOR_LOG=true)
For maintainers:
# Build and publish
npm run build
npm publishThe prepublishOnly script automatically builds before publishing.
To use Task Orchestrator MCP with Windsurf (Cascade):
Install globally:
npm install -g agent_mcp_task_orchestratorAdd to Windsurf MCP config:
Edit ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"task-orchestrator": {
"command": "agent_mcp_task_orchestrator"
}
}
}Restart Windsurf to pick up the new MCP server configuration.
Note: Storage automatically uses ~/.task-orchestrator/storage/ directory. No additional configuration needed.
create_tasksCreate one or more tasks with optional dependencies and parent tasks.
Parameters:
tasks (required): Array of task objects, each with:
name (required): The name of the task
description (optional): Description of the task
dependencies (optional): Array of dependencies (string shorthand or RichDependency objects)
String shorthand: Task ID, positional reference (task-1, task-2...), or task name
RichDependency object: Full dependency with type, onFailure, condition, url, timeoutMs, metadata
priority (optional): Task priority (higher = more important, affects execution order)
order (optional): Order among siblings (for parent-child relationships)
parentTaskId (optional): Parent task ID for creating subtasks. CRITICAL: Must be an actual existing task ID, NOT a positional reference. Create the parent task first, get its ID from the response, then use that ID here.
metadata (optional): Additional metadata for the task
maxRetries (optional): Maximum number of retry attempts for this task
deduplication (optional): How to handle duplicate tasks (skip, reuse, error, none)
Important Notes:
Positional references (task-1, task-2, etc.) ONLY work for dependencies within the same batch
For parentTaskId, you MUST use actual existing task IDs - create the parent task first, get its ID from the response, then create subtasks using that ID
Do not use positional references for parentTaskId
Dependencies support rich types: hard (default), soft, conditional, external
update_taskUpdate an existing task.
Parameters:
id (required): The ID of the task to update
name (optional): New name for the task
description (optional): New description
dependencies (optional): New dependencies (string shorthand or RichDependency objects)
priority (optional): Task priority (higher = more important)
order (optional): Order among siblings
metadata (optional): New metadata
delete_taskDelete a task by ID.
Parameters:
id (required): The ID of the task to delete
get_taskGet a specific task by ID.
Parameters:
id (required): The ID of the task to retrieve
list_tasksList all tasks or filter by status.
Parameters:
status (optional): Filter by status ('pending', 'in_progress', 'completed', 'failed')
complete_taskMark a task as completed and optionally provide a result. This is the main tool to use when you finish working on a task.
Parameters:
id (required): The ID of the task to complete
result (optional): The result of the task execution
fail_taskMark a task as failed with an error message.
Parameters:
id (required): The ID of the task to fail
error (required): The error message
start_taskMark a task as in progress. Use this only when working with standalone tasks outside of workflows.
Parameters:
id (required): The ID of the task to start
reset_taskReset a task back to pending status.
Parameters:
id (required): The ID of the task to reset
retry_taskRetry a failed task, incrementing retry count.
Parameters:
id (required): The ID of the task to retry
Note: Task will only be retried if it hasn't exceeded its maxRetries limit.
add_dependencyAdd a dependency to a task. Supports both string shorthand and RichDependency objects.
Parameters:
taskId (required): The ID of the task to add dependency to
dependency (required): Dependency to add (string shorthand or RichDependency object)
remove_dependencyRemove a dependency from a task.
Parameters:
taskId (required): The ID of the task to remove dependency from
depTaskId (required): The dependency task ID to remove
update_dependencyUpdate an existing dependency on a task.
Parameters:
taskId (required): The ID of the task to update dependency for
depTaskId (required): The dependency task ID to update
updates (optional): Partial updates to apply (type, onFailure, condition, url, timeoutMs, metadata)
move_taskMove a task to a new parent or change its order among siblings.
Parameters:
taskId (required): The ID of the task to move
newParentTaskId (optional): New parent task ID (null to remove parent)
position (optional): Order position among siblings
get_next_tasksGet tasks that are ready to execute (all dependencies completed).
can_executeCheck if a task can be executed based on its dependencies.
Parameters:
id (required): The ID of the task to check
create_workflowCreate a workflow (group of tasks in sequence).
Parameters:
name (required): The name of the workflow
taskIds (required): Array of task IDs in the workflow
get_workflowGet a workflow by ID.
Parameters:
id (required): The ID of the workflow to retrieve
list_workflowsList all workflows.
delete_workflowDelete a workflow by ID.
Parameters:
id (required): The ID of the workflow to delete
start_workflow_executionStart execution of a workflow, creating a workflow run.
Parameters:
workflowId (required): The ID of the workflow to execute
advance_workflow_runAdvance a workflow run to the next task.
Parameters:
runId (required): The ID of the workflow run to advance
get_workflow_runGet a workflow run by ID.
Parameters:
runId (required): The ID of the workflow run to retrieve
list_workflow_runsList all workflow runs.
get_next_workflow_tasksGet tasks that are ready to execute within a specific workflow (dependency-aware).
Parameters:
workflowId (required): The ID of the workflow to get ready tasks for
get_dependency_graphGet the dependency graph for a workflow. Returns nodes (tasks) and edges (dependencies).
Parameters:
workflowId (optional): Workflow ID to filter by
export_mermaidExport the dependency graph as a Mermaid flowchart diagram. This tool generates an image that is displayed in the LLM chat agent.
Parameters:
workflowId (optional): Workflow ID to filter by
format (optional): Output format - mmd (text), png (image), or svg (vector). Default: mmd
When to Use:
After creating or significantly changing a workflow with multiple tasks and dependencies
When the task structure is getting complex or hard to track
When the user asks to show the workflow or "visualize the tasks"
Before making major structural changes (to understand the current state)
When reviewing the critical path or blocked tasks visually
Best Practices:
Use format: "png" in most cases for the best visual experience in the LLM chat
Proactively export as image when the workflow becomes non-trivial (more than 5-6 tasks or has several dependencies)
Do not ask the user "do you want me to export the graph?" โ just do it when it adds value
If the user says "show me the workflow", "visualize the tasks", "export as image", or "show the graph" โ immediately call export_mermaid with format: "png"
After exporting the image, provide a short textual summary of the current state if helpful
Example:
{
"workflowId": "workflow-123",
"format": "png"
}get_blocked_tasksGet blocked tasks with their blocking dependencies.
Parameters:
workflowId (optional): Workflow ID to filter by
get_critical_pathGet the critical path for a workflow (longest path of dependencies).
Parameters:
workflowId (required): Workflow ID to analyze
export_workflow_bundleExport a workflow as a portable JSON bundle containing the workflow, all related tasks (including subtasks), dependencies, and metadata. The bundle can be saved and imported in a new session to recreate the workflow structure.
Parameters:
workflowId (required): The ID of the workflow to export
includeRuns (optional): Whether to include workflow run history (default: false)
humanReadableOnly (optional): Export simplified human-readable view (default: false)
Returns:
A JSON bundle containing:
workflow: Workflow metadata (name, taskIds, version, tags, templateDescription)
tasks: Array of all tasks in the workflow (including subtasks)
version: Bundle version string
exportedAt: ISO timestamp when bundle was exported
templateName: Original workflow name
tags: Optional tags from the workflow
nameToIdMap: Maps qualified names to task IDs for human-readable references
idToNameMap: Maps task IDs to qualified names for reverse lookup
humanReadableOnly: Flag indicating simplified view
Name Enrichment:
The bundle includes hierarchical qualified names for tasks (e.g., "ParentTask/ChildTask") to make the exported bundle more readable while preserving all original IDs for traceability. Each task also includes a qualifiedName field in its metadata.
Usage Example:
{
"workflowId": "workflow-123"
}Example Bundle with Name Enrichment:
{
"workflow": {
"name": "CI Pipeline",
"taskIds": ["task-1", "task-2"],
"version": "1.0.0",
"tags": ["ci", "production"]
},
"tasks": [
{
"id": "task-1",
"name": "Build",
"metadata": {
"qualifiedName": "Build"
},
"dependencies": []
},
{
"id": "task-2",
"name": "Test",
"parentTaskId": "task-1",
"metadata": {
"qualifiedName": "Build/Test"
},
"dependencies": ["task-1"]
}
],
"version": "1.0.0",
"exportedAt": "2024-01-01T00:00:00.000Z",
"templateName": "CI Pipeline",
"nameToIdMap": {
"Build": "task-1",
"Build/Test": "task-2"
},
"idToNameMap": {
"task-1": "Build",
"task-2": "Build/Test"
}
}Best Practices:
Export workflows as templates for reuse across projects
Save bundles to version control for workflow documentation
Use tags to categorize workflow templates
Export before major refactoring to preserve workflow structure
Use qualified names in nameToIdMap for human-readable task references
The bundle is fully importable with all original IDs preserved
import_workflow_bundleImport a workflow bundle to create a new workflow. The bundle should be a JSON object containing workflow, tasks, and metadata. All task IDs are remapped during import to avoid conflicts. Supports name prefixing, deduplication strategies, and name-based resolution.
Parameters:
bundle (required): The workflow bundle to import (JSON object with workflow, tasks, version, exportedAt, etc.)
namePrefix (optional): Prefix to add to all task and workflow names (useful for avoiding name conflicts)
deduplication (optional): Deduplication strategy for imported tasks (skip, reuse, error, none; default: none)
nameRemapping (optional): Map of original task IDs to new task names for custom renaming during import
Returns:
newWorkflowId: ID of the newly created workflow
taskIdMap: Mapping from original task IDs to new task IDs
Workflow name and task count
Name-Based Resolution:
The import process supports both task IDs and qualified names in dependency references. If the bundle includes nameToIdMap, you can reference tasks by their hierarchical names (e.g., "ParentTask/ChildTask") instead of IDs. This makes manual bundle editing and customization easier.
Usage Example:
{
"bundle": {
"workflow": {
"id": "original-workflow-id",
"name": "CI Pipeline",
"taskIds": ["task-1", "task-2"],
"createdAt": "2024-01-01T00:00:00.000Z",
"updatedAt": "2024-01-01T00:00:00.000Z",
"version": "1.0.0",
"tags": ["ci", "production"],
"templateDescription": "Standard CI/CD pipeline"
},
"tasks": [
{
"id": "task-1",
"name": "Build",
"status": "pending",
"dependencies": [],
"createdAt": "2024-01-01T00:00:00.000Z",
"updatedAt": "2024-01-01T00:00:00.000Z"
}
],
"version": "1.0.0",
"exportedAt": "2024-01-01T00:00:00.000Z",
"templateName": "CI Pipeline",
"tags": ["ci", "production"],
"nameToIdMap": {
"Build": "task-1"
}
},
"namePrefix": "Project A - ",
"deduplication": "none",
"nameRemapping": {
"task-1": "Custom Build Name"
}
}Best Practices:
Use namePrefix when importing the same template multiple times to avoid name conflicts
Use deduplication: "skip" to avoid creating duplicate tasks if similar tasks already exist
Use nameRemapping to customize task names during import for specific project needs
Review the taskIdMap to understand how IDs were remapped
After import, use start_workflow_execution to begin executing the imported workflow
Save bundle files in a templates directory for easy reuse
The import process is backward compatible with bundles that don't include name maps
Workflow Template Lifecycle:
Export a working workflow as a template using export_workflow_bundle
Save the bundle JSON to a file or version control
Import the bundle in a new session using import_workflow_bundle
Customize with namePrefix and appropriate deduplication strategy
Execute the imported workflow using start_workflow_execution
Common Use Cases:
Workflow Templates: Create reusable workflow patterns (CI/CD, deployment, testing)
Cross-Project Sharing: Share workflows between different projects or teams
Backup/Restore: Save workflow state before major changes
Documentation: Use bundles as documentation of workflow structure
Testing: Import test workflows in isolated environments
get_statsGet statistics about tasks and workflows.
clear_allClear all tasks and workflows.
save_stateManually save the current state to storage.
get_versionGet the version information of this task orchestrator MCP server.
Create initial tasks with no dependencies:
{
"name": "Install dependencies"
}Create dependent tasks using RichDependency:
{
"name": "Run tests",
"dependencies": ["task_1234567890_abc"]
}Or with rich dependency object:
{
"name": "Run tests",
"dependencies": [
{
"taskId": "task_1234567890_abc",
"type": "hard",
"onFailure": "block"
}
]
}Check which tasks can be executed: (Use get_next_tasks tool)
Complete a task using complete_task:
{
"id": "task_1234567890_abc",
"result": {
"status": "success",
"duration": "30s"
}
}Check if dependent task can now be executed: (Use can_execute tool)
Create multiple tasks with dependencies as needed
Create a workflow:
{
"name": "CI Pipeline",
"taskIds": ["task_1_id", "task_2_id", "task_3_id"]
}The agent_mcp_task_orchestrator supports true dependency-aware workflow execution that respects the full task dependency graph (not just linear execution). This enables parallel execution of independent tasks within a workflow.
๐ Parallel Execution - Independent tasks can run simultaneously (e.g., frontend and backend builds)
๐ Dependency Graph - Full DAG support, not just linear sequences
โญ๏ธ Automatic Progression - System automatically finds newly unlocked tasks after dependencies complete
๐ State Tracking - Workflow runs track completed, active, and blocked tasks
๐ก๏ธ Error Handling - Failed tasks with retry limits are handled gracefully
๐ค Agent-Friendly - Clear responses showing exactly what tasks to work on next
โ Backward Compatible - Existing linear workflows continue to work seamlessly
File logging is disabled by default. To enable logging of tool calls and LLM responses, set the TASK_ORCHESTRATOR_LOG=true environment variable.
When enabled, logs are written to the output directory (default: ~/.task-orchestrator/output/) and organized by date:
output/
โโโ task-orchestrator-log-2024-06-22.json
โโโ task-orchestrator-log-2024-06-23.json
โโโ ...Enable logging:
TASK_ORCHESTRATOR_LOG=true node dist/index.jsOr in your MCP client config:
{
"mcpServers": {
"task-orchestrator": {
"command": "node",
"args": ["/path/to/dist/index.js"],
"env": {
"TASK_ORCHESTRATOR_LOG": "true"
}
}
}
}Tool Request Logs (automatically logged):
timestamp: When the tool was called
type: "tool_request"
tool: Name of the tool
arguments: Arguments passed to the tool
result: Result returned by the tool
LLM Response Logs (for debugging LLM โ Agent interactions):
timestamp: When the LLM response was logged
type: "llm_response"
content: Full text from LLM that suggested tool calls
toolCalls: Array of tool calls suggested by the LLM
relatedTools: List of tool names extracted from tool calls
To trace exactly what the LLM suggested that caused tool calls (e.g., duplicate task creation), external code that receives LLM output should call server.logLLMResponse() before tool execution:
import { TaskOrchestratorMCPServer } from './index.js';
const server = new TaskOrchestratorMCPServer();
// When you receive an LLM response with tool calls
const llmMessage = "I'll create tasks for the feature implementation...";
const toolCalls = [
{
function: {
name: "create_tasks",
arguments: { tasks: [...] }
}
}
];
// Log the LLM response before executing tools
await server.logLLMResponse(
llmMessage,
toolCalls
);
// Then proceed with tool execution...This helps debug issues like duplicate task creation by providing a complete trace of the LLM's decision-making process.
# Build
npm run build
# Watch mode
npm run dev
# Start server
npm startTasks and workflows are stored in a JSON file at the path specified by SEQUENTIAL_STORAGE_PATH. The file contains:
{
"tasks": {
"task_id": {
"id": "task_id",
"name": "Task name",
"description": "Task description",
"status": "pending",
"dependencies": [],
"createdAt": "2024-06-22T10:00:00.000Z",
"updatedAt": "2024-06-22T10:00:00.000Z",
"result": null,
"error": null,
"metadata": {}
}
},
"workflows": {
"workflow_id": ["task_id_1", "task_id_2"]
}
}MIT
Advance a workflow run by finding newly unlocked tasks after tasks are completed/failed. Returns detailed information including completed tasks, failed tasks, newly ready tasks, blocked tasks, workflow status, and a human-readable summary. Supports smart failure handling that only fails the workflow when no paths forward remain (unless continueOnFailure is enabled).
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the workflow run to advance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the returned information (completed tasks, failed tasks, etc.) and explains smart failure handling. It is clear about what the tool does, though it does not explicitly state whether the operation is read-only or mutating, which slightly 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 56 words, with purpose stated first, followed by return details and failure handling. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is complete. It explains when to use the tool, what it returns, and key behavior (failure handling). The listed return fields compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'runId', so baseline is 3. The description does not add additional meaning beyond what the schema already provides ('The ID of the workflow run to advance').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'advance' and the resource 'workflow run'. It distinguishes from sibling tools like 'get_next_tasks' by specifying it actively advances the run and returns newly unlocked tasks, not just lists them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'after tasks are completed/failed', providing clear context. However, it does not mention when not to use it or suggest alternative tools, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a task can be executed based on its dependencies
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'check', implying a read-only operation. It does not disclose what happens if dependencies are unmet (e.g., returns false vs throws error) or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one input and no output schema, but missing details like return type or behavior when dependencies are not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds 'based on its dependencies', providing context beyond the parameter schema. The baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and resource 'task', and distinguishes from siblings like execute_task or fail_task by specifying it checks based on dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., before execute_task) or when not to use it. The implied usage is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean up old workflow runs based on age or count
| Name | Required | Description | Default |
|---|---|---|---|
| maxAgeMs | No | Maximum age in milliseconds for workflow runs to keep (optional) | |
| maxCount | No | Maximum number of workflow runs to keep (optional, keeps most recent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Clean up', which implies deletion but does not disclose whether the operation is destructive, reversible, requires permissions, or triggers side effects. The behavioral impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, with no irrelevant information. It is appropriately concise and front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description fails to cover essential behavioral details like idempotency, permanent deletion, or handling of optional parameters when both are omitted. The low complexity does not fully compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both maxAgeMs and maxCount described adequately in the schema. The tool description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clean up') and resource ('old workflow runs') with clear criteria ('based on age or count'). It distinguishes from sibling tools like get_workflow_run and list_workflow_runs, which do not perform cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete_workflow or other cleanup tools. It does not mention prerequisites, when not to use it, or any ranking relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all tasks and workflows
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Clear' is vagueโdoes it delete permanently, soft-delete, or reset? There is no mention of side effects, permissions, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. However, it is brief to the point of being under-specifying, missing important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any explanatory notes, the description fails to provide sufficient context about the tool's behavior, scope, or effect of clearing all tasks and workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no additional parameter information, but none is needed since the schema fully covers this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Clear' and the resource 'all tasks and workflows'. It is specific about the scope but does not differentiate from siblings like 'delete_task' or 'delete_workflow' which are more targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It is implied to be a bulk operation, but there is no explicit comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one or more tasks with optional dependencies and parent tasks
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that tasks can have dependencies and parent tasks, but omits critical behavioral traits like idempotency, validation behavior, retry handling, or return value. The user learns nothing about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that covers the core functionality without extraneous words. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (array of objects, optional fields) and no output schema, the description provides no information about return values, error handling, or how the created tasks relate to workflows. Given the extensive sibling tools list, more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter documented in the schema. The description rephrases the 'dependencies' and 'parentTaskId' but adds no new semantic context beyond the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates tasks, specifying that it can handle multiple tasks with optional dependencies and parent tasks. This verb+resource description differentiates it from sibling tools like delete_task, update_task, or execute_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as create_workflow or update_task, nor does it mention prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workflow (group of tasks in sequence)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the workflow | |
| taskIds | Yes | Array of task IDs in the workflow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral aspects, but it only describes the basic action. Missing details like permissions, side effects, constraints on names, or what happens if parameters are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently concise. Could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with two required parameters and 24 sibling tools, the description is too sparse. It doesn't explain how taskIds work, whether tasks must exist, or what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. Description adds no additional meaning beyond restating 'workflow' and 'sequence'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'workflow', and defines it as 'group of tasks in sequence'. It distinguishes from sibling tools like 'create_tasks' and 'delete_workflow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any preconditions or postconditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Delete a task by ID', lacking details on permanence, cascading effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single phrase. No wasted words, but could be slightly expanded to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description is incomplete. It does not explain behavior like permanent deletion or relationship to subtasks, which is relevant given sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the id parameter with description. Tool description adds no further value beyond the schema's parameter description, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Delete' and resource 'task' are clearly stated. However, no differentiation from sibling tools like clear_all, reset_task, or retry_task, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use delete_task versus alternatives. Does not specify prerequisites, such as whether the task exists or if user has permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a workflow by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the workflow to delete |
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 only says 'Delete' without detailing any consequences, prerequisites, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and no wasted words. It is appropriately concise for a straightforward delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but sufficient for a simple delete operation with one parameter. However, given the lack of annotations and output schema, additional context about return values or effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in the schema is sufficient. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a workflow by ID', specifying the verb and resource. It distinguishes from sibling tools like delete_task and cleanup_workflow_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as cleanup_workflow_runs or when not to use it. The description implies usage but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a task as completed with a result
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to execute | |
| result | No | The result of the task execution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It does not disclose whether the operation is idempotent, what happens if the task is already completed, or if the result is mandatory. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words or repetition. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description omits crucial details like return value, side effects, and how this tool relates to siblings. Incomplete for an execution action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described adequately. The description adds no extra meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: marking a task as completed and attaching a result. It uses a specific verb-resource pair and differentiates from sibling tools like 'fail_task' by implying success.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'fail_task' or 'retry_task'. Missing context on prerequisites or expected usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a task as failed with an error message
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to fail | |
| error | Yes | The error message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the action and input, but does not disclose side effects (e.g., workflow state change, finality). Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Efficiently conveys core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters and no output schema, description is minimally sufficient. Lacks details on workflow impact or error handling behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%, so parameter descriptions already exist. Description only reiterates 'with an error message', adding little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Mark' and resource 'task', with detail 'with an error message'. Clearly distinguishes from siblings like 'retry_task' or 'reset_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., 'retry_task', 'reset_task'). Agent must infer from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tasks that are ready to execute (all dependencies completed)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It states the tool gets tasks that are ready, which is a read operation with no side effects. However, it lacks details on scope, ordering, permissions, or what 'all dependencies completed' means exactly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded. No wasted words, efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain return values (e.g., format or fields of the tasks). Additionally, with sibling tools like get_next_workflow_tasks, more differentiation is needed. The description feels incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. The description adds no param-specific info but is adequate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb (Get), resource (tasks), and condition (all dependencies completed), distinguishing it from sibling tools like list_tasks (which lists all tasks) and get_task (which gets a specific task).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for tasks ready for execution, but does not mention exclusions or contrast with similar tools like get_next_workflow_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tasks that are ready to execute within a specific workflow (dependency-aware). Useful for checking what can be worked on next in a workflow context.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to get ready tasks for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only mentions 'dependency-aware,' which hints at behavior but does not disclose safety (read-only), idempotency, or potential side effects. The lack of explicit behavioral context limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action ('Get tasks that are ready to execute'), and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and its use case, but lacks details about the output format (e.g., what properties the returned tasks have). With no output schema, this omission affects completeness for an agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the single parameter (workflowId). The tool description does not add extra semantics beyond restating the purpose. Since schema coverage is 100%, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves tasks that are ready to execute in a specific workflow, with dependency awareness. This distinguishes it from the sibling get_next_tasks (which likely operates without workflow scope) and other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'useful for checking what can be worked on next in a workflow context,' which implies when to use. However, it does not explicitly exclude using other tools like get_next_tasks or mention prerequisites, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about tasks and workflows
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose whether it's read-only, potential side effects, or what exactly 'statistics' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 6 words, no redundancy, perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, description lacks details on return format, scope of statistics, and differentiation from list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline score of 4 is appropriate as description adds no param info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves statistics about tasks and workflows, distinguishing it from sibling tools like get_task or list_tasks, though 'statistics' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over others (e.g., get_task, list_workflows) or what kind of statistics it provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all subtasks of a parent task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The parent task ID to get subtasks for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states 'Get all subtasks' without specifying whether this is read-only, whether it returns direct or recursive subtasks, any permissions required, error handling for missing parent, or limits on result size. These omissions leave significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the tool's purpose. It is front-loaded and contains no unnecessary words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter, no output schema, and no annotations, the description is minimally adequate but lacks detail on return format, pagination, recursion behavior, and edge cases. It is complete enough for a basic retrieval but falls short of fully informing an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, and the description adds no additional meaning beyond what the schema already provides ('The parent task ID to get subtasks for'). The description is effectively redundant with the parameter description, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'subtasks', specifying the action of retrieving all subtasks for a given parent task. This distinguishes it from siblings like 'get_task' (which retrieves a single task) and 'list_tasks' (which lists tasks without parent context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the parent task must exist) or scenarios where another tool (like 'get_next_tasks') might be more appropriate. This lack of context forces the agent to infer usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific task by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention what happens if the task is not found (e.g., error or null), required permissions, whether the retrieval is cached, or any rate limiting. For a read-only operation, transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the key action and resource. It avoids unnecessary words but could be slightly more informative without adding length. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no output schema), the description is minimal but functional. However, it lacks information about the return format (e.g., full task object) and error handling. An agent would need to infer these from context, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'id' is described as 'The ID of the task to retrieve'). The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific task by ID' clearly states the action (get) and the resource (a specific task), with a precise identifier method (by ID). This distinguishes it from sibling tools like list_tasks (which returns multiple tasks) or get_subtasks (which returns subtasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_tasks, get_subtasks, or get_workflow. There is no mention of prerequisites, conditions, or situations where this tool should not be used. With 24 sibling tools, this is a significant omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version information of this sequential MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states a simple read operation but does not specify the exact format of version information or any potential side effects (though unlikely). Adequate for a straightforward getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, immediately conveys the purpose. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is complete enough for the agent to understand the tool's function. Could optionally explain the return value, but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'version information of this sequential MCP server', distinguishing it from sibling tools that manage workflows and tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the purpose is so distinct that usage is implied. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a workflow by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the workflow to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'get', which implies read-only, but does not disclose behaviors like error handling when ID is invalid, permissions required, or idempotency. With no annotations, this is insufficient for a comprehensive understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous information. Efficient and front-loaded with the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 required param, no output schema), the description is minimally adequate. However, it does not specify return format or error conditions, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'id' described. Description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action and resource: 'Get a workflow by ID'. It distinguishes from siblings like 'get_workflow_run' and 'list_workflows', but lacks additional context about what a workflow is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'list_workflows' or 'get_workflow_run'. No conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a workflow run by ID
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the workflow run to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states 'Get' which implies a read operation, but does not mention error behavior (e.g., what happens if the run ID does not exist), permission requirements, or any side effects. The description adds minimal behavioral context beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get a workflow run by ID'. It is concise, front-loaded with the action and resource, and contains no extraneous words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (1 parameter, no nested objects, no output schema), the description is incomplete. It does not mention what the tool returns or any response format. Since there is no output schema, the description should clarify the return value (e.g., 'Returns the workflow run details'), but it omits that entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'runId' has a schema description: 'The ID of the workflow run to retrieve'). According to the guidelines, when coverage is high (over 80%), the baseline score is 3. The tool description does not add any additional meaning about the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a workflow run'), with the parameter 'runId' specifying the identifier. This differentiates it from sibling tools like 'list_workflow_runs' that retrieve multiple runs, or 'cleanup_workflow_runs' which performs a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or compare with siblings such as 'list_workflow_runs' or 'get_next_workflow_tasks'. The agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks or filter by status
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter tasks by status (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It implies a read operation but does not explicitly state non-destructiveness, pagination behavior, rate limits, or whether the list is exhaustive. The statement 'list all tasks or filter by status' is insufficient to infer safety or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with 'list all tasks' which communicates the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return format, ordering, or limits. It lacks these details. Additionally, with many sibling tools, the description fails to help an agent understand what tasks are included (e.g., all tasks in system or per user).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 100% description coverage and an enum, which fully defines the parameter. The description's mention of 'filter by status' adds no new semantic value beyond the schema, so baseline 3 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'tasks', and mentions optional filtering by status, which distinguishes it from sibling tools like get_task that retrieve a single task. However, it does not specify the scope (e.g., all tasks in workspace) nor differentiate from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like get_task, list_workflow_runs, or search-based tools. The description does not include context for when filtering is appropriate or when to use alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workflow runs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'List all workflow runs', omitting any details about ordering, filtering, rate limits, or side effects. The agent cannot infer safety or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), which is concise but under-specified. It lacks critical context for an agent to use it effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description should provide more context such as what a workflow run is and how this tool differs from get_workflow_run or delete_workflow_run. It is incomplete for an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters, so no additional parameter description is needed. The description correctly implies the tool takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'workflow runs', making the basic purpose evident. However, it does not distinguish from sibling list tools like list_workflows, list_trees, or list_strategies, so it loses one point for lack of specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives such as list_workflows, get_workflow_run, or other list tools. The agent is given no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workflows
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the action but gives no information about side effects, read-only nature, or any other behavioral traits. This is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loaded, and contains no superfluous content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides the basic purpose. However, it lacks information about return format, ordering, or scope, which would help an agent understand the output. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description does not need to add parameter details. It meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all workflows' clearly states the verb (list) and resource (workflows), making the purpose obvious. However, it does not differentiate from sibling tools like 'list_workflow_runs' or 'get_workflow', which list related but distinct resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other list tools such as 'list_strategies' or 'list_trees'. An agent would have to infer from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a task as in progress
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to mark as in progress |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states the action. It does not disclose idempotency, side effects, or behavior when the task is already in progress.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is well-structured but could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is minimally adequate but lacks details on typical usage, expected outcomes, or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional meaning beyond the already-documented 'id' parameter. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark a task) and the target state (in progress). It distinguishes from sibling tools like 'fail_task' or 'delete_task' by specifying the exact state change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset a task back to pending status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to reset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavioral traits. It does not specify destructive potential, permissions needed, whether task must be in a particular state, or what happens to dependent tasks. Insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Highly concise and front-loaded. Minor improvement possible by including the target state more prominently, but effective overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is minimal. It does not mention return values, side effects, or state constraints. With many sibling tools, more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already describes 'id' as 'The ID of the task to reset'. Description adds no further parameter context; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the verb 'reset' and resource 'task' with target state 'back to pending status', clearly indicating the action and outcome. Differentiates from siblings like delete_task or fail_task, but could be more explicit about the initial state requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as retry_task, mark_in_progress, or advance_workflow_run. Agent lacks context to choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry a failed task, incrementing retry count
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to retry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that retry count is incremented, but does not clarify whether the task is re-executed, what status changes occur, or what happens if the task is not failed. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it lacks depth appropriate for the tool's role. It could be improved with a bit more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description is minimally adequate. However, it omits information about return values, error conditions, and when the operation is valid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', and the description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb 'Retry' on a resource 'failed task', and the incrementing retry count adds context. It differentiates from siblings like fail_task or reset_task by focusing on re-attempting a failed task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use retry_task versus alternatives like reset_task or execute_task. The description lacks any context for appropriate usage, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually save the current state to storage
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It reveals that the operation persists state but does not state whether it overwrites a previous snapshot, whether it is idempotent, whether prior changes must exist, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word earns its place, and the main verb 'save' appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema, the description gives the core operation but leaves scope ambiguous: 'current state' could mean session, tree, or global storage. It also does not explain return or success behavior, so an agent can call it but cannot fully predict its consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there are no parameter meanings for the description to clarify. Per the zero-parameter baseline, the description adequately covers the input contract by not omitting anything relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('save') and a clear object ('current state to storage'), so an agent can infer the tool's basic purpose. It does not explicitly differentiate from sibling tools, but no sibling offers an equivalent save/persistence operation, making the purpose reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool versus alternatives. The word 'Manually' implies it is used for explicit, user-triggered persistence, but no conditions, prerequisites, or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start execution of a workflow with dependency-aware task initialization. Automatically finds and marks all initially ready tasks as in_progress. Returns runId and list of ready tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It reveals dependency-aware initialization and return values but lacks details on idempotency, error handling, permissions, or side effects on existing runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: first sentence defines core behavior, second sentence states return. Front-loaded with key action verbs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides basic behavioral info but omits error conditions, prerequisites (e.g., workflow existence, valid state), and full impact on task states beyond ready tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (workflowId) already described. The description does not add new meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: starting workflow execution with dependency-aware task initialization. It distinguishes itself from siblings like execute_task or advance_workflow_run by specifying automated task state management and return of runId and ready tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to initiate a workflow run) but provides no explicit guidance on alternatives, prerequisites, or when not to use (e.g., if tasks should be executed individually).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the task to update | |
| name | No | New name for the task | |
| description | No | New description for the task | |
| dependencies | No | New dependencies for the task | |
| parentTaskId | No | New parent task ID for the task | |
| metadata | No | New metadata for the task |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the bare function. It does not reveal whether updates are partial or full, whether idempotent, or any side effects like affecting dependent tasks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded and efficient, but perhaps too brief. It earns its place but sacrifices informative detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters including a nested object and an array, the description is insufficient. No output schema exists, and the description does not clarify semantics like merging vs overwriting metadata or dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are documented in the input schema with descriptions (100% coverage), so the baseline is 3. The description adds no extra meaning; it does not explain how parameters interact or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing task' clearly states the verb (update) and resource (task), but does not distinguish this tool from siblings like delete_task or execute_task. It is not a tautology because it adds the word 'existing', but it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or any context about its role among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0advance_workflow_runcan_executecleanup_workflow_runsclear_allcreate_taskscreate_workflowdelete_taskdelete_workflowexecute_taskfail_taskget_next_tasksget_next_workflow_tasksget_statsget_subtasksget_taskget_versionget_workflowget_workflow_runlist_taskslist_workflow_runslist_workflowsmark_in_progressreset_taskretry_tasksave_statestart_workflow_executionupdate_taskScored across 27 tools
Each tool has a clearly distinct purpose, with no ambiguity between similar operations like get_next_tasks and get_next_workflow_tasks, as descriptions clarify scope.
All tool names follow a consistent verb_noun snake_case pattern, such as create_tasks, get_workflow, and advance_workflow_run, with no mixing of conventions.
27 tools is on the higher side but appropriate for the complexity of sequential workflow management, covering CRUD, status transitions, execution control, and utilities without being excessive.
The tool surface covers the full lifecycle: creation, execution, status management, progression, cleanup, and monitoring, with no obvious gaps for the domain.
Task management for teams building with AI agents. Agents claim tasks and report progress.
Shared task queue for humans and AI agents: leases, handoffs, approvals and signed receipts.
Task tracking built for coding agents. Work is leased, so two agents never take the same SubTask.
Work management where AI agents are first-class members: tasks, projects, memory over hosted MCP
