MCP tool reference

Every tool the Laimonade MCP server exposes to a coding agent, what each one does, and whether it reads, writes or removes — checked against the server registry at build time.

Last reviewed 17 September 2026 · maintained by Founder

What this page is

The published contract for the Laimonade MCP server, verified against server v0.10.0. An agent is told to call what this page names, so a tool documented here that does not exist is a defect rather than a stale note — scripts/check-mcp-tools.mjs compares this table against the server's own registry and fails the build if they disagree.

You do not need to memorise any of it. The server hands your assistant the workflow when it connects, so in practice you ask for what you want in plain language. This page is for when you want to know exactly what an agent can reach.

What do the permissions mean?

Every tool declares one, and your MCP client uses it to decide when to ask you first.

Most of the list is reversible. The destructive ones are marked that way because they undo a human decision rather than because data goes away — archived items are recoverable from the Archive view. delete_milestone is the exception worth knowing about: it does remove the milestone, which is why it is refused while any epic still points at one, and why cancelling is the better move when work actually happened.

Connection

| link_repository | Track GitHub repositories against the project, so commits, pull requests and CI results start feeding the board and the delivery signals that close items. Takes what git remote get-url origin prints, or owner/name, or an array — a project usually spans several. Safe to call twice: an already-tracked repository says so, and one GitHub has renamed since is corrected. | Write | | complete_onboarding | Record what the project is FOR — the business context, and the initial roadmap and backlog generated from it. A project that has never been through this has no goal, so nothing can be planned against it. Call it after the repositories are linked. | Write |

The setup order is create, link, then complete, and it is not arbitrary: linking first is what lets onboarding see the code it is writing a roadmap about.

complete_onboarding asks the PERSON its three questions through MCP elicitation rather than letting an agent answer them, because the answers are about the business and not about the repository. A client that does not support elicitation must therefore pass the three fields itself — the schema makes them optional precisely so that a client which does support it can be asked instead.

create_project has two limits worth knowing before you reach for it. It is a paid-plan feature, and the project the call is made FROM is the one that decides — so a trial project cannot create another. And it needs a connection signed in as a person: a project API key cannot create projects, which is deliberate, because an API key is scoped to the project it belongs to and creating a new one would widen that scope without anyone agreeing to it.

Finding work

Every get_* call returns a numbered menu, and those numbers are what load_items takes — there are no document ids to copy. Numbers always refer to the most recent menu in the session.

Understanding before editing

An agent that calls these two before changing existing behaviour is the difference between a fix and a regression. Both are cheap and neither costs credits.

Creating roadmap and backlog

Parentage is not write-once: an item filed without an epic can be moved under one later. Omitting a parent is better than inventing one.

Nor are epics write-once. update_backlog_item corrects an epic's title, description, acceptance criteria, priority and milestoneId — the milestone it rolls up to, which used to be settable only when the epic was created. It refuses the remaining structural fields — points, epic parent, execution metadata, review evidence — because they mean nothing on an epic: an epic has no epic parent, and its points roll up from its children. The refusal says which fields would have worked rather than only that the call failed.

milestoneId is refused on a story, bug or improvement, which inherit their milestone through their epic — and refused there even when the value is null, since passing the field at all says something about the model that is not true.

An epic attached to no milestone contributes to no roadmap progress. get_backlog_item on an epic reports its milestone as null rather than omitting the field, so that state is visible rather than merely absent.

Moving work through the board

There is no tool that marks an item Done. submit_for_review is as far as an agent can take work, by design — see what Laimonade will not do.

Reporting back

record_decision earns its place on the alternative rejected. A diff shows what was decided and never what was considered instead, which is the half somebody asks about months later and the half that is gone by then.

Resources

Resources are raw reads with no menu numbering. Prefer the tools; these exist for clients that work better with resources.

Being told when the sprint changes

laimon://sprint/current is the one resource you can subscribe to. A client that calls resources/subscribe on it is sent notifications/resources/updated whenever the sprint changes underneath it — the weekly rollover closing and archiving the previous sprint, an item being added to the sprint, an item moving into In Review.

It exists for one specific failure: an agent holding item ids from the current sprint had no way to learn the sprint had rolled over, so it found out by asking for archived items one at a time and being refused. When you get an update, re-read the resource — or pass the ids you are holding to get_backlog_items — and drop what has gone.

Nothing else accepts a subscription, on purpose. A subscription is a promise to report changes, and accepting one for a resource with no change source would leave you waiting for an event that cannot arrive. A subscription also lives only as long as the session that made it: re-subscribe after reconnecting.

Treat an update as a hint to re-read, not as a ledger. Delivery is best-effort: the notification travels on a stream your client opens shortly after connecting, so there is a brief window where nothing can arrive, and a notification sent then is dropped rather than queued. Do not infer state from the sequence of updates, and keep re-reading on your own cadence as well.

A connection granted several projects cannot subscribe to it, for the same reason it cannot read it — a resource URI cannot name which project it means. Use the equivalent tool.

Decisions waiting on you

Laimon sometimes needs a person to decide something — a sprint carrying more than its capacity, milestones past their target with nothing tracked against them. It raises those in Slack and by email, and where neither reaches you they simply pile up.

So the first read of each MCP session also carries any decisions still waiting, up to three, oldest and most serious first. Your assistant should put them to you in its own words and record your answer with answer_pending_ask — accepted to go ahead, or corrected with a note saying what to do instead. It is asked once per session, never mid-task, and a question you ignore comes back next session rather than blocking anything.

Those three are chosen most serious first, and oldest first among equals — which means three questions you never answer will sit at the top indefinitely and hide everything newer behind them. Ask your assistant to call list_pending_asks to see the whole queue, or to sort it by newest when what you want to know is whether anything has come up lately.

Why menu numbers, rather than ids?

Because an agent copying a 24-character id across three calls gets one wrong eventually, and the failure is silent — a valid id for the wrong item. Numbers are short, always refer to the list just returned, and a stale number is rejected rather than resolved to something else.

The cost is that numbers are session state. Ask for a different list and they change with it.