Sequential MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SEQUENTIAL_OUTPUT_DIR | Yes | Directory where activity logs are stored | |
| SEQUENTIAL_STORAGE_PATH | Yes | Path to the JSON file where tasks and workflows are stored |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_tasksB | Create one or more tasks with optional dependencies and parent tasks |
| update_taskC | Update an existing task |
| delete_taskC | Delete a task by ID |
| get_taskB | Get a specific task by ID |
| get_subtasksB | Get all subtasks of a parent task |
| list_tasksC | List all tasks or filter by status |
| execute_taskC | Mark a task as completed with a result |
| fail_taskA | Mark a task as failed with an error message |
| mark_in_progressC | Mark a task as in progress |
| reset_taskC | Reset a task back to pending status |
| retry_taskC | Retry a failed task, incrementing retry count |
| get_next_tasksA | Get tasks that are ready to execute (all dependencies completed) |
| can_executeB | Check if a task can be executed based on its dependencies |
| create_workflowC | Create a workflow (group of tasks in sequence) |
| get_workflowB | Get a workflow by ID |
| list_workflowsB | List all workflows |
| delete_workflowC | Delete a workflow by ID |
| start_workflow_executionA | 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. |
| advance_workflow_runA | 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). |
| get_workflow_runB | Get a workflow run by ID |
| list_workflow_runsC | List all workflow runs |
| get_next_workflow_tasksA | 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. |
| get_statsB | Get statistics about tasks and workflows |
| clear_allB | Clear all tasks and workflows |
| save_stateB | Manually save the current state to storage |
| get_versionA | Get the version information of this sequential MCP server |
| cleanup_workflow_runsB | Clean up old workflow runs based on age or count |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.