MCP integration

What MCP can do

Continuum includes a local Model Context Protocol server for documents, Canvas, Blueprint, and Mermaid work. A compatible AI tool can inspect saved work, validate a declarative document recipe, retrieve built-in examples, and prepare a proposed change.

The important split is read now, stage writes. Listing, reading, schemas, guides, and validation return immediately. Creating or changing a Canvas never does: the MCP server stages a temporary proposal and the running Continuum app asks you to review it.

Fast path: create a complete Canvas in one proposal

For agents: author the whole diagram as Blueprint YAML or JSON, then call stage_blueprint once. Include every node, note, color, position, size, and relationship in that source. Do not create cards individually through the UI, stage one proposal per node, or repeatedly rearrange a board whose intended layout is already known.

For a connected MCP client that already knows the Blueprint contract:

1. Compose the complete source from the user's brief or supplied data. Keep unknowns explicit; do not turn hypotheses into facts. For swimlanes or a prescribed arrangement, set node position and size directly and include section labels in the same source.
2. Call stage_blueprint with { source, applyMode: "new" }. It parses and validates the source before staging, and the app provides the preview and approval step. A separate validate_blueprint call is optional: use it before staging when a preflight would help, or while correcting validation errors.
3. Review the proposal in Continuum and apply it with Approve. Staging is not application; report completion only after approval. Use get_blueprint_proposal_status when a programmatic completion check is needed.

That is one authoring MCP call, or two with explicit validation. Preview and approval happen in the app; there is no MCP apply tool. Schema discovery, reading an existing target, and optional status/read-back checks are additional calls, not prerequisites to repeat for every new Canvas.

Minimal complete example

Pass this YAML as the source string to stage_blueprint (JSON represents the same Blueprint):

version: "1"
title: Coffee pilot
mode: freeform
layout: right
nodes:
  - key: sampler
    kind: note
    title: Sampler purchase
    body: "known premise · Offer a tasting kit; price to validate."
    color: neutral
    position: { x: 0, y: 0 }
    size: { width: 300, height: 180 }
  - key: subscribe
    kind: note
    title: Subscription decision
    body: "assumption · A good first brew may lead to a monthly plan."
    color: bronze
    position: { x: 380, y: 0 }
    size: { width: 300, height: 180 }
relationships:
  - from: sampler
    to: subscribe
    direction: directed
    style: dashed
    label: to validate

The parser fills omitted optional fields; the schema tool returns the fully normalized contract. Call get_blueprint_schema once if the contract is unfamiliar, then reuse it. Current limits are 50 nodes (including structural nodes), 100 relationships, three group levels, and node sizes from 80–1600 wide and 48–1200 high. Use section labels and spacing for lanes wider than the node-size limit.

Existing Canvases, images, and other inputs

• New Canvas: use applyMode: "new"; no target lookup is necessary.
• Existing Canvas: resolve its ID with list_canvases if needed, read get_canvas_blueprint, then stage the intended merge or replace with targetCanvasId. Do not replace unrelated user work just to add content.
• Layout only: use one stage_canvas_layout call containing all required positions and structural additions. It preserves existing item IDs, content, and relationships. Avoid auto-arrange after supplying deliberate positions unless a different arrangement is requested.
• Images: finish the Blueprint first. Once its Canvas exists, use stage_canvas_image, or batch images with other additions in stage_canvas_layout. Blueprint source does not embed image bytes. Resize/compress assets before encoding: although image validation allows 10 MiB, the current local bridge caps the entire serialized request at 1 MiB, including base64 and JSON overhead.
• External briefs or tabular data: translate the relevant content into one Blueprint; do not reproduce the source application's UI interactions in Continuum. Use Mermaid when the requested result is one Mermaid graph, and Document Recipe for a composed calculation document.
• Connection issues: use the configured MCP connection first. For a custom Demo or development profile, supply its actual descriptor with --descriptor or CONTINUUM_MCP_DESCRIPTOR; do not assume the production profile. Repository exploration and UI automation are fallback diagnostics, not part of normal Canvas authoring.

Connect an MCP host

The integration is available in the packaged macOS and Windows apps. Keep Continuum open so its local bridge is available, then add this server to your MCP host configuration. This example assumes Continuum is installed in /Applications:

{
  "mcpServers": {
    "continuum": {
      "command": "/Applications/Continuum.app/Contents/MacOS/Continuum",
      "args": [
        "/Applications/Continuum.app/Contents/Resources/app.asar/dist-mcp/mcp/server.js"
      ],
      "env": {
        "ELECTRON_RUN_AS_NODE": "1"
      }
    }
  }
}

Adjust both paths if the app lives elsewhere. Restart or reconnect your MCP host after changing its configuration. The server finds the short-lived local capability created by the running Continuum app; you do not copy a payment API key into your MCP client. Workspace MCP access requires Pro or an active trial in the running app.

For the default per-user Windows installation, replace YOUR_NAME in this equivalent configuration:

{
  "mcpServers": {
    "continuum": {
      "command": "C:\\Users\\YOUR_NAME\\AppData\\Local\\Programs\\Continuum\\Continuum.exe",
      "args": [
        "C:\\Users\\YOUR_NAME\\AppData\\Local\\Programs\\Continuum\\resources\\app.asar\\dist-mcp\\mcp\\server.js"
      ],
      "env": {
        "ELECTRON_RUN_AS_NODE": "1"
      }
    }
  }
}

For a source checkout, run npm run mcp:build and configure your host to execute node /absolute/path/to/Continuum/dist-mcp/mcp/server.js.

Tool reference

Blueprint contract

• get_blueprint_schema — the normalized Blueprint schema and a YAML example.
• validate_blueprint — local Blueprint YAML or JSON validation.
• stage_blueprint — a reviewed new, merge, or replace proposal.
• stage_canvas_layout — a reviewed Canvas proposal that moves existing items in place and can add structural lines, labels, frames, or local image assets.
• stage_canvas_image — stages a single local PNG, JPEG, WebP, or GIF image from a data URL for in-app review.
• get_blueprint_proposal_status — pending, approved, rejected, or expired status.

Document Composer

• get_document_recipe_schema — the versioned Document Recipe schema and example.
• validate_document_recipe — calculations, block limits, bindings, interpolation tokens, and rendered-preview validation without mutation.
• list_documents — local document identifiers, titles, revisions, and custom-composition ownership.
• get_document_recipe — canonical source plus the current editable recipe, when present.
• stage_document_recipe — a reviewed new, append, or replace proposal. Append preserves existing calculations and replaces the complete custom composition; replace rewrites both with a stronger warning.
• get_document_proposal_status — pending, approved, rejected, expired, or stale status.

Recipes use the same metric, comparison, timeline, resilience, readiness, summary, and conclusion components as built-in templates. Values are literals or bindings to named Continuum calculation symbols. Narrative text supports bounded tokens such as {{runway_months|number}}; it does not execute JavaScript or another expression language. A document may own one custom composition and cannot combine it with template: or scenario preview ownership.

Canvas workspace

• list_canvases — titles and identifiers for local canvases.
• get_canvas_blueprint — one Canvas as canonical Blueprint YAML.

Mermaid graphs

• get_mermaid_guide — logical-model templates and Continuum’s architecture sample.
• validate_mermaid — local Mermaid parsing without a workspace change.
• list_mermaid_graphs — persistent Mermaid graph nodes across canvases.
• get_mermaid_graph — one graph’s canonical Mermaid source.
• stage_mermaid_graph — a proposed Mermaid node for a new or existing Canvas.

Safe staging and approval

stage_blueprint, stage_mermaid_graph, stage_canvas_layout, stage_canvas_image, and stage_document_recipe create memory-only proposals. A proposal identifies its MCP client, requested mode, source diff, validation result, and live result inside Continuum. Document proposals record a target revision and refuse approval if the source changed after staging; approval is one editor-history update. Layout proposals preserve the IDs, content, and relationships of existing items; they only move them and can add structure or a local image. Image inputs are base64 data URLs for PNG, JPEG, WebP, or GIF files up to 10 MiB; Continuum does not fetch remote URLs and stores the image locally only after approval. Every proposal expires after 30 minutes and changes the workspace only after an explicit Approve action. Rejecting it or closing the app leaves documents untouched.

The local capability descriptor and Unix socket or Windows named pipe stay inside the current user's application context and use a short-lived capability token. This protects the handoff between the MCP process and the running app; it is workflow integrity, not a replacement for operating-system account security.

Architecture graph workflow

The built-in Continuum architecture sample demonstrates the full path:

1. Call get_mermaid_guide to retrieve the canonical architecture source.
2. Use validate_mermaid while refining the logical model.
3. Call stage_mermaid_graph with applyMode: "new" or applyMode: "merge".
4. Review the rendered graph and requested destination in Continuum.
5. Approve it to add a persistent Mermaid node, or reject it without changing the Canvas.

The same diagram is included in the source repository as examples/continuum-architecture.mmd. It maps the browser and desktop surfaces, local workspace, Graph Explorer, Blueprint provider boundary, MCP bridge, and approval step.

Boundaries

• There is no remote MCP endpoint, hosted relay or MCP OAuth flow. Sign in to Continuum itself for Pro licensing.
• The MCP server does not call an AI provider. Blueprint’s optional provider is configured separately in the app.
• Composed documents render in browser and desktop builds. Local workspace MCP access belongs only to a running Continuum desktop app.
• Continuum’s MCP server is provider-free. The connected MCP client authors a recipe; Continuum validates, previews, and stages it.
• Read tools can expose the Canvas or Mermaid source you explicitly ask the MCP client to retrieve. Review your host and model provider’s privacy behavior before sharing sensitive models.
• Approval protects workspace mutations. It does not authenticate every process already running as your operating-system user.