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., "@workflow-atlas Create a workflow map for the user login process."
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.
Two tools for thinking and communicating about software, in one tiny app:
Workflows — hand-laid visual maps of a process, styled like technical drawings.
Algorithm storyboards — step-by-step animations of how an algorithm behaves, with editable parameters and per-step comments, so an idea lands as a moving picture instead of a wall of prose.
https://github.com/user-attachments/assets/6e9e2f50-b197-46b7-b3cf-c809759a2912
A zero-dependency local server serves the app and gives any AI assistant — over MCP, so it's not tied to one provider — an authoring surface: it can create and edit the algorithm storyboards, the workflow maps, and even the CSS/HTML styling, so when the assistant proposes an algorithm it can show you a moving picture instead of a wall of prose. One install serves many projects and parallel sessions: each project's content lives in a home directory, and the server routes each session to its own project automatically (see Projects).
Open source under the MIT License (see LICENSE). No build step, no npm
install, no framework — plain HTML/CSS/JS and Node built-ins.
A fully AI-driven project — by AI, for AI. Every line of code, every storyboard, and these docs were authored by AI assistants through the very MCP surface described below; humans only steer and review. The app exists to give an AI a place to show its thinking, not just describe it. Expect the quirks that come with that, and read the code before you trust it.
New projects start empty, so demos never mix with real work. To populate a fresh project with the bundled demo content (the authoring-loop and boot & serve maps, plus binary search / bubble sort / Euclid's GCD storyboards), run the server once with
WORKFLOW_ATLAS_SEED=1.
Zero install (Node ≥ 20). From this folder:
npm start # → http://localhost:5174/ (or: node server/server.mjs)Works with any MCP client. With Claude Code you don't start it yourself —
a project .mcp.json registers the server so the client spawns and manages it
(one-time: approve it when prompted). Any other MCP client can launch
node server/server.mjs over stdio just the same. The one process serves the app
and exposes the MCP tools.
The open tab live-reloads when content changes — author a spec or workflow
(this session or another) and the page refreshes itself (review autosaves are
excluded, so typing a comment never reloads under you). A server is required:
the app fetches project data from /api, and that data lives in your home dir,
not in the served folder.
When the assistant authors a workflow or storyboard (save_sheet / edit_board /
save_algorithm) and no tab is open yet, the server opens the app in your
default browser so the result is in front of you; if a tab is already open it
just live-reloads instead. Disable the auto-open with ATLAS_NO_OPEN=1.
If the port (default 5174, override with PORT) is busy, the server adapts:
if another workflow-atlas instance already holds it, this process reuses that UI
and runs as an MCP/stdio worker (the shared file watcher still live-reloads your
edits); if something unrelated holds it, the server steps to the next free port.
Local-only by design. The server binds to 127.0.0.1 and its write surface
(the MCP tools and review autosave) rejects any request that isn't same-machine,
same-origin — so a website you visit or another host on your network can't drive
it. It is unauthenticated tooling meant for your own machine; only set
ATLAS_HOST to expose it on another interface if you understand the risk.
Related MCP server: @designjs/mcp-server
Every project's content (algorithms, workflow maps, review overlays) is stored
under a home directory — ~/.workflow-atlas/projects/<project>/ by default,
override the base with $WORKFLOW_ATLAS_HOME. So one install serves many projects,
and parallel sessions stay isolated.
Routing. Each server process is bound to one project: by default the git
repo root (so an MCP client opened in repo acme — or any of its git worktrees —
authors the one acme project), else the launch directory's name when it isn't a git
repo. Set $WORKFLOW_ATLAS_PROJECT to pick one explicitly. The UI has a project
switcher (top-left) to view any project, and the active project shows in the tab title.
Isolation & concurrency. Different-project sessions never contend; writes are
atomic (temp-file + rename) and serialized by a cross-process lock, so a torn write
or two same-project sessions (e.g. parallel worktrees) can't corrupt or silently drop a
file. Each sheet also carries a rev token: an MCP edit is rejected if the sheet
changed since the assistant last read it, so it can't overwrite a concurrent human edit.
The in-app replace-all save snapshots the prior file to workflows.json.bak first.
Seeding. New projects start empty; WORKFLOW_ATLAS_SEED=1 copies the bundled
demos into a fresh project.
A workflow map is a list of sheets; each sheet is an infinite-zoom board —
a free-laid set of nodes connected by edges. The defining idea: any node
can itself contain a board (node.board), so a chart can hold a chart can hold a
chart, to unbounded depth.
Semantic zoom (level-of-detail). A node renders at the detail its on-screen size warrants: a status dot when tiny → a card (title · status · markers) → a frame that mounts its child board in place once it's large enough. Only what is both visible and big enough is in the DOM, so a deep tree stays cheap.
Seamless re-rooting — why it's truly infinite. Zoom into a node until it fills
the viewport and the renderer re-roots onto that node's child board, rebasing
the camera so cam.zoom returns to ~1. Because the zoom resets at every level, the
scale chain never underflows floating point — so nesting depth has no practical
limit (the e2e test dives 25 levels with the camera scale staying O(1)). Zoom
back out and it pops one level. A breadcrumb (top-left) shows the path, and
the URL hash mirrors it (#<sheet>/<nodeId>/<nodeId>…) so a nested view is
deep-linkable, survives reload, and Back/Forward walk the nesting.
Edges live within one board. An edge connects two nodes in the same board; a cross-level relationship is expressed by containment (nest the node inside the other's board), never by an edge — that keystone invariant is what lets a board be rendered, dived into, and validated at any depth. Drag a connection from any of a node's four sides and the edge leaves that side toward the target.
Direct manipulation. Turn on Edit to drag nodes, double-click empty canvas to drop one, double-click a node to dive in, inline-edit a title, and right-click for a context menu — all over the same plain JSON.
A sheet is { id, code, name, title, sub, schema: 2, board }:
board — { nodes: [], edges: [], view: { x, y, zoom } }.
node — { id, x, y, w, h, title, status, sub?, detail?, algorithm?, board? }.
status ∈ done · partial · todo; detail is { in[], out[], note, open[] }
(shown in the inspector); algorithm: '<id>' links a storyboard; and board
nests a child chart — the same { nodes, edges } shape, recursively.
edge — { id, from, to, kind, label?, fromSide? }. from/to are node ids
in this same board; kind ∈ flow · loop · dep; fromSide ∈
top · right · bottom · left is the side it leaves.
The validator rejects an edge whose endpoints aren't both in its board, a self-edge, and a board that nests one of its own ancestors (an infinite-recursion cycle) — depth itself is unbounded.
Legacy shorthand. A sheet may instead carry a flat
stations: [...]spine (each{ title, sub, status, detail }, withloop: { to, label }for a feedback arc andfan: { tracks: [...] }for parallel branches). It's auto-migrated into the board model on load — fan → a nested child board, loop → aloopedge — and the server commits the v2boardon the first write. New work should authorboarddirectly; reach forstationsonly for a quick linear spine.
All content is JSON — no diagram syntax, no code — stored per project under
$WORKFLOW_ATLAS_HOME (see Projects) and edited through the MCP
tools (the assistant authors it; changes show on reload). For workflows, prefer
the granular tools — set_node (one card) and edit_board (cards + edges in one
board) — which edit one piece without resending the rest; reach for save_sheet
only to create a sheet or rewrite it wholesale (delete_sheet / reorder_sheets
manage the set). save_sheet takes a whole sheet including its nested board (see
the data shapes above); a legacy stations[] spine is still
accepted and auto-migrates to a board on read.
The write tools reject a non-slug id, a code that isn't a short string, a bad
status, non-string detail.open/in/out, a dangling edge, a duplicate node/sheet id,
and a board+boardRef conflict; save_sheet echoes non-fatal lint warnings
(overlong badge, an empty sheet, an open question whose exact text repeats within a
sheet). Every workflow write is serialized by a cross-process lock and carries a
per-sheet rev token, so a stale assistant edit is rejected rather than
overwriting a concurrent human edit (re-read, or pass force). Deleting a sheet
keeps its recorded decisions, so re-creating the same id later recovers them. The
in-app replace-all save snapshots the prior file to workflows.json.bak first, so
an accidental reset is recoverable until the next replace-all.
A second view (top-left Workflows / Algorithms switch, or open
algorithms.html) animates an algorithm step by step instead of describing it
in prose. The stage shows the data (an array of value cells, or a worksheet),
the pseudocode highlights the active line, and the narration explains each step
— synced to a play / step / scrub transport (← → to step, space to play).
Each storyboard is a JSON spec (authored with save_algorithm, auto-discovered
— no registration step). A spec is:
{
"id": "binary-search", "tag": "ALG-01", "name": "Binary search",
"sub": "…", "kind": "array", // "array" (value cells) or "calc" (worksheet)
"code": ["pseudocode", "lines"], // highlighted as it runs
"params": [ { "key": "target", "value": 33, "min": 1, "max": 99, "step": 1 } ],
"steps": [ /* explicit frames — the simple, fully-authorable path */ ]
}A frame (kind: "array") is { array[], cls{index:state}, ptr{label:index}, note, line, verdict{ok?,text}, question? }, where state is one of
idle·active·compare·lo·hi·mid·eliminated·found·sorted. A row
(kind: "calc") is { label, result?, unit?, expr?, sub?, kind?(input|result), bad?, line, note, question? }.
Instead of steps, a spec may set "builtin": "<name>" + "data" to be driven
live by a built-in generator in shared/generators.js (the bundled binary
search, bubble sort, and Euclid demos use this — change a param and the whole
walk re-runs). Authored storyboards just use steps. Add one with the
save_algorithm MCP tool.
Your layer over a storyboard — tuned params, per-step comments, and recorded
decisions — lives beside the spec in the project's reviews/<id>.json. With the
server running the app autosaves to it as you edit and reloads it as the
baseline next time. (Offline, edits stay in the browser only.)
A trace step can pose an open design question (question: '…'). The storyboard
shows it on that step with a box to record the decision (answer + who +
when); resolved questions show settled, and the timeline marks open (hollow) vs
decided (green). The decision is stored alongside the rest in the review file
(decisions[step]). The point: addressing a question is one durable action, and
the assistant can read/resolve it too. Best practice — when you decide, also let
it drive a real change (a param default, the logic, a step's status) so the
artifact and the decision can't drift apart.
server/server.mjs is one zero-dependency process that serves the app, persists
reviews over REST, and speaks MCP — over stdio (how an MCP client like
Claude Code launches it) and at /mcp over HTTP (for manual testing). Every tool
acts on the session's project. Tools:
Read — list_algorithms, get_algorithm, list_sheets (TOC: ids + status
counts + each sheet's rev, no boards), get_sheet, get_node (one node by its
#sheet/nodeId/… path), find_nodes (search/index nodes by text or status →
returns each match's path), get_review, list_open_questions, list_shared.
get_sheet takes an optional depth (positive int) that includes nested boards only
that many levels deep — a deeper node.board becomes a stub { nodes, path } you
fetch with get_node, so a deep sheet reads shallowly
Author algorithms — save_algorithm, delete_algorithm
Author workflows — set_node (patch one card) and edit_board (cards + edges
in one board, atomic) are the granular, preferred path; save_sheet creates or
rewrites a whole sheet; delete_sheet / reorder_sheets manage the set. Writes are
serialized and rev-guarded so a stale assistant edit can't overwrite a human one
Review / decisions — set_param, set_comment, set_decision,
reopen_question (algorithms); set_workflow_decision,
reopen_workflow_question (workflow open questions)
The look — list_files, get_file, set_file → read/overwrite raw app
files (CSS / HTML / JS / JSON / SVG / MD / TXT) to style the app (project data is edited with the content tools)
So the loop is: the assistant proposes an algorithm → it builds the storyboard
with save_algorithm → you watch it run and leave a comment or decision → the
assistant reads that over MCP and revises. Showing, not just telling. (The server
also advertises this in its MCP instructions, so when you say you've answered,
the assistant knows to call list_open_questions and read your decisions back.)
scripts/atlas-review-hook.mjs is a Claude Code UserPromptSubmit hook: once
you've answered every open question on a sheet/storyboard, your next message
carries those decisions automatically (so the assistant revises without being
told to re-read). It fires per unit — answering one sheet doesn't wait on the
others, and the bundled demo questions never block it — and only once per
answered state.
Wire it in your user settings with the absolute path to the script. It
reads the same project the server bound to — derived from the directory Claude Code
is open in, under $WORKFLOW_ATLAS_HOME — so it works from any repo:
{ "hooks": { "UserPromptSubmit": [ { "hooks": [
{ "type": "command", "command": "node \"/abs/path/to/workflow-atlas/scripts/atlas-review-hook.mjs\"" }
] } ] } }ATLAS_HOOK_DEBUG=1 prints why it did/didn't fire (and which project) to stderr;
ATLAS_CONTENT_DIR overrides the project path. It never blocks your prompt.
If your client is Claude Code, a project .mcp.json runs the server as a stdio
MCP server, so it's spawned every session — you never start it by hand. One-time:
reload the session (so .mcp.json is read) and approve the server when
prompted. Other MCP clients register node server/server.mjs however they spawn
stdio servers.
workflow-atlas/
index.html workflows shell (title block · sheet · callout)
algorithms.html storyboard shell (stage · pseudocode · narration)
styles.css design system — palette, type, nodes/edges, stage
app.js workflow app shell — sheet index, inspector, autosave, URL↔focus sync
canvas.js the infinite-nested canvas engine: semantic zoom (dot/card/frame),
focus-stack re-rooting, in-browser editing, four-side connections
storyboard.js algorithm player (loads specs, replay, transport)
shared/board.js the node/edge/board MODEL — geometry, ids, recursive (cycle-guarded) validation
shared/migrate.js legacy stations-spine → v2 board (nodes/edges); runs in browser AND server
shared/generators.js built-in algorithm generators (browser + server)
shared/project.js active-project resolution + switcher (browser)
scripts/
atlas-review-hook.mjs optional Claude Code UserPromptSubmit hook
content/ bundled demo seed (copied into a project on WORKFLOW_ATLAS_SEED=1)
server/server.mjs zero-dep Node server: static + REST + MCP (stdio + /mcp)
package.json npm start, metadata (zero dependencies)
.mcp.json registers the server for Claude Code
LICENSE MIT
~/.workflow-atlas/ project DATA (override with $WORKFLOW_ATLAS_HOME)
projects/<project>/
workflows.json workflow maps
algorithms/*.json algorithm storyboards
index.json discovery manifest (server rewrites on save/delete)
reviews/*.json tuned params + comments + decisions (server writes).mcp.json registers the server (Claude Code's format; any MCP client can spawn
node server/server.mjs over stdio):
{ "mcpServers": { "workflow-atlas": { "command": "node", "args": ["server/server.mjs"] } } }(Another project can point its own .mcp.json here via a relative path such as
../workflow-atlas/server/server.mjs, so the tool stays usable from that
session too.)
Delete an algorithm storyboard and its review. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It states the tool deletes both the storyboard and review and that the deletion persists, but lacks details on side effects, error handling, permissions required, or whether deletion is irreversible. 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?
The description is very short (two sentences) and front-loads the action. However, its brevity sacrifices important details, making it feel under-specified rather than efficiently concise. It earns a middle score.
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 delete tool, the description misses key context: what the 'algorithm' parameter should contain, whether the tool is idempotent, what happens if the algorithm doesn't exist, and any cascading effects. Incomplete for safe 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?
Input schema has one string parameter 'algorithm' with no description (0% schema coverage). The tool description does not elaborate on what the parameter represents (e.g., ID, name, path) or its format. Adds no value beyond the parameter name.
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 verb 'Delete' and the specific resource 'algorithm storyboard and its review'. It distinguishes from siblings like 'delete_sheet' which targets a different resource type. The action is unambiguous.
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. No mention of prerequisites, conditions, or comparison to siblings like 'save_algorithm' or 'get_algorithm'. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete ONE workflow sheet by id (pass baseRev/force as in save_sheet to guard against a concurrent human edit). Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| sheet | Yes | ||
| baseRev | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the persistence of the deletion ('Persists.') and hints at concurrency safety, but omits details like required permissions, irreversibility confirmation, or effects on related data. 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?
The description is extremely concise: two sentences with no wasted words. The first sentence states the core action, and the second provides critical usage context. Every part 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 lack of annotations and output schema, the description provides sufficient context for a simple deletion tool. It covers parameters, persistence, and concurrency guard. It could elaborate on side effects or error scenarios, but it is complete enough for typical 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?
With 0% schema description coverage, the description adds meaning to two out of three parameters ('baseRev' and 'force') by referencing 'save_sheet' and the concurrency guard purpose. The 'sheet' parameter is implied as the ID by the phrase 'by id', but not explicitly documented. Partially compensates for missing schema descriptions.
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 ('Delete'), the resource ('workflow sheet'), and scoping ('by id'). It distinguishes from related operations by referencing 'save_sheet' for the concurrency guard. This is a specific verb+resource combination with no ambiguity.
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 mentions passing 'baseRev' and 'force' parameters as a guard against concurrent human edits, guiding when to use them. However, it does not explicitly state when not to use this tool versus alternatives, but the naming and brevity make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GRANULAR write — edit cards & connections in ONE board WITHOUT resending the sheet. This is the primary way to keep the diagram in sync as you work (mark a card done, add a step, wire two cards). "at" addresses the board: the sheet id = its ROOT board, or "sheetId/nodeId/…" = the child board inside that container node (every non-leaf node on the path must already exist; only a leaf container's missing board is created so you can author into it). nodes[] UPSERT-MERGE by id: an existing id patches just the fields you pass (top-level keys replace; "detail" merges per key — set {detail:{note}} and detail.in/out/open are untouched; a null value CLEARS a field; an array replaces the whole array); a new id CREATES the node (needs a title; auto-placed below the board's bbox — pass x/y to override). edges[] upsert by id (omit id to create one; from/to must be node ids in THIS board; kind? flow|loop|dep, label?, fromSide? top|right|bottom|left). deleteNodes[] removes nodes (and cascades their incident edges); deleteEdges[] removes edges by id. One atomic, validated write. CONCURRENCY: auto-rejected if a human edited the sheet in the app since you last read it (re-read & re-apply, or pass force:true); pass baseRev (from list_sheets / a prior write) to pin it explicitly. Returns what changed + the new rev. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | ||
| edges | No | ||
| force | No | ||
| nodes | No | ||
| baseRev | No | ||
| deleteEdges | No | ||
| deleteNodes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly covers upsert-merge behavior, concurrency auto-rejection, force option, baseRev, atomic writes, and persistence details.
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 long but every sentence adds value; it is front-loaded with 'GRANULAR write' and structured logically, though slightly verbose.
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 7 parameters, no output schema, and no annotations, the description is remarkably complete, covering return values, edge cases, and concurrency, leaving no critical 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?
Despite 0% schema description coverage, the description explains each parameter in depth (at path, nodes upsert/merge, edges upsert with fields, delete arrays, force, baseRev), adding significant meaning beyond the 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?
The description clearly states it edits cards & connections in one board, distinguishing it from siblings like save_sheet or set_node by emphasizing granularity and atomicity.
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?
It identifies as the primary way to keep the diagram in sync, implying when to use, and describes concurrency handling with force, but could explicitly contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find / index workflow nodes by text or status, returning each match's node PATH so you jump straight to a card instead of drilling board by board. Pass the path straight to get_node or set_node to read/patch that card. (For edit_board, whose "at" addresses a BOARD, use the card's PARENT board — drop the last id from the path — and reference the card's id in nodes[].) With NO query it INDEXES every node across all sheets at every nesting depth. query = case-insensitive substring matched against a node's id / title / sub / detail.note / detail.in / detail.out / detail.open / algorithm (e.g. "Npgsql"). status = done|partial|todo filter. sheet = scope to one sheet (else the whole project). A boardRef mount shows as a leaf (→mounts ); edit its contents on the source sheet.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| sheet | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses full-scan indexing with no query, case-insensitive substring matching across multiple fields, status filter, sheet scoping, and boardRef leaf behavior. All behavioral traits are covered despite no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Somewhat verbose but every sentence adds value; front-loaded with main purpose. Minor room for tightening without losing clarity.
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 annotations, no output schema, and three optional params, the description thoroughly covers functionality, edge cases (boardRef), and result usage, making it fully self-sufficient.
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 three parameters (query, sheet, status) are explained in detail: query is case-insensitive substring against specific fields, status is a filter with values, sheet scopes to one sheet. Adds meaning beyond the empty 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?
Clearly states it finds workflow nodes by text or status and returns paths, distinct from siblings like get_node (read) and set_node (patch).
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?
Explicitly advises when to use (jump to a card), how to use results with get_node/set_node, and provides special handling for edit_board by dropping last path id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full JSON spec of an algorithm storyboard (meta, kind, code, params, steps or builtin).
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | 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. It states it 'Reads' the spec, implying no side effects. However, it does not disclose error behavior (e.g., algorithm not found) or any permissions needed. It mentions 'full JSON spec,' which hints at the return format but lacks details.
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 16-word sentence that is front-loaded with the key action and result. Every word earns its place; no fluff.
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 getter with one parameter and no output schema, the description covers the essence. The term 'full JSON spec' implies the return is a complete representation. It could mention whether the spec includes nested structures, but given the sibling tools and simplicity, it is adequate.
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 one required string parameter 'algorithm' with no description (0% coverage). The description mentions 'algorithm storyboard,' clarifying that the parameter identifies an algorithm. However, no format or example is given. The description adds some meaning but could be 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 clearly states the verb 'Read' and the resource 'full JSON spec of an algorithm storyboard' with specific content types (meta, kind, code, params, steps or builtin). It distinguishes itself from sibling tools like save_algorithm or delete_algorithm by focusing on reading the spec.
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 vs alternatives, but the name 'get_algorithm' and sibling tools like 'list_algorithms' or 'save_algorithm' imply its purpose. The description could benefit from noting that it retrieves a specific algorithm's spec, not listing or modifying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a raw app file (e.g. styles.css, index.html, algorithms.html) to design the look.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Read', implying no side effects, but lacks details on output format, authorization, or constraints. Minimal behavioral 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?
Single sentence, no fluff, front-loaded with action and resource. Could benefit from a second sentence for parameter explanation but remains 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?
With 1 parameter, no output schema, and no annotations, the description is incomplete. Lacks details on return value, path semantics, and error conditions. For a simple read tool, more context is needed.
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 description only hints at possible values via examples in parentheses. Does not explain path format, allowed values, or relative vs absolute paths.
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 (Read), the resource (raw app file), and provides specific examples. It distinguishes from sibling tools like list_files (listing) and set_file (writing).
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?
Implies usage context ('to design the look') but does not explicitly state when to use or when to use alternatives. 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.
Read ONE node addressed by the same #sheet/nodeId/nodeId path the URL hash uses (or a stub's more.path) — jump straight to one pillar/sub-board instead of dumping the whole sheet. Returns that node with its own child board pruned to "depth" (default 1; deeper child boards become { nodes, path } stubs). To EDIT what you read here, use set_node (one card) or edit_board (a whole board) — never resend the sheet.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| depth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses the read-only nature, the return format (node with pruned child board, stubs for deeper levels), and default depth. Missing explicit idempotency or side-effect mention, but the read-only intent is clear.
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?
Three concise sentences. Front-loaded with the primary action, then parameter details, then usage advice. No superfluous words.
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 read tool with no output schema, the description adequately explains what is returned (node with pruned child board, stubs). The path semantics are clearly tied to the application's URL structure. Complete enough for an agent to use correctly.
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%, so description must compensate. It explains the 'path' parameter as the URL hash or stub path, and 'depth' with default 1 and behavior for deeper levels. This adds significant meaning beyond the bare 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?
The description clearly states 'Read ONE node' and specifies the unique addressing mechanism (URL hash path or stub's more.path). It distinguishes from siblings like get_sheet by contrasting 'jump straight to one pillar/sub-board instead of dumping the whole sheet'.
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 explicit guidance on when to use this tool (for reading a single node) and when not to use it (for editing, directing to set_node or edit_board). It also warns not to 'resend the sheet' for editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the saved review (tuned params + per-step comments + decisions) for an algorithm.
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral disclosure beyond 'Read'. No annotations provided, so description carries full burden but omits permissions, error states, or whether review always exists.
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. Efficient but slightly underspecified.
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 param, but missing details like return format or behavior for missing reviews. 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?
Schema description coverage is 0%. Description does not explain the 'algorithm' parameter's format, valid values, or relationship to other tools. No added meaning.
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?
Clearly states verb 'Read' and resource 'saved review for an algorithm'. Distinguishes from sibling tools like get_algorithm (different content) and save_algorithm (write 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?
No guidance on when to use this tool vs alternatives, such as get_algorithm or list_algorithms. Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ONE workflow sheet by id. A deeply nested sheet can be huge — pass "depth" (positive int) to include nested child boards only that many levels deep (a deeper node.board becomes a stub { nodes, path } you fetch with get_node). Omit depth for the full sheet. Reading a sheet records its rev so a later edit_board/set_node/save_sheet is rejected if a human changed it meanwhile (see save_sheet).
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| sheet | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes depth effect, concurrency rev recording, and stub behavior for nested boards. References get_node for deeper fetching.
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 paragraph, 4 sentences. Purpose is front-loaded. Efficient but could be slightly more 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?
Adequate for a read tool with clear sibling context. Concurrency behavior is explained in relation to save_sheet. No output schema, but return format is not critical for function selection.
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%, but description explains depth as positive integer controlling nesting and sheet as id. Adds value beyond schema by hinting at behavior when depth is omitted or used.
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?
Clearly states 'Read ONE workflow sheet by id' with specific verb and resource. Distinguishes from sibling tools like list_sheets (list all) and get_node (fetch nested boards).
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?
Provides explicit guidance on depth parameter usage ('Omit depth for the full sheet') and concurrency behavior. Does not explicitly state when not to use the tool, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the algorithm storyboards and whether each has a saved review.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that this is a read-only operation or disclose any side effects. It minimally conveys the output content but lacks behavioral details like authentication needs or rate limits.
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 that is clear and concise with no wasted words. It efficiently conveys the tool's action and output.
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 parameters and no output schema, the description provides sufficient information about what the tool returns (list of algorithm storyboards with saved review status). It is complete for a simple list 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?
There are no parameters (schema coverage 100% empty), so the baseline is 4. The description adds meaning by specifying what the list contains (algorithm storyboards and saved review status), which is beyond the empty 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?
The description clearly states the verb 'List' and the resource 'algorithm storyboards', and specifies the additional context of 'whether each has a saved review'. This is specific and distinct from sibling tools like list_files or list_sheets.
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. While the purpose is clear, there is no mention of scenarios or exclusions relative to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the raw app files you may read/edit to design the look (CSS, HTML, JS at the app root). Excludes server/ and the demo seed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions the scope and exclusions but fails to state read-only nature, permission requirements, or response format, leaving gaps for an agent.
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 focused sentence with no redundant information, efficiently conveying the tool's 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 parameterless list tool, the description covers what files are included and excluded. The absence of output schema info is acceptable given the tool's simplicity.
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, and the description adds meaningful context (file types, location) beyond the schema. Baseline for 0 params is 4, and this is met.
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 that the tool lists raw app files (CSS, HTML, JS) at the app root for design purposes, distinguishing it from sibling tools by mentioning exclusions (server/, demo seed).
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?
While the description implies the tool is for design file access, it does not explicitly state when to use this tool over alternatives like list_algorithms or list_sheets, nor does it provide exclusion criteria for other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every authored open question — across algorithm storyboards AND workflow sheets — and whether each has been decided yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a listing operation, implying no side effects, but does not explicitly declare read-only behavior, idempotency, or 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?
Single sentence, 17 words, front-loaded with action and scope. 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?
For a simple list tool with no parameters and no output schema, the description covers the essential information (what is listed and from where). However, it does not specify result ordering, pagination, or exact fields returned.
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 in schema, so baseline is 4. Description adds no parameter info, but none is needed as schema coverage is 100%.
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 lists open questions from two sources (algorithm storyboards and workflow sheets) and includes decision status. It distinguishes from sibling tools like list_algorithms, list_sheets, and set_decision by specifying the scope and 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?
The description implies usage for viewing open questions, but does not explicitly state when to use or provide alternatives. It lacks guidance on not using for closed questions or when to use sibling tools like set_decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Table of contents: every sheet's id/code/name/title/sub + per-status node counts + its current rev (the concurrency token), with NO boards — the cheap way to see what exists before reading any board. Start here, then drill in with get_sheet / get_node.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains it returns no boards and is 'the cheap way,' indicating lightweight behavior. It lists returned data (id/code/name/title/sub, node counts, concurrency token), adding context beyond the schema. No annotations to contradict.
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 front-loaded sentences with no wasted words. The first sentence enumerates contents and nature, the second gives usage advice. Ideal 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?
It adequately describes what the tool returns despite no output schema. It covers all relevant aspects: sheet identifiers, node counts, and concurrency token. No need for more detail.
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 the description doesn't need to explain them. The baseline of 4 is appropriate, and the description adds meaning by detailing what is returned.
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 provides a table of contents for sheets with specific fields (id/code/name/title/sub, node counts, revision) and explicitly excludes boards, distinguishing it from sibling tools like get_sheet.
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?
It advises 'Start here, then drill in with get_sheet / get_node,' providing a clear workflow. While it doesn't explicitly state when not to use it, the recommendation implies it's for initial exploration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear a recorded decision so the question is open again. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes | ||
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'clears' a decision (mutation) and 'persists', but provides no details on side effects, error behavior, or state changes beyond the core action. Without annotations, this is minimally adequate.
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, zero wasted words. The key action and persistence are front-loaded. Ideal 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?
For a mutation tool with two undocumented parameters, no output schema, and no annotations, the description is incomplete. It fails to explain what algorithm and step refer to, or the workflow implications of reopening a question.
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 two required parameters with 0% description coverage. The description does not mention or explain 'algorithm' or 'step', leaving their meanings entirely to the agent's inference.
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 a recorded decision' and the resource 'question', and distinguishes from sibling 'reopen_workflow_question' by focusing on 'question' rather than 'workflow question'.
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 like set_decision or reopen_workflow_question. No context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear a recorded decision so a workflow open question is open again. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| sheet | Yes | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It says 'Persists' implying a permanent state change, but does not mention side effects, reversibility, or authorization needs. 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?
The description is very short (13 words), but lacks structure and detail. It is under-specified rather than concise, failing to provide necessary 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?
No output schema, no annotations, and no parameter descriptions. The description only covers the high-level action, missing return type, exact effects, and usage context. Incomplete for a tool with zero supporting structured data.
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%, so the description must add meaning for the parameters. It does not explain what 'sheet' or 'question' refer to. The description adds no value beyond the raw 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?
The description uses a clear verb 'Clear' and specific resource 'recorded decision so a workflow open question is open again'. It distinguishes from the sibling tool 'reopen_question' by explicitly mentioning 'workflow open question', indicating a specific 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?
No guidance on when to use this tool vs alternatives like 'set_workflow_decision' or 'reopen_question'. The description does not mention prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reorder the sheets in the left index. order = [id, …]; any sheet id you omit keeps its order at the end. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that persistence occurs ('Persists.') and explains the effect of omitted ids, which is sufficient for a simple reorder operation.
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 with two sentences, each providing essential information without any filler words.
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 core functionality well. It lacks information about return values or error handling, but is otherwise 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?
Schema description coverage is 0%, but the description fully explains the single parameter 'order' including its format and behavior, thus adding significant meaning beyond the schema definition.
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 explicitly states the verb 'Reorder', the resource 'sheets in the left index', and clarifies the order parameter behavior, distinguishing it from sibling tools like save_sheet or get_sheet.
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 gives clear usage instructions for the order parameter and implies when to use this tool (for reordering), but does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or replace an algorithm storyboard from a JSON spec. spec = { id (slug), tag?, name, title?, sub?, workflow?{sheet,label}, layout?{ width (overall page px, 700-2400), height (stage min-height px, 240-1600), sidebarWidth (pseudocode/narration column px, 260-720) } for bigger storyboards, kind ("array"|"calc"), code (pseudocode lines[]), params? [{ key, label, sym?, value, unit?, min, max, step, hint? }], and EITHER steps[] (explicit frames) OR builtin (one of: binary-search, bubble-sort, euclid-gcd) + data + questions?[{ step, text }] }. A frame (kind "array") = { array[], cls{index:state}, ptr{label:index}, note, line, verdict{ok?,text}, question? } where state ∈ idle|active|compare|lo|hi|mid|eliminated|found|sorted. A row (kind "calc") = { label, result?, unit?, expr?, sub?, kind?(input|result), bad?, line, note, question? }. Persists to this session's project.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool persists to the session's project and details the complex nested structure of the spec. However, it does not explicitly mention authorization needs or confirm the destructive nature of replacement.
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 lengthy but front-loaded with the core purpose. Given the complexity of the spec, every detail is necessary. However, it could be slightly more structured (e.g., bullet points) without losing clarity.
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 extensively documents the spec structure but lacks details about return values (no output schema) and error conditions. For a highly complex tool, this is a minor gap; overall, it provides sufficient 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?
The parameter schema only defines an object with no properties, providing 0% coverage. The description compensates fully by specifying the entire nested structure of the spec, including required fields, optional fields, allowed values, and constraints.
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 or replaces an algorithm storyboard from a JSON spec, specifying the verb 'Create or replace' and the resource 'algorithm storyboard'. It distinguishes from sibling tools like delete_algorithm and get_algorithm by describing its unique input format.
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 for creating or updating algorithm storyboards but does not explicitly state when to use this tool over alternatives like save_sheet or set_node. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upsert ONE workflow sheet by id — create it or replace it in place WITHOUT resending the others. sheet = { id (slug), code (SHORT badge), name, title, sub, schema? (2 for the v2 board form), shared? (true ⇒ this sheet is a reusable COMPONENT other sheets mount), status? (done|partial|todo — a shared component's single status, mirrored by every mount), AND EITHER legacy stations[] OR a v2 "board" }. A v2 board (the infinite-canvas / nested-chart form the app now renders) = { nodes:[ NODE ], edges:[ EDGE ], view?:{x,y,zoom} }. NODE = { id (unique within this board), x, y, w?, h? (local px), title, sub?, status (done|partial|todo), detail?{in[],out[],note,open[]}, algorithm?, board? (a NESTED child board — revealed by zooming into the node), boardRef? (TRANSCLUDE another sheet by id instead of owning a board — mounts that shared component live+read-only and inherits its status; mutually exclusive with board; see list_shared) }. EDGE = { id, from (node id in THIS board), to (node id in THIS board), kind? (flow|loop|dep), label?, fromSide? (top|right|bottom|left — the side the edge leaves the source node) } — edges are intra-board only; link across levels by nesting, not by an edge. Legacy stations[] sheets still load and auto-migrate to a board on read. Use this to CREATE a sheet or rewrite it wholesale; for surgical edits to an existing sheet prefer edit_board / set_node (they don't resend the tree). CONCURRENCY: pass "baseRev" (a sheet's rev from list_sheets or a prior write) to make the write FAIL if the sheet changed since — by default a write is auto-rejected if a human edited the sheet in the app since you last read it; pass force:true to overwrite anyway. Returns created-or-updated + the new rev + lint warnings. Persists to this session's project.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| sheet | Yes | ||
| baseRev | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers all behavioral traits: upsert semantics, concurrency control (baseRev, force, auto-rejection on human edit), auto-migration of legacy stations, return values (created-or-updated, rev, lint warnings).
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 long but well-structured and front-loaded with the core purpose. Every sentence adds value, but could be slightly more concise. Still effective.
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 (nested objects, two forms, concurrency), the description is exceptionally complete. It explains return values, migration behavior, and concurrency rules, leaving no 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%, but description extensively explains the 'sheet' parameter, including all fields and the two forms (stations vs board). Also explains baseRev and force parameters fully.
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: 'Upsert ONE workflow sheet by id — create it or replace it in place WITHOUT resending the others.' It distinguishes from sibling tools by noting that for surgical edits, prefer edit_board/set_node.
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?
Explicit guidance provided: 'Use this to CREATE a sheet or rewrite it wholesale; for surgical edits to an existing sheet prefer edit_board / set_node.' Also explains concurrency behavior with baseRev and force.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set (or clear, with empty text) a comment on a step of an algorithm. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes | ||
| text | No | ||
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions persistence but lacks details on whether overwrites occur, permission requirements, or side effects. The ability to clear with empty text is noted, but other behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it sacrifices essential details. It achieves conciseness at the cost of completeness, making it only adequate.
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, no annotations, and 3 parameters, the description is insufficient. It does not explain return values, error states, or what constitutes a valid step. It feels incomplete for practical use.
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 adds minimal value beyond parameter names: algorithm, step (number), text. No explanation of what the step number represents or constraints on text format.
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: set or clear a comment on a step of an algorithm. It distinguishes from sibling tools by specifying the resource (comment on algorithm step) which is unique among the listed 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 implies usage for adding or clearing comments, but does not explicitly state when to use this tool over alternatives like set_decision or set_param. No exclusion criteria or context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an open question: record the decision (answer) on a step. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | ||
| step | Yes | ||
| answer | Yes | ||
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states 'Persists' and implies mutation ('record the decision'), but fails to disclose idempotency, overwrite behavior, required permissions, or side effects (e.g., invalidates open question status). This is insufficient for safe invocation.
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 that conveys the core purpose efficiently. However, it sacrifices necessary detail; a slightly longer description with parameter clarifications would be more helpful 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 4 parameters, 0% schema coverage, no output schema, and no annotations, the description is far from complete. It does not explain the 'open question' context, how parameters relate, or what happens after invocation. For a tool with this complexity and no other documentation, the description is inadequate.
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 0% description coverage, yet the description only clarifies 'step' and 'answer' indirectly. It does not explain 'algorithm' (likely an identifier) or 'by' (likely the decider), leaving 50% of parameters semantically opaque. The description adds minimal value beyond the 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?
The description clearly states the tool records a decision (answer) on a step to resolve an open question, using specific resources like 'step' and 'decision'. However, it does not differentiate from sibling tools like 'set_workflow_decision' or 'reopen_question', missing an opportunity to clarify its unique scope.
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 (e.g., 'set_workflow_decision' for workflow-level decisions, 'reopen_question' for reopening). No prerequisites or exclusions are mentioned, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overwrite a raw app file to restyle/redesign the app. Allowed extensions: css, html, js, json, svg, md, txt. Cannot touch server/ or the demo seed (use the content tools for project data). No guardrails on the markup itself — local tooling.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | 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. It discloses that there are no guardrails on the markup (local tooling) and that the tool overwrites files. However, it does not clarify whether the tool creates files if they don't exist, what happens on error, or any authentication/permission needs. 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?
The description is two sentences with a clear structure: action first, then constraints. It is efficient and front-loaded, though the phrase 'to restyle/redesign the app' is slightly redundant with 'raw app file'.
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 exists, but the description does not mention what the tool returns (e.g., success message, updated file info, or errors). For a write operation with two parameters, this is a significant gap. Constraints are well-covered, but completeness for invocation understanding is lacking.
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%, so the description must compensate. It implies that 'path' is the file path and 'content' is the new file content, but lacks details like path format (relative vs absolute), required extension, or character encoding. Provides minimal added meaning beyond the 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?
The description clearly states the tool overwrites a raw app file for restyling/redesign, with allowed extensions and explicit constraints (cannot touch server/ or demo seed). This distinguishes it from sibling read tools like get_file and list_files, and from other write tools like save_algorithm.
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 specifies when to use (overwriting app files for styling) and when not to (use content tools for project data). It lists allowed extensions but does not explicitly direct to get_file for reading or compare to other write tools. Still, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shorthand to edit ONE card: patch a single node addressed by its "sheetId/nodeId[/nodeId…]" path (the URL-hash form get_node uses). "set" is merged into the node with the same rules as edit_board.nodes[] (top-level replaces; detail merges per key; null clears; arrays replace). PATCH-by-default: if the node does not exist this ERRORS (so a typo can't silently create a phantom) — pass create:true to add it (a new node needs a title). For edges, deletes, or several cards at once, use edit_board. CONCURRENCY: same auto-guard as edit_board (baseRev / force). Returns created|updated + the new rev. Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | ||
| path | Yes | ||
| force | No | ||
| create | No | ||
| baseRev | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses merge semantics, error-if-not-exists behavior, concurrency guards, return value, and persistence, with no annotations to rely on.
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?
Dense but efficient; every sentence adds value. Slightly long but justified by complexity.
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?
Covers all aspects: purpose, parameters (including nested object), behavioral rules, error conditions, sibling differentiation, and return values, despite no 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?
Provides full context for all 5 parameters despite 0% schema coverage: explains path format, set merge rules, create flag, baseRev/force concurrency, and error behavior.
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?
Clearly identifies the tool as a shorthand to patch a single node by path, distinguishing it from siblings like edit_board and get_node.
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?
Explicitly states when to use (single card edit) and when not (edges, deletes, multiple cards: use edit_board), plus details on creation and concurrency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set one param value in an algorithm review (re-evaluates the storyboard live). Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | ||
| algorithm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral info: it says the tool 're-evaluates the storyboard live' and 'persists,' indicating side effects. However, it does not mention potential errors, reversibility, or dependencies, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core action and adds key behavioral details 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 no annotations, no output schema, and minimal parameter info, the description is insufficient. It does not explain the tool's place among siblings, expected return, or parameter format, leaving significant 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%, but the description does not explain the meaning of key, value, or algorithm. The agent cannot infer valid values or constraints from the description alone, severely hampering parameter understanding.
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 is setting a param value in an algorithm review, with details about live re-evaluation and persistence. It differentiates from sibling set_ tools by specifying the context (algorithm review) and the effect (re-evaluates storyboard). However, it could be more explicit about what 'param' refers to.
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 provided on when to use this tool versus alternatives, such as when not to use it or which tool to use for batch updates. The description lacks any usage context or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a workflow open question — record a decision against a station/track open[] item, identified by its sheet id and the EXACT question text (see list_open_questions). Persists.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | ||
| sheet | Yes | ||
| answer | Yes | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states the tool 'persists', indicating a write operation, but lacks details on side effects, authentication requirements, rate limits, or what happens if the question is not open. It does not mention whether existing decisions are overwritten.
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 with no wasted words. It efficiently conveys the core purpose and refers to another tool for further detail. However, it could be slightly more concise by combining the purpose and identifier references.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the 'by' parameter, acceptable 'answer' values, success/error behavior, or return value. The tool's mutation nature demands more context about persistence effects.
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%, so the description must explain parameters. It mentions 'sheet id' and 'exact question text' but does not describe the 'by' or 'answer' parameters. The 'by' parameter (likely decision maker) and 'answer' (the decision value) are left unspecified.
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: 'Answer a workflow open question — record a decision against a station/track open[] item'. It identifies the resource (open question items) and specifies the identifier (sheet id and exact question text). It distinguishes from siblings like 'set_decision' by referencing 'list_open_questions' for exact question text.
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 implicit guidance by stating to use 'list_open_questions' for the exact question text, implying that the question must be open. However, it does not explicitly state when not to use this tool or provide alternatives like 'set_decision' or 'reopen_question'.
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.2.0delete_algorithmdelete_sheetedit_boardfind_nodesget_algorithmget_fileget_nodeget_reviewget_sheetlist_algorithmslist_fileslist_open_questionslist_sharedlist_sheetsreopen_questionreopen_workflow_questionreorder_sheetssave_algorithmsave_sheetset_commentset_decisionset_fileset_nodeset_paramset_workflow_decisionScored across 25 tools
Most tools target distinct entities (algorithms, sheets, files, questions), but pairs like reopen_question/reopen_workflow_question and set_decision/set_workflow_decision have similar names and purposes, requiring careful reading of descriptions to avoid confusion.
All tools follow a consistent verb_noun pattern in snake_case (e.g., delete_algorithm, list_sheets, set_node). No mixing of conventions or irregular naming.
With 25 tools, the server covers algorithms, workflow sheets, files, and reviews. While the count is high, it reflects the breadth of functionality, but some tools could be merged (e.g., unified question tools) to reduce cognitive load.
The tool set provides create, read, update, and delete operations for algorithms and sheets, plus search, file management, and decision handling. Minor gaps exist (e.g., no bulk operations), but core workflows are well-supported.
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
Generate, edit, and deploy immersive 3D/WebGL web projects from any MCP assistant.
Create, edit, preview, publish, and manage web pages from MCP-capable AI clients.
Build, edit, host, and publish websites from AI assistants. Setup: https://mcp.orivox.org/
