Laver MCP

Remove a group from a board. Unlike deleting a column this does NOT require the group to be empty: the tickets in it survive and are simply left ungrouped, which also bumps each of their versions — so anything holding a version for one of those tickets has just been made stale and must re-read before writing. The group itself does not go to the trash and cannot be restored. A group that is not there, or a board you cannot open, is a 404.

Delete a workspace label and strip it from every ticket that carries it, across every board. There is no trash for a label and nothing here restores one: recreating it by name gives a NEW uuid on no tickets, so the association is gone even if the word comes back. The reply's `label.affected_task_uuids` names every ticket it was stripped from, which is the only record of what it was on — keep it if there is any chance of wanting to put the label back. A label that is not there, or a workspace this key cannot open, is a 404.

Remove a column from a board. It has to be EMPTY first: a column still holding tickets is a 409 saying how many, and the tickets are not moved or archived for you — move them with move_ticket and call this again. A board also has to keep one column, so deleting the last one is a 409 as well. Neither refusal is worth retrying unchanged. Unlike a ticket this does not go to the trash and cannot be restored, though the tickets that were in it are untouched because you moved them out first. A column that is not there, or a board you cannot open, is a 404.

Remove an item from a ticket's checklist. This one is not recoverable — a checklist item does not go to the trash the way a ticket or a comment does, so a criterion deleted here is gone and has to be typed again. Tick it off with update_subtask when it is done; delete it only when it should never have been on the list. An item already deleted, one on another ticket, and a ticket you cannot open are all the same 404, so a retry is safe and confirms nothing.

Permanently destroy a ticket that is ALREADY in the trash, along with its comments and attachments. Nothing undoes this — not the trash, not a restore, not support. It is the second step and never the first: archive_ticket, then this. A ticket still live on a board answers 404 rather than being destroyed, so this cannot bin something in one call. `workspace_uuid` must be the workspace the ticket belongs to — from get_ticket before it was archived, or get_board for the board it was on. Naming a workspace your key was not issued for is a 403 (`This API key is scoped to a different workspace.`) a…

Remove a file from a ticket. This is the same one-way-but-recoverable move archive_ticket makes: the attachment leaves the ticket immediately and its bytes sit in the workspace trash for 30 days, after which the sweep destroys them. There is no tool here to restore one — that is the web app — so treat it as final in an agent's hands. The freed bytes stop counting against the workspace's storage quota straight away. An attachment already deleted, still uploading, or on a ticket this key cannot open are all the same 404, so this never confirms that a file existed.

One automation rule in full — its trigger and trigger_config, its conditions, its actions, whether it is `enabled`, the user it runs as, and the `version` that update_automation and delete_automation require. Read it immediately before either write: the version is the whole point of this call, and a version read minutes ago may already be stale. Board access is enough, but a non-admin sees a `call_webhook` action's url and body as "[hidden]" — the rule still reads correctly, and sending those redacted values back through update_automation would overwrite the real url with the word, so never ro…

A board with its status columns, labels, members and tickets. The status uuids returned here are what create_ticket and move_ticket expect. Each ticket carries `label_uuids` — bare uuids, resolvable against the board's `labels` list in the same reply — which is exactly the field `update_ticket` takes, so a label read from here can be written straight back without remapping. Note that `list_tickets` and `get_ticket` still return expanded `labels` objects, because neither reply has the dictionary to resolve uuids against. The tickets are around 90% of this reply, so pass `include_tasks: false` w…

One ticket in full: its fields, its `subtasks`, its expanded `labels` objects, and the `version` every write needs. Read this before you write. update_ticket, move_ticket, archive_ticket and the rest all take that version and answer 409 if it has moved on since you read it — that 409 is the signal to call this again and retry against the fresh version, never to drop the version or force the write. `labels` arrive expanded rather than as bare uuids because this reply carries no board dictionary to resolve them against; get_board returns `label_uuids` instead, and that bare-uuid shape is the one…

Fetch one attachment's CONTENT, having found its uuid with list_ticket_attachments. What comes back depends on what the file is, because a tool result is text and most files are not: a text or CSV attachment is returned inline as text; an image is returned as an image block, which is the only form the model can actually look at; anything else — a PDF, a spreadsheet, a document — cannot cross this boundary as text at all, and needs `save_to`. Pass `save_to` for any file you want on disk, and for anything large: it writes the bytes to that path on the machine THIS SERVER runs on (normally the sa…

The discussion on a ticket, as two lists: `comments` — the thread, oldest first — and `events`, the activity history the web app draws alongside it (moves, field edits, who did what and when). The whole thread comes back in one call; there is no paging and no cursor, so a very long one is simply long. Reading is free of side effects: it does NOT mark the thread as read or clear anyone's unread badge, so polling this to follow a ticket cannot make a teammate think their comment has been seen. A ticket you cannot open is a 404, the same 404 a ticket that never existed gives. READ `api_key` ON A …

How long this ticket has spent in each column, derived from the moves already recorded in its history — the answer to "where is the time going". READ `visits` RATHER THAN THE `by_status` TOTALS if you are adding several tickets up: each visit is one stay in one column with its own `entered_at`, `left_at` and `hours`, where `by_status` is those visits already summed per column — and a ticket's per-column totals overlap with another's whenever the two were worked in the same batch, so summing totals across tickets double-counts wall-clock time that was shared. The hours are wall clock, not worki…

One wiki page in full, with its body and any attachments it references. Get `page_uuid` from get_wiki_tree or from a search_wiki hit — a page uuid is not a wiki uuid, and passing one for the other is a 404. A page you cannot open is that same 404, so it never confirms that a page exists. The body comes back as `content_markdown`, in the same markdown create_wiki_page, append_wiki_page and update_wiki_page take: edit that text and send it straight back to update_wiki_page with the `version` from this reply, and nothing needs rebuilding. `markdown_omits` lists what is on the page that markdown c…

What a wiki page said at an earlier version — its title, body and who saved it. This is how you recover something that was overwritten, and it is a READ: the page is not changed and its version does not move. Reach for it the moment you find that a page no longer says what you put there. `version` counts from 1 and goes up by one on every save; the current version is on the page from get_wiki_page. A version that was never saved, and a page you cannot open, are both the same 404. The body is `content_markdown`, the same dialect the write tools take, so putting old wording back is a copy from h…

Every page in a wiki as a tree — titles, uuids and nesting — without any page content. This is the cheap way to find a page uuid when you know roughly where it sits; search_wiki is the way when you know roughly what it says. Follow up with get_wiki_page for the content of one. A wiki you cannot open is a 404, the same one a wiki that does not exist gives. A big wiki is tens of thousands of tokens of metadata, so narrow it with `parent_page_uuid` and `depth` rather than reading all of it to find one uuid.

Record that one ticket must be finished before another can start. Direction is from the point of view of task_uuid: "blocks" means task_uuid has to be done first. Every ticket read afterwards carries `blocked_by`, `blocks` and `is_blocked`, so this is how you work out what order to do things in.

What a rule has actually done — newest first. This is the tool for "why did this ticket move?" and "why is my rule not firing?", and the answers come from different halves of it. Each run carries its `status`, the ticket it acted on with that ticket's title, `actions_done` out of `actions_total`, an `error` when one failed, and the times it was enqueued, started and finished. The runs that did nothing because the conditions did not hold are `no_match`, and they are EXCLUDED by default — a rule with conditions produces far more of them than real runs, so they would bury the interesting rows; pa…

The automation rules on a board — each with its trigger, conditions, actions, whether it is `enabled`, the user it runs as, and the `version` any edit would need. These are live: a rule with `enabled: true` fires on its trigger within a couple of seconds and applies its actions as the person named in `run_as_user_uuid`. Read this before creating a rule on a board you did not set up, both because the per-board limit counts what is already here (two on the free plan) and because an existing rule may already do what you were about to add. What a rule has actually done is list_automation_runs rath…

The boards in a workspace, with their uuids and names — where you go from a workspace to something you can actually read. It lists only the boards this key can open, so a short list means limited access rather than an empty workspace, and archived boards are not in it. The uuid you want for get_board and list_tickets is here; the status uuids those need are not — get_board has those.

The custom fields defined on a board: each one's uuid, name, type and — for a select — its options. The uuid is the key `update_ticket`'s `custom_fields` is written against, and a value keyed by a field's NAME is dropped silently, so this is the read that makes writing one possible. get_board returns the same definitions alongside everything else; this is the cheap way to ask for them alone. Fields are board-scoped by design — 'Size' on one board is not 'Size' on another — so a uuid from one board written to a ticket on another is discarded without an error. Reading them needs only board acces…

Every label in the workspace, alphabetically, with its uuid and colour. This is the workspace-wide source of the uuids `update_ticket` takes as `label_uuids` — get_board only shows the ones already in use on that board, so a label another team applies elsewhere is invisible there and is here. Labels are shared across every board in the workspace: applying one to a ticket does not copy it anywhere, and renaming it changes it for everybody. An empty list means the workspace genuinely has none. A workspace this key cannot open is a 404.

What of this workspace's is on the public internet right now: `wiki_pages` and `boards`, each with its `public_token` — the share link's secret — plus who published it, when, and how many times a stranger has viewed it. This is the inventory read, and no other tool answers it, since a page or board reads exactly the same here whether or not the world can see it. Two fields carry the meaning. `live` is what a stranger actually gets, so a row is not proof of reachability; when it is false, `dark_reason` says why — `page_deleted`, `wiki_deleted`, `board_deleted`, `page_private`, `workspace_switch…

The files on a ticket: name, content type, size in bytes and uuid, newest first. Nothing else here reads a ticket's files, so this is the way to find out whether the specification an agent is working from is actually a PDF somebody attached. `get_ticket` reports `attachment_total`, which is how you know whether calling this is worth a round trip. Only finished uploads are listed — an upload still in flight and a deleted file both read as absent — and the reply carries metadata, never the bytes; get_ticket_attachment fetches those one at a time.

Tickets on a board, in board order, optionally filtered by status or by free text. This is what to read a column or walk a whole board with; get_board returns the same tickets but takes neither `limit` nor a cursor. Paging: `limit` defaults to 50 and caps at 200, and `next_cursor` comes back only on a FULL page — a short page is the end of the walk, so stop when it is absent instead of calling again, and pass it back verbatim when it is there. Following a board over time: send the `server_time` from a previous reply as `updated_since` and you get only what changed since, plus `removed_task_uui…

The wikis in a workspace, with their uuids — the only place a `wiki_uuid` comes from, so every other wiki tool starts here. `workspace_uuid` is required; start from list_workspaces if you do not have one. An empty list is not proof the workspace has no wiki: a key acting as a guest is excluded from workspace-wide reads and sees nothing here. Archiving a wiki (done in the browser; there is no tool here for it) takes it out of this list entirely, along with every page under it — pass `archived: true` to see those instead, which is also the only way to find a `wiki_uuid` for restore_wiki.

Tickets from EVERY board in the workspace at once — the triage read, and the only one here that does not need a board_uuid. Two questions it answers that nothing else can: `overdue: true` is everything past its due date and not yet in a column the board counts as finished, oldest deadline first; `unassigned: true` is everything nobody owns. Send both and you get the intersection, since the filters are ANDed rather than ORed. `q` is the same word-and-prefix search list_tickets uses, ranked, across the whole workspace. Deliberately the small sibling of list_tickets: one page, 50 by default and 2…

The workspaces this key can act in, with their uuids, names and the role it holds in each. Start here when you do not already have a workspace uuid, then go to list_boards. Through an API key this is always exactly one workspace — the one the key was issued for — even when the person who created it belongs to several, so a single entry is the normal answer rather than a sign of missing access. Archived workspaces are not in it. Each entry carries `billing_status`, which is how you tell a workspace that has gone read-only from one you can still write to, before a write fails rather than after.

Clear this ticket's unread badge for the user this key acts as. Every other tool here leaves read state alone — get_ticket_comments deliberately does not mark anything read — so this is the one call that says "I have seen the thread", and the one that clears an unread count an agent's own comment created for the person whose key it is. It marks read up to the NEWEST comment that exists right now: a comment posted a second later is unread again, so this is a point in time rather than a standing subscription. Idempotent — calling it on a thread with nothing unread succeeds and changes nothing — …

Move a ticket to another column. Give either `status` (the column name) or `status_uuid` — with NEITHER this is a 400 ("body must NOT have fewer than 2 properties") and not a no-op, and with both it is a 400 saying to pick one. A column name is matched case-insensitively and trimmed, so "to do" finds "To Do", but a name no column has is a 400 naming it, and a `status_uuid` belonging to another board is refused too — get_board is where both come from. `version` must be the one get_ticket returned; a stale one is a 409 that carries the current version with it, so the retry does not need another …

Set the top-to-bottom order of a board's groups. Same contract as reorder_statuses: send the COMPLETE list of group uuids from get_board in the order you want, and a list that no longer matches the board is a 409 ("The group list changed. Refresh and try again.") rather than a partial reorder. Tickets keep their groups; only the lanes move.

Set the left-to-right order of a board's columns. Send the COMPLETE list of status uuids in the order you want — a partial list is refused rather than applied, which is what stops two people reordering at once from silently dropping a column. Read them off get_board immediately before calling, and if a column has been added or removed since, this answers 409 ("The column list changed. Refresh and try again."): re-read and send the new complete list. Nothing moves between columns; only the order changes.

Undo an archive: brings a wiki, and every page under it, back into list_wikis and back onto the internet if any of its pages were published. `wiki_uuid` comes from list_wikis with `archived: true` — that is the only place one is visible at all, since an archived wiki is invisible everywhere else this server reads. A wiki that is not archived, one in a workspace this key cannot open, and a uuid that does not exist are all the same 404, so this never confirms that a wiki exists. There is deliberately no tool here that archives one in the first place: that half stays a browser action.

Search tickets, wiki pages AND ticket comments across a whole workspace in one call, ranked by relevance with a highlighted excerpt. Use this when you know roughly what something is called but not which board or wiki it is on — list_tickets needs a board_uuid, this does not. The reply has FOUR lists: `boards` and `tasks` and `pages` matched their own text, and `comments` are tickets found by something said ABOUT them — each carries the ticket it belongs to, and a ticket already in `tasks` is never repeated there. `boards` is easy to miss and is often the one you want: it is how you find the bo…

Full-text search inside ONE wiki, returning matching pages with a highlighted excerpt. A title match outranks a body match, so the page actually about the term comes first. A single word also matches as a prefix — 'custom' finds 'Customark' — while a multi-word query keeps the usual search semantics: "quoted phrase", -excluded, and OR. Matches are marked in the excerpt with the control characters \x01 and \x02 around each hit, not with markup; strip them before showing the text to anyone. `wiki_uuid` comes from list_wikis, and a wiki that does not exist or that you cannot open is the same 404.…

Remove the link between two tickets. Order does not matter — it finds the pair from either end, so you do not have to know which one is recorded as the blocker. Note what it removes: Laver can hold more than one kind of link between the same pair (a dependency, a related-to, a duplicate-of), a person can add the other kinds in the web app, and this removes ALL of them rather than only the dependency link_tickets creates. It is not an error to unlink a pair that was never linked — nothing matches, nothing is removed, and the call still succeeds — so this cannot be used to test whether a link ex…

Edit a live automation rule: rename it, switch it off, change what triggers it, or replace its conditions or actions. `enabled: false` is the one to reach for first when a rule is misbehaving — it stops the rule immediately and reversibly, where deleting it also destroys its run history, so pause before you delete and read list_automation_runs while you still can. `conditions` and `actions` REPLACE the stored lists rather than merging into them, so send the complete array you want, built from what get_automation returned and not from memory. Requires a workspace OWNER or ADMIN and the current …

Rewrite one of YOUR OWN comments. Only the author may edit a comment: somebody else's is a 404, exactly the same 404 as a comment that does not exist, so this never tells you who wrote what. It REPLACES the whole body rather than appending — read the comment back with get_ticket_comments and send it plus your addition if you meant to add a line. The edit is visible: the comment is marked as edited with the time, so this is not a way to make a change quietly. Comments are not versioned, so there is no `version` here and no 409 — the last edit wins, and two edits racing is simply the later one. …

Rename a custom field, change a select's options, change a currency field's code, or move it up the list. The `type` is deliberately not editable and is not a parameter here. `options` REPLACES the whole list rather than adding to it, and removing an option does not clear it from tickets that already hold that value — those keep a value the dropdown no longer offers, so read the tickets before you shorten a list. Send at least one field; all omitted is a 400. Requires a workspace OWNER or ADMIN, like defining one.

Rename or recolour a workspace label. It changes EVERYWHERE at once — every board, every ticket that carries it, for everybody in the workspace — because there is one label rather than a copy per board. That is the thing to be sure of before calling: a rename to something more specific may be wrong for whoever else is using it. The uuid does not change, so nothing holding one breaks. Renaming onto a name another label already has — ignoring case and surrounding space — is a 409. Send at least one of the two fields.

Rename a column, recolour it, or mark it as the one that means finished. `is_complete: true` is the interesting one: a board has at most ONE completed column, so setting it here silently clears the flag on whichever column held it, and the reply names what was unset. That flag is what `overdue` in list_workspace_tickets reads — a ticket sitting in a complete column is never overdue — so moving it changes what triage reports. Renaming is safe for tickets, which point at the uuid rather than the name, but it does break any saved text that named the old column. Send at least one of the three fiel…

Tick a checklist item off, rename it, or move it up the list. `is_done: true` is the common one and is what makes the ticket's progress count move; `is_done: false` un-ticks an item that was ticked too early. Send at least one of the three — all three omitted is a 400. Renaming REPLACES the whole title rather than appending to it. An item on another ticket, or on a ticket you cannot open, is a 404 naming neither.

Change a ticket. `version` must be the one from get_ticket; a 409 means somebody wrote first and you should re-read. Markdown in `description` is parsed, and it replaces the whole description rather than appending to it. `label_uuids`, `assignee_uuids` and `custom_fields` each REPLACE the whole set rather than adding to it, so send what is already on the ticket alongside what you are adding or you will silently remove the rest. `custom_fields` is keyed by the field's uuid — read them off get_ticket, since a name will not do — and a uuid no field on that board has is DROPPED SILENTLY rather tha…

REPLACE what is on a wiki page: its body, its title, or both. This is the tool for correcting a page that has gone stale — append_wiki_page can only add, so using it to fix something leaves the wrong version sitting above the right one, and a page maintained that way grows into drafts a reader cannot tell apart. Prefer append_wiki_page when you are ADDING a section; use this when something already written has to stop being there. `content_markdown` replaces the WHOLE body, not part of it: whatever you do not send is gone, so read the page with get_wiki_page first, edit the `content_markdown` i…

Attach a file to a ticket — the way an agent puts evidence on a ticket rather than describing it. Two ways to give it the bytes, and exactly one must be used. `file_path` reads a file from the machine THIS SERVER runs on (normally the agent's own machine, since the client starts this as a subprocess) and is the right one for anything that already exists on disk; it costs no context, so prefer it. `text` is for content the agent has just written — a log, a CSV, a diff — and needs `filename` alongside it. Laver refuses anything that is not one of application/pdf, application/vnd.openxmlformats-o…