Capaxima MCP server

What a session looks like

You open a project in Capaxima and your editor next to it. In Claude Code you type /board_health — one of the server's prompt recipes, registered as a slash command. The agent reads the board's conflicts, unlinked tasks and tasks without an estimate, and reports what is missing. You say “level it, balanced utilisation”; the agent calls plan_edit with operation: level, the board redraws under the Gantt, and the change is one undo step in the app. You ask “which roles are overloaded in March?”; for a question the agent gets only the read tool.

The app does not have to trust the model. Every write is a named tool with a typed schema. A link that would create a cycle is refused, and the response names the path. Deleting every task on the board requires confirm: true. A call the model repeats with the same arguments is answered from the earlier result and not applied twice.

Connecting

The beta ships the server with the installer; the start command for your install is in the release notes. There are two transports: stdio, for clients that start the server themselves, and streamable HTTP on 127.0.0.1:7432 for everyone else.

Claude Code

claude mcp add --transport http capaxima http://127.0.0.1:7432/mcp \
  --header "Authorization: Bearer <token>"

Cursor

In .cursor/mcp.json of the project, or the global one:

{
  "mcpServers": {
    "capaxima": {
      "url": "http://127.0.0.1:7432/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Who may talk to it

The server binds to loopback, so other machines cannot reach it. Other browser tabs can: any web page can POST to a loopback port, and with DNS rebinding it can send a Host header it controls. So every request is checked before it reaches the transport:

Host must name this machine — anything else is a rebound name and gets 403.
Origin, when a browser sends one, must be a loopback origin or one you listed in CAPAXIMA_MCP_ALLOWED_ORIGINS. CORS reflects exactly the accepted origin, never *.
Set CAPAXIMA_MCP_TOKEN and every request must carry it as a bearer token, or it gets 401. It is optional because a non-browser client on the same machine is already a local process; the server says at startup when no token is configured.

Tools — the only way to write

A small local model gets eight verb tools instead of the full surface: one call per verb, addressed by task and phase titles rather than ids. If a title is unknown or ambiguous, the response lists the real candidates so the model can correct its call. A frontier model with native tool calling gets the full surface of about forty-five tools underneath — board_summary, project_draft_apply, schedule_analyze, resource_level, board_snapshot and the rest.

Tool	What it does
`board_inspect`	Read the board: overview, tasks (a search word narrows by title), phases, fields, schedule, conflicts, or the whole thing as Markdown or CSV.
`project_bootstrap`	A whole first roadmap on an empty board in one call: schema, phases, tasks, durations, roles, links.
`task_edit`	One task by title: create, rename, delete, duplicate, move, set a field.
`phase_edit`	One phase, milestone or gate by title: create, rename, delete, change kind, nest under a parent.
`dependency_edit`	Link or unlink two tasks by title; from blocks to. A link that would close a cycle is refused and the path returned.
`tasks_bulk_edit`	Many tasks at once: set a field, estimate all, assign domains, group into phases, delete — scoped to the board, a phase or a search. Deleting everything needs `confirm: true`.
`plan_edit`	The schedule: set duration or start, lock, unlock, configure, upsert or delete a role, level. No task named means every task.
`board_repair`	Fix the board without inventing content: resolve conflicts, re-lay out, clean placeholder titles.

Every result that changes the board includes a digest of the board after the change — counts, phase titles, task titles, field names — so the next call can address titles that exist. Arguments that must name something on the board are offered as a list of what is actually there, recomputed on every step.

Prompts — eleven recipes

A prompt recipe is a tool call with the arguments already chosen. Each recipe renders into one named call; the arguments autocomplete from the live board. In Claude Code and Cursor the recipes appear as slash commands.

Recipe	What it does
`bootstrap_project`	Create a complete roadmap on an empty board in one deterministic call.
`group_loose_tasks`	Put every task that sits outside a phase into one, then re-lay out the board.
`fix_dependency_cycles`	Apply every conflict fix the board can resolve automatically.
`level_resources`	Redistribute work across roles with the deterministic leveller.
`estimate_everything`	Fill in a duration for every task, optionally only where one is missing.
`set_field_everywhere`	Write the same value to a field across a phase, a search, or the whole board.
`link_tasks`	Make one task block another, refusing anything that would close a cycle.
`add_phase`	Create a phase, milestone or gate and, optionally, nest it inside an existing one.
`clean_placeholder_titles`	Delete tasks whose titles are objectively placeholders, keeping meaningful ones.
`schedule_report`	Read-only: critical path, end date and overloads.
`board_health`	Read-only: what is missing, unlinked, unestimated or in conflict.

Resources — reading without a tool call

A resource is data the client fetches directly, without a tool call and without adding to the message history.

roadmap://boards — the boards the server holds.
roadmap://board/{boardId}/{view} — one reading of one board: overview, tasks, phases, fields, schedule, conflicts, or the whole thing as markdown.
roadmap://board/{boardId}/tasks/{page} — boards too large to read in one go, 100 tasks a page, each page naming the next.

The server sends notifications/resources/list_changed whenever a board changes, so a cached overview is never silently stale.

Completions and elicitation

Completions. Prompt arguments and resource-template variables autocomplete from the live board: task titles for from and to, phase titles for phase, field names for field, open boards for boardId.

Elicitation. A required argument the caller left out is asked of you, with the real candidates in the form, rather than guessed by the model. This happens only for clients that declare the capability; everyone else keeps the strict schema. A declined or cancelled prompt changes nothing.

What it will not do

It does not run a model. You bring your own agent.
It does not use the network. Loopback only. The paid app never contacts a server.
It does not write around the document. Tools are the only way to change a board, and each tool performs the same action as a click in the UI.

Request the beta with the MCP server

Let your agent plan the board