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., "@cascade Refactor the login flow and update the associated tests"
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.
You describe a task from inside Claude Code or Codex. Cascade breaks it into a dependency graph of smaller subtasks, then runs as many of them at once as their dependencies allow, each one handled by its own CLI agent process. You watch it happen live in a browser tab, and your main session reports progress back to you as pieces finish.
Context is assembled per node and all information flows back to your main session.
Cascade is built on the principles of graph engineering: the idea that agent work should be described as a graph of bounded nodes and typed edges, not forced through a single linear stack.
A linear workflow — one step unlocking the next — works fine when every step genuinely depends on the one before it. But most real tasks aren't that tidy. They contain work that could run in parallel, evidence that would overload a single context window if crammed into one pass, and checkpoints that need precise placement rather than one fixed spot in a queue. Forcing that shape into a line either serializes work that didn't need to wait, or overloads a single model call with everything at once.
A graph fixes this by giving each unit of work a boundary. A node has a clear task and explicit success criteria, so it can be validated and retried on its own without rerunning everything around it. An edge carries meaning, not just order — it says what evidence or result actually needs to cross from one node to the next, so downstream work receives exactly the context it needs and nothing it doesn't. Independent branches run concurrently because nothing in the graph says they have to wait, and a failure on one branch stays contained to the work that actually depended on it.
This is what lets Cascade fan a task out across parallel CLI agents instead of one long serial run: the graph decides what's ready, what's blocked, and what context moves where, so the model doing the work always sees a scoped slice of the problem instead of an ever-growing prompt.
Cascade runs as a local MCP server over stdio. It holds no model access of its own — it validates graphs, schedules work, and shells out to the claude and codex CLIs already configured on your machine, using whatever models and permissions those CLIs already have.
Register it once with either host. No clone or build required — npx fetches the published package on first run:
claude mcp add --scope user cascade -- npx -y @pepps233/cascade
codex mcp add cascade -- npx -y @pepps233/cascade--scope user matters: without it the server is registered against a single project directory and /cascade will silently have no tools anywhere else. Verify with claude mcp list — cascade should report ✔ Connected.
To get the /cascade entry point, copy the skill into place:
mkdir -p ~/.claude/skills/cascade
curl -fsSL https://raw.githubusercontent.com/Pepps233/cascade/main/skills/cascade/SKILL.md \
-o ~/.claude/skills/cascade/SKILL.mdThe skill pre-approves the cascade tools for the turn it runs in, so the orchestration loop does not prompt for each call. For Codex, copy commands/cascade-codex.md to ~/.codex/prompts/cascade.md instead. Both templates drive the same MCP tools, so behavior is identical regardless of which CLI you're driving the graph from.
git clone https://github.com/Pepps233/cascade.git && cd cascade
npm install && npm run build
claude mcp add --scope user cascade -- node "$(pwd)/dist/server.js"The server starts a local viewer on the first free port from 7317 upward the moment a graph is created, and opens it in your browser automatically.
Tool | What it does |
| Validates a proposed graph (cycles, dangling edges, duplicate ids), persists it, and opens the live viewer. Does not start any work. |
| Marks ready nodes and spawns their workers. Returns immediately — it does not wait for anything to finish. |
| Blocks until a node changes state or a timeout elapses. This is what lets the orchestrating session report progress as it happens instead of polling or going silent. |
| Returns an immediate snapshot: every node's state, truncated results, and counts. |
| Returns the full result and recent log output for a single node. |
| Stops a running graph, terminating any workers still in flight. |
Cancel a running graph: SIGTERM all running workers and mark them failed.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete behavior: 'SIGTERM all running workers and mark them failed.' This goes beyond the generic action of cancellation and provides useful operational detail, especially since no annotations are provided.
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, front-loaded with the verb, and contains zero wasted words. It is appropriately concise for the tool's simplicity.
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 and no output schema, the description covers the essential action and effect. It could mention the post-cancel graph state, but it is adequate for selecting and invoking 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 description does not explicitly explain the graph_id parameter, but with only one parameter and a self-explanatory name, the meaning is inferable from the phrase 'a running graph.' The schema coverage is 0%, so the description partially compensates but could have been more explicit.
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 ('Cancel') and resource ('a running graph') to clearly state what the tool does. This distinguishes it from sibling tools like start_execution and create_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear precondition ('a running graph') that tells the agent when to use this tool. While it does not explicitly name alternatives, the context is sufficient for a cancellation operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a DAG of subtasks to be executed by parallel CLI agent workers. Validates the graph and starts the live viewer, but does not execute anything.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for workers; defaults to the server process cwd | |
| task | Yes | The original user task being decomposed | |
| edges | No | ||
| nodes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses meaningful behavioral traits: validation of the graph, starting a live viewer, and not executing anything. It does not cover error behavior or viewer lifecycle, but the core side effects are surfaced.
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?
One sentence delivers purpose, validation behavior, viewer behavior, and the critical non-execution caveat. No filler or redundancy.
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 the tool's role but omits return behavior and post-creation steps. Given no output schema and 4 parameters, more guidance about what the agent should do after creating the graph 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 only 50% (task and cwd have descriptions; nodes and edges do not). The description does not compensate by explaining how nodes/edges form the DAG or how they relate to execution. An agent would need extra reasoning to construct valid node and edge objects.
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 ('Create a DAG of subtasks') and clearly identifies the resource and scope. It also distinguishes itself from sibling execution tools by explicitly stating it does not execute anything.
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 this tool (to define a graph before execution) and clarifies it does not run tasks, suggesting execution belongs to another sibling. However, it doesn't explicitly name an alternative like start_execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an immediate snapshot of a graph: per-node state, truncated results, and counts.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses 'truncated results' and 'immediate snapshot,' but does not clarify whether the operation is read-only, whether it triggers computation, or what happens for missing/invalid graph IDs.
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 redundancy. Every word contributes to the meaning, making it highly concise and well-structured.
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 one-parameter tool, the description covers the primary output aspects (per-node state, truncated results, counts). However, with no output schema or annotations, it lacks detail on error cases and the relationship to sibling tools, leaving moderate gaps.
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 0% and the description does not explicitly describe graph_id. While the parameter is self-evident from the tool name, the description fails to add meaning beyond the bare schema, thus not compensating for low coverage.
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 obtains an immediate snapshot of graph state, specifying the exact components returned (per-node state, truncated results, counts). This distinguishes it from siblings like get_node_output, which targets individual node outputs.
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 guidance is provided. The description does not mention when to use this tool over get_node_output or other siblings, nor any exclusions. The agent must infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full result and log tail for a single node.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | ||
| graph_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation but fails to mention error handling, authentication needs, or whether partial results can be returned. The description adds minimal transparency beyond the basic function.
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 zero waste. It efficiently communicates the core function without unnecessary 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?
The tool is simple, but the description is incomplete: no output schema, no annotations, and no explanation of parameters or error cases. The agent may not understand why graph_id is required or what 'full result and log tail' concretely returns.
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 0%, and the description does not explain the purpose or relationship of graph_id and node_id. The agent must infer meaning from parameter names alone, with no added context from the description.
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 a specific verb ('Get') and resource ('full result and log tail for a single node'), distinguishing it from sibling tools like start_execution or get_graph_state, which focus on graph lifecycle or aggregate state.
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 vs alternatives like get_graph_state. It doesn't mention prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin executing a graph. Non-blocking: marks ready nodes, spawns workers, and returns immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_id | Yes | ||
| max_concurrency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides key behavioral traits: non-blocking, marks ready nodes, spawns workers, returns immediately. It adds meaningful context beyond the name, though it omits edge cases like concurrency limits or error behavior.
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 that is front-loaded with the primary action, and every word contributes value. Excellent 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?
The description covers the core behavior but lacks parameter explanations and potential side effects. Given the simple tool and absence of output schema, it is adequate but has clear gaps.
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 0%, and the description does not explain graph_id or max_concurrency. It fails to add any meaning beyond the bare schema properties.
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 'Begin executing a graph' with a specific verb and resource, and the non-blocking detail distinguishes it from sibling tools like wait_for_change and cancel_execution. Clearly conveys what the tool does.
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 non-blocking nature implies when to use it (when you want to start execution without waiting), but there is no explicit guidance on alternatives or exclusions. Sibling tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block until any node in the graph changes state, or until the timeout elapses. On a change, returns the changed nodes, a full snapshot, and whether the graph is fully terminal. On a timeout, the snapshot is omitted since nothing moved.
| Name | Required | Description | Default |
|---|---|---|---|
| graph_id | Yes | ||
| timeout_ms | No | Overall wait budget in milliseconds; defaults to 600000 (10 minutes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the blocking nature, timeout behavior, and the differing return values on change vs. timeout (snapshot omitted when timeout). This provides meaningful context beyond basic read/write hints, though it does not cover error cases 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?
The description is two sentences long, front-loaded with the core purpose and immediately followed by behavioral details. Every sentence adds value, with no wasted words or repetition.
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 tool has only two parameters and no output schema, so the description covers the key behavioral aspects well: what triggers a result, what is returned on change, and what happens on timeout. It lacks error handling details (e.g., invalid graph_id), but for a simple blocking wait tool, the provided information is sufficient for most use 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 description coverage is 50% (timeout_ms has a description, graph_id does not). The description implies graph_id refers to the graph being watched, but adds no new detail about parameter format or constraints. It does not fully compensate for graph_id's missing schema description, but the parameter is self-explanatory from the tool name and context.
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 function: it waits (blocks) until a node in the graph changes state or a timeout occurs. It also specifies the resource (graph nodes) and distinguishes itself from sibling tools like start_execution or get_graph_state by focusing on the blocking wait behavior.
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 usage as a blocking wait for state changes, but does not explicitly state when to use this tool versus alternatives like polling with get_graph_state. No exclusions or alternative recommendations are provided, so guidance is only implied.
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.
v0.1.0cancel_executioncreate_graphget_graph_stateget_node_outputstart_executionwait_for_changeScored across 6 tools
Each tool serves a clear, non-overlapping purpose: create_graph defines the DAG, start_execution begins running it, wait_for_change and get_graph_state provide different monitoring modes, get_node_output fetches detailed results, and cancel_execution stops execution. There is no confusion between them.
Tool names follow a mostly consistent verb-first pattern in snake_case (start_execution, create_graph, cancel_execution). The get_ prefix is used consistently for retrieval tools, but wait_for_change breaks the pattern slightly by combining a phrasal verb with a preposition. Overall naming is readable and predictable.
With 6 tools, the server is well-scoped for graph-based execution management. Each tool covers a distinct phase of the workflow without redundancy or bloat.
The tool surface covers the full execution lifecycle: create, start, monitor, inspect outputs, and cancel. A missing delete_graph or graph update operation is a minor gap, but not a dead end for the primary purpose of running and observing graphs.
Hosted MCP server for task-first delegation to remote workstations and workers.
MCP Server for an Agent Task Marketplace
ArcAgent MCP server for bounty discovery, workspace execution, and verified coding submissions.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
