Skip to main content
The product MCP (autonomy) exposes one tool per platform endpoint, each a thin translation of it. They’re grouped into the domains below plus a guidance helper.

Projects

Discover, link, and initialize projects.

Tasks

Start, poll, iterate, review, and ship coding tasks.

Preview

See a finished version, or the task’s live sandbox.

Setup

Commands, env vars, validation, and the agent-driven setup chat.

Full Mode

Proxy the app’s API calls to your staging backend.

Governance

Coding standards, PR template, and project info.

Knowledge

Space Pages, workspace memories, and skills.

Sandbox

Reset a stuck project and keep its template fresh.

​
Conventions

  • IDs - most tools take a project_id; task tools also take a task_id. Get both from list_projects and list_tasks / get_task.
  • Background work - start_task, continue_task, and complete_task return immediately and run in the background. Poll get_task to track them.
  • New task vs follow-up - start_task opens a new task; continue_task adds to one that exists. Two tasks can’t be combined after the fact, so send a refinement of existing work through continue_task, not a second start_task - except on an archived or discarded task, which continue_task refuses.
  • Tool annotations describe what a tool actually does, not what it’s named for. readOnlyHint is true only for tools that write nothing at all (e.g. list_projects, get_task_pr_diff), and most writes carry idempotentHint so a client can tell a repeatable write from a one-shot one. Note that the MCP spec defaults destructiveHint to true once readOnlyHint is false, so a write that does not set it reads as potentially destructive whether or not it is - today only get_task and refresh_pr_status set it explicitly. Don’t infer from a missing destructiveHint that a tool is risky; check its description.
  • get_task is not read-only. For a task already sent to devs it first reconciles PR merge/close state, which can flip that task - and the project’s other recent sent tasks - to merged or closed. The write only copies what the git provider already says and repeating it changes nothing further, so it’s annotated destructiveHint: false, idempotentHint: true. If your client still prompts for approval on non-read-only tools, allow get_task once in its permission settings - you poll it constantly.

​
Response paging

Tools that return large payloads — code diffs, message logs, agent traces, spec docs, validation output, setup files — cap each response at ~200,000 characters (roughly 50k tokens) so one call can’t dominate the calling agent’s context window. When a response is capped, it includes a next_offset field pointing at the next character to read. Pass that value back in as offset to fetch the next slice; keep calling until next_offset is null. The tools that take an offset parameter are get_task_messages, get_task_pr_diff, get_task_spec_version, get_coding_standards, get_space_page, get_setup_validation_status, and get_setup_files. Other read tools return a bounded slice in a single call and don’t need paging.

​
Guidance helper

load_autonomy_skill(name) returns a built-in step-by-step playbook - no platform call. Names: setup, full-mode, tasks, troubleshooting. The server also exposes prompts: /autonomy-getting-started, /autonomy-setup, /autonomy-new-task, /autonomy-full-mode.
These reference pages are generated from the MCP server’s tool definitions, so they stay in sync with the code. If a tool’s signature changes, its page changes with it.