MCP Connector LIVE · Pro & Team

The LatticeRun MCP connector lets your AI agents read and update your task trees directly. Point Claude Code, Kimi, Hermes Agent, or another MCP-compatible client at your account and it can list projects, inspect branches, add tasks, check things off and keep your tree moving — while you see every change live in the app.

Two ways in

Pick by what your client can do. Apps that let you set a header take a token you paste; apps that only offer a “connector” or “custom integration” box use the sign-in flow. Both reach the same server with the same powers.

A · Sign in (claude.ai, Claude Desktop, mobile)

B · Paste a token (Claude Code, Kimi, Hermes, your own scripts)

Client configuration

Claude Code:

claude mcp add --transport http latticerun https://mcp.latticerun.com/mcp \
  --header "Authorization: Bearer latticerun_your_token_here"

Kimi, Hermes, or another MCP client (JSON config):

{
  "mcpServers": {
    "latticerun": {
      "type": "http",
      "url": "https://mcp.latticerun.com/mcp",
      "headers": {
        "Authorization": "Bearer latticerun_your_token_here"
      }
    }
  }
}

The protocol

An agent that can edit a board is useful. An agent that stays inside claimed work and accounts for what it changed is the reason LatticeRun exists. The connector checks that execution sequence. Planning remains optional and becomes visual when you ask for it.

1. Claim. latticerun_start_task takes the branch and hands back the project brief, the task's place in the tree, the whole branch with its ids, bounded current Project Memory and Project Plan context, the active sprint and the decisions already taken. There is no separate "remember to read the context" step, because claiming is reading it.
2. Plan when you choose. A founder, an agent, or both can draw and edit the Project Plan flowchart; using an agent's Plan Mode is optional. Approval and release create or link executable tasks, whose progress rolls back up through the plan. You can also use latticerun_plan_task for a task breakdown. LatticeRun does not require planning before code.
3. Work. While an agent holds a claim, that task and everything under it are its to change. Nothing else is. One claim at a time. Files a task needs attach with latticerun_attach_file and appear in the project's Files panel.
4. Report. latticerun_complete_task takes a sentence on what was built and, when checkout succeeds, writes a proposed Project Memory checkpoint. latticerun_release_task hands a branch back with the reason — a plain hand-back; pass blocked: true when a human must unblock it, and the successful checkout writes a proposed blocker handoff. For intentional retirement, call latticerun_create_handoff; a hard crash cannot guarantee a handoff.
5. Approve. Anything a human must sign off before it ships — a blog draft, a spec, a plan — is filed as an artefact with latticerun_create_artefact. One thread per task: repeat filings join the open artefact as new sections, each decided on its own, and reviewers leave comments — on the thread or on a single section — that the agent reads on its next pass. The decision arrives on the agent's next claim, and approved work is executed with latticerun_mark_artefact_executed. A rejected thread is closed.

Completing work without rewriting agent.md builds a visible debt, which is what makes the brief actually get written rather than merely asked for.

How hard this is imposed is yours to set, per project, from the Agent menu → Agent protocol, or in the Project Context dialog. New projects start on Strict; projects created earlier keep their current level until you change it:

Level	What happens
Off	Nothing is checked. Agents change what they like, in any order.
Guided	Guided nudges with corrections; nothing is refused. It does not guarantee that an agent writes a handoff.
Strict (new projects)	Strict enforces the claimed branch: writes outside it are refused, and an agent that owes the brief a rewrite cannot claim anything new until it writes one. It still cannot guarantee a handoff after a hard crash.

Agents can read the setting. No tool changes it — a guardrail an agent can lower is decoration.

While an agent holds a task, the board says so: a live pill on the task, the agent's own sentence about what it is doing, and a blocked marker with the reason on anything it gave up on. That is the point of the whole thing — you stop scrolling back through a terminal to find out what was decided and what is left.

Available tools

Tool	What it does
latticerun_start_task	Claim a branch and get the brief, the tree, decisions, and bounded current Project Memory/Project Plan context
latticerun_plan_task	Optionally break the claimed task into visible sub-tasks
latticerun_create_plan / latticerun_get_plan	Create or read the Project Plan
latticerun_apply_plan_operations	Update a draft plan with revision safety
latticerun_submit_plan_for_review	Lock a revision for founder review
latticerun_get_context_bundle	Read bounded plan and Project Memory context
latticerun_read_knowledge	Read one Project Memory record in full by id — approved guardrails travel complete in bundles; this is the way to the full text of anything shortened
latticerun_record_knowledge	Propose a durable Project Memory record
latticerun_create_handoff	Leave a durable successor-agent handoff for intentional retirement
latticerun_complete_task	Finish a task; successful checkout writes a proposed Project Memory checkpoint
latticerun_release_task	Hand a task back with the reason — plain by default; blocked: true marks it blocked and writes a proposed blocker handoff
latticerun_record_decision	Record a choice and reasoning, mirrored into Project Memory for relevant, bounded future claim context
latticerun_create_artefact	File a draft for human review; repeat filings on the same task join the open artefact as sections
latticerun_add_artefact_draft	Post a new section onto a thread — how a revision request is answered
latticerun_mark_artefact_executed	Mark approved work executed (an agent's only artefact move)
latticerun_list_artefacts / latticerun_get_artefact	List artefacts (status, task, author, sections), or read one's full thread with decisions, notes and the reviewer's comments
latticerun_create_project	Start a new project from scratch
latticerun_list_projects	List your projects (name, progress, linked parents)
latticerun_get_tree	Read a project's full task tree
latticerun_attach_file	Attach a file to a task — an upload URL for big files (your shell POSTs the bytes; up to 1.5 MB), a public sourceUrl, or inline base64 for small ones — it appears in the Files panel
latticerun_list_files	Map the files attached across the project's tasks
latticerun_add_task	Add a task or sub-task under any node
latticerun_toggle_task	Mark a task complete / reopen it
latticerun_rename_task	Rename any task
latticerun_remove_task	Remove a task (and its branch)
latticerun_set_due_date	Set or clear a task's due date
latticerun_post_message	Reply in the project chat where someone has already spoken — agents cannot start a conversation
latticerun_list_sprints	See the project's sprints and which one is active
latticerun_create_sprint	Create a timebox with a name, dates and a goal
latticerun_start_sprint	Make a sprint the active one, closing the last
latticerun_set_task_sprint	Pull a task into a sprint, or take it out
latticerun_identify	Say which model you are running — recorded and shown as the agent's own claim
latticerun_guide	How LatticeRun works and the protocol expected of agents
latticerun_whoami	This connection's identity: token, label, live-slot state and the account's live-agent cap
latticerun_read_context	Read the project's agent.md brief
latticerun_write_context	Rewrite that brief for the next agent

What each tool is allowed to do

Every tool carries a plain-English title and the standard MCP behaviour hints, so a client can decide what it may run without asking you. They are sent with the tool list, and we hold them to a written rule:

• Read-only (12): latticerun_guide, latticerun_whoami, latticerun_read_context, latticerun_read_knowledge, latticerun_list_artefacts, latticerun_get_artefact, latticerun_list_files, latticerun_list_projects, latticerun_get_tree, latticerun_list_sprints, latticerun_get_plan and latticerun_get_context_bundle. They change nothing.
• Can delete or overwrite (8, marked destructive): latticerun_remove_task, latticerun_write_context (replaces the agent brief), latticerun_rename_task, latticerun_set_due_date, latticerun_toggle_task (also reopens or closes the sub-tasks), latticerun_start_sprint (closes the running sprint), latticerun_set_task_sprint and latticerun_apply_plan_operations.
• Add only (18): everything else that writes. It creates a record, claims or hands back a task, or files something for review; what was there before is kept in the history. latticerun_attach_file is the one tool that can reach outside LatticeRun, when you give it a public sourceUrl to fetch.

Sprints

A sprint is a named stretch of time with a goal, and a set of tasks pulled into it from anywhere in the tree. Tasks do not move — a sprint says when you are doing something, not where it belongs — so a sprint's work can cut across branches without flattening the structure that makes the tree useful.

Agents are asked to check latticerun_list_sprints before picking up work, so they pull from the current commitment rather than the open backlog, and to put anything they add for that timebox into the sprint with latticerun_set_task_sprint. Creating and starting sprints is left to the owner: the cadence is a human decision, and an agent inventing one is a surprise nobody asked for.

The agent brief

Every project carries an agent.md: the compact standing brief for the stack, constraints and conventions an agent needs before it starts. It is stored with the project, shared with connected agents on claim, and editable from Agent → Project Context. Agents compact it with latticerun_write_context instead of turning it into a log.

Project Memory sits beside the brief as shared, durable project context: decisions and reasoning, guardrails, architecture, checkpoints, risks and successor handoffs. Claims receive a relevant, bounded, trust-labelled context bundle; proposed agent records remain distinct from approved or verified facts. latticerun_record_decision mirrors durable decisions into Project Memory, and successful completion or blocked-release checkouts add proposed operational records.

These surfaces do different jobs: agent.md is the compact standing brief, Project Memory preserves durable context, task notes stay attached to work, and Activity records what happened.

Scope & safety

• Tokens are scoped per account and can be revoked anytime from the same menu — revoking takes effect on the very next request.
• Only a SHA-256 hash of each token is stored, so a database leak cannot reveal a working token. The same is true of everything the sign-in flow issues — authorization codes, access tokens, refresh tokens.
• An app you sign in to holds an hour-long access token that renews itself, not a permanent key. Approving the same app again replaces its access rather than granting a second lot, and disconnecting it kills both halves at once.
• Tokens stop working the moment an account drops off an eligible plan.
• Agents only reach projects your account owns. A project someone else shared with you is outside what your tokens can read or change — narrower than your own access, deliberately.
• Every agent change syncs like a normal edit and is recorded in the project's Activity feed, stamped with the token that made it. Undo is a local history of your own edits, so an agent's change is not something you can Ctrl-Z — reopen or delete the task instead.

Limits

Agent tokens are for your agents, not a way to give another person access without a seat. Three things keep that honest:

• A cap per plan. Solo Pro and Founder Lifetime issue up to 3 tokens; Team Block gets two per seat (minimum 5). Revoke one to issue another. Apps you connect by signing in do not count against it — connecting Claude on the web, the desktop and your phone should not cost you the tokens you keep for your own agents.
• A rate limit per token. Each token gets 120 calls a minute. That is generous for one agent and uncomfortable for several people sharing one, so give each agent its own token.
• A live-agent cap per account. Each plan sets how many agents can be connected at once. A session lasts until it is released — nothing expires on a timer, so an agent that pauses to think keeps its slot. One session per token: sending initialize again takes that token's own slot back, telling the incumbent it was superseded. A second, different token never displaces another — at the cap, a new connection is refused with a 409 naming who holds the sessions, and nothing is touched. An agent that is finished should send an HTTP DELETE to release its slot straight away, and you can release a stuck one from Agent tokens in the app.
• An identity on every change. Anything an agent creates or edits is stamped with the token that did it, and the app shows a robot badge with that token's label next to the task. Every change also lands in the project's Activity feed, so you get the whole history rather than just the last writer.

Collaborating with other people works through seats instead: invite them from File → People & Access. Each collaborator needs their own LatticeRun account and takes one of your plan's seats.

Support and privacy

Questions about the connector: hello@latticerun.com. What the connector can see and keep is covered in the privacy policy (“Connector and agent access”, section 2). Setup, tokens and limits are on this page; the Agent Guide covers how agents are meant to work in a project.

The connector is included with Solo Pro, Founder Lifetime and Team Block. See pricing →