io.github.Developyn/laver-mcp

Add one item to a ticket's checklist. This is where acceptance criteria belong when they are meant to be ticked off one at a time rather than read as prose: they show as a progress count on the card, and update_subtask is how each one gets marked done. It appends to the bottom of the list. Plain text, not Markdown — an item is a line on a checklist rather than a document, so write the criterion as a sentence and put the detail in the ticket's description. One item per call; a checklist of seven is seven calls. A ticket you cannot open is a 404.

Add markdown to the END of a page that already exists. This is the tool for writing what you learned into your own section of a shared page — the thing create_wiki_page cannot do without leaving you a second page of the same name. It ADDS ONLY: it cannot change or remove a word that is already on the page, which is exactly why it is safe to offer where a general edit is not. There is still no tool to edit or delete existing content; if you need to correct something you appended, append the correction. Takes NO version and never conflicts — two agents appending to the same page at the same moment both get their text, in whichever order the server serialises them, and neither is asked to retry. Markdown is converted server-side by the same parser create_wiki_page uses, so headings, lists, tables, code blocks and links all survive; lead with a heading if you want your section to be findable. The reply is the page's identity and its new version, deliberately NOT the page body — appending does not need you to have read the page, and getting the whole document back is the cost this tool exists to avoid. Markdown that is only whitespace is a 400 rather than a version bump for no change. Needs write access to the workspace: a read-only role or a guest key is a 403 and retrying cannot fix it.

Move a ticket to the workspace trash — the recoverable half of deleting. It leaves the board, stops appearing in list_tickets and search, and get_ticket answers 404 for it, but it can be restored for 30 days from the workspace's trash in the web app, and is destroyed automatically once that window passes. This server has no restore tool, so from here archiving is a door only a person can reopen. It takes no `version` and cannot 409 — archiving is not a field edit, so there is nothing to conflict with. Already archived, never existed, and on a board you cannot open are all the same 404, so a retry is safe and a 404 tells you nothing about tickets you cannot see. If you intend to destroy the ticket permanently, call get_ticket FIRST and keep its `workspace_uuid`: delete_ticket needs one and an archived ticket can no longer be read to find it.

Add a comment to a ticket. Markdown in `body` is parsed — headings, lists and code fences all render. Comments are not versioned: this takes no `version` and cannot 409, so it is the one write that is always safe to make against a ticket somebody else is editing, and it is the right way to report something rather than editing the description out from under them. It is also the write a read-only key can still make — a `commenter` role is refused update_ticket and move_ticket with a 403 but allowed this. A ticket you cannot open is a 404. Posting does not mark the thread read on your behalf.

Create an automation rule on a board from a trigger, one to twenty actions, and optional conditions. READ THIS BEFORE CALLING IT: the rule runs as the user this API key acts as, every time it is triggered, for as long as it exists — a standing grant of that person's permissions to anybody who can cause the trigger, not a one-off write like every other tool here, and the resulting history is attributed to them. This one takes effect immediately: the rule is live as soon as it is created and fires on its trigger within a couple of seconds, so do not create one speculatively to see what it would do. Creating one requires a workspace OWNER or ADMIN — a member who can otherwise write on the board is a 403 and retrying cannot fix it. A 402 means the plan's per-board rule limit is already reached (two on free) and nothing was created. Conditions are a flat AND of field/operator/value tests and every one must hold; the operators a field accepts differ, so `title contains x` is valid where `title is x` is a 400 listing the operators title takes. `run_as_user_uuid` defaults to the key's own user, and naming somebody else is refused unless they are an active member who can write and can see the board. Rules arrive switched on unless you pass `enabled: false`. The `schedule` and `ticket.due` triggers are not events and REQUIRE `trigger_config`: a schedule fans out over every ticket the conditions select at its appointed time, in UTC, so give it conditions unless you really mean the whole board; a due-date rule fires once per ticket per threshold and never retroactively, so creating one does nothing to work that is already overdue. `column.empty` is the odd one: it is about ONE ticket rather than the board, so it requires a `task_uuid` alongside `trigger_config: {status_uuid}`, and it fires the moment that column holds nothing — which may be the moment you create it, since a column that is already empty is already empty. It also keeps doing it every time that column empties aga…

Create a board in a workspace. Without `template` the board arrives with Laver's default columns; with one it is seeded with that template's columns, labels and a few example tickets. `template` accepts exactly "crm" or "sales-leads" — anything else is a 400 from the schema, so do not guess an id. A template applies once, at creation: there is no way to apply one to an existing board and no link back afterwards, so a board created without one has to be arranged by hand. A workspace you cannot open is a 404, and a 402 means the plan's board limit is already reached and the board was not created — neither is worth retrying.

Define a custom field on a board — a column of structured data every ticket on that board can carry, in addition to its description. Types: text, number, date, checkbox, select, currency. A `select` REQUIRES `options` and is refused without at least one; a `currency` takes a three-letter ISO 4217 code in `currency` (checked against the real list, so 'ZZZ' is a 400). The type cannot be changed afterwards — there is no answer to what a text value should become as a number that is not a guess — so a field of the wrong type has to be deleted and made again, losing every value stored in it. Defining a field requires a workspace OWNER or ADMIN; an ordinary member who can edit tickets is a 403, even though that same member may fill the field in once it exists. The reply carries the new field's uuid, which is the key update_ticket writes values against.

Add a group to a board — the horizontal swimlanes tickets are sorted into, as opposed to the status columns they move through. A ticket's group is set with update_ticket, not here. Appended to the bottom; reorder_groups moves it. There is deliberately no tool that renames a group: the API has no route for it, so a group named wrongly is deleted and made again. A board you cannot open is a 404.

Create a workspace label. Names are unique ignoring case and surrounding space — 'Bug', 'bug' and ' bug ' are one label — so creating one that exists is a 409 rather than a second label. List_labels first and reuse the uuid you find rather than calling this to see whether it conflicts. A colour is REQUIRED — six-digit hex, '#d97757' — because a label with no colour is a label nobody can pick out on a board. The new label exists workspace-wide immediately and appears on every board, but is on no ticket until update_ticket puts it there. The reply carries its uuid, which is what `label_uuids` takes.

Add a status column to a board. It is appended to the right-hand end; reorder_statuses is how it goes anywhere else. The reply carries the new column's uuid, which is what create_ticket and move_ticket take, so a column can be created and filled without re-reading the board. Names are not unique — creating "Review" twice gives you two columns called Review and no error — so read get_board first if you mean to check. A board you cannot open is a 404.

Create a ticket on a board. Give either `status` (the column name) or `status_uuid`; with neither it lands in the first column. Markdown in `description` is parsed — headings, lists and code fences all render. It is appended to the bottom of its column unless you send a `position`. The reply is the new ticket, including the `uuid` to reference it by and the `version` any later write to it will need, so there is no need to re-read it before your next call. This tool sends no idempotency key, so calling it twice makes two tickets: on a timeout or an unclear failure, use list_tickets with `q` set to the title to see whether the first one landed before you retry.

Write a NEW page into a wiki, with its body as markdown. This is how an agent puts findings somewhere durable instead of handing them back as chat text. `wiki_uuid` comes from list_wikis; `parent_page_uuid` (from get_wiki_tree) nests the new page under an existing one and is where a page belongs unless it is genuinely top-level. The markdown is converted server-side by the same parser ticket descriptions and comments go through — headings, lists, tables, code blocks, blockquotes, horizontal rules and links all survive. An `` image survives too, as a reference to that URL — but only for a URL already hosted somewhere public, because there is no tool here to upload an attachment, and an image the reader cannot fetch renders as a broken one. Raw HTML is kept as literal text rather than interpreted, so do not reach for it to get something markdown lacks. ADD ONLY: there is deliberately no tool to change or delete what is already on a page. Wiki pages have a live collaborative editor behind them, so a whole-document overwrite from here would silently destroy whatever a person had open at the time. Adding cannot damage anything, so it is offered and overwriting is not. Do not call this twice to 'update' a page; you will get two pages — to add to a page that already exists, use append_wiki_page. Creating a page needs write access to the workspace: a read-only role or a guest key is a 403 and retrying cannot fix it. A title is required and a body is not, so a page can be created empty and filled in by a person later.

Delete an automation rule. It stops firing at once and the rule is gone — there is no trash for one and nothing here restores it, so a rule deleted by mistake has to be rebuilt from what you read before deleting. It also takes the rule's ENTIRE RUN HISTORY with it: after this, list_automation_runs has nothing, and the record of what the rule did to which tickets survives only in the workspace audit log. If the goal is to stop a rule rather than to be rid of it, update_automation with `enabled: false` does that reversibly and keeps the history. Requires a workspace OWNER or ADMIN and the current `version`; a stale version is a 409 carrying the current one, which is the guard against deleting a rule somebody else has just changed under you. The reply is empty on success.

Retract one of YOUR OWN comments. As with editing, only the author may do it and anybody else's comment is an indistinguishable 404. The comment leaves the thread immediately and goes to the workspace trash, where a person can restore it for 30 days — there is no tool here that restores one, so from an agent's side treat it as final. Deleting a comment nobody has replied to is unremarkable; deleting one that a colleague has already answered leaves their reply talking to nothing, so prefer update_comment with a correction when the thread has moved on. A comment already deleted is the same 404 again, which makes a retry safe and tells you nothing.

Remove a custom field definition from a board, and with it every value any ticket on that board held in it. This is the destructive one in this group: the values are not archived, do not go to the trash, and cannot be recovered by restoring anything — deleting a field to recreate it loses the data even if you spell the name identically. There is no confirmation and no dry run, so read list_custom_fields and decide first. Requires a workspace OWNER or ADMIN. A field that is not there, or a board you cannot open, is a 404.

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.`) and never reaches the ticket; naming your own workspace for a ticket that does not live in it is a 404. Keep this for tickets that should never have existed: a duplicate, a probe, a test fixture you created. Anything a person might want back can simply be left archived, where it expires on its own. The 404 is otherwise deliberately undistinguished — not archived, already destroyed, and a board you cannot open all look identical.

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 round-trip an action list you did not read as an admin. A rule on another board, or a board you cannot open, is the same 404.

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` when you came for the uuids.

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 update_ticket wants. A ticket you cannot open answers 404, the same 404 as one that never existed, so a 404 here is not proof the ticket is gone.

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 same machine as the agent, since the client starts it as a subprocess) and returns the path and size instead of the content. Files over 4 MB always need `save_to`, whatever their type, because an inline result that size costs more context than the answer is worth. Missing, still uploading, deleted, or on a ticket you cannot open are all the same 404.

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.

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 working hours: a ticket that sat over a weekend counts the weekend. `gaps` is the honest part of the reply and is worth reading before quoting any number — a ticket created before its board recorded moves has `no_move_recorded`, and `chain_broken` or `status_mismatch` mean the history and the ticket's current column disagree, so the totals are a floor rather than a measurement. The current column's visit is still open, with `left_at` null, and its hours grow until the ticket moves. A ticket you cannot open is a 404, the same 404 one that never existed gives.

One wiki page in full, with its content 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. This server can create a page (create_wiki_page) and add to the end of one (append_wiki_page), but cannot change or delete what is already written: to correct something, append the correction rather than planning to edit the page.

What a wiki page said at an earlier version — its title, content 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. There is deliberately no tool here that puts an old version back — read it and append the wording you want, because a restore overwrites whatever a colleague has open in the live editor right now.

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; pass `include_no_match: true` when the question is why nothing happened, because then they are the entire answer. `depth` above zero means the run was set off by another rule's write rather than by a person, and a run stopped at the depth cap is how a rule that feeds itself shows up. A ticket that has since been deleted or moved to another board keeps its run with a null title rather than vanishing. Deleting a rule destroys its history with it. Board access is enough to read this — deliberately, since being told why the board did something to your ticket is not the same power as writing rules.

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 rather than this. A rule that switched itself off after looping shows up here as `enabled: false` with a `disabled_reason`. Board access is enough to read them, which is wider than creating one. A board you cannot open is a 404, the same 404 a board that never existed gives.

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 access, where defining one needs a workspace admin.

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_off`, or `unavailable` for a cause an admin cannot act on, such as a plan that no longer includes publishing. An archived page still holding a token is listed on purpose: it goes straight back onto the internet the moment somebody restores it, and that state has no other way of being found. `public_wiki_pages_enabled` and `public_boards_enabled` are the workspace-wide switches, so every row can be dark for one reason. At most 500 rows of each; `truncated` says if that happened. Requires a workspace OWNER or ADMIN — an ordinary member is a 403, a non-member a 404 — and it grants no access a reader did not already have, since every link here is public by definition. Taking one back down is deliberately not a tool: report what is published and let a person decide what to unpublish.

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_uuids` for tickets that left the board or went out of view. Use the server's clock for that rather than your own, which is the whole point of `server_time` — your clock can drift and silently skip a ticket. Archived tickets are never returned.

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 200 at most, no cursor and no paging — so a `limit`-sized reply means there may be more and you cannot ask for the rest from here. Narrow it, or go board by board with list_tickets. It shows only the boards this key can open, so a restricted member's triage is their own boards and the reply never says which ones were left out. Archived tickets are not in it.

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 — and it reports `unread_comment_count: 0` with the moment it recorded. Reading is not affected: the thread is still fully readable afterwards.

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 read. The ticket is appended to the bottom of the column it arrives in unless you send a `position`; it does not keep the number it had in the column it left.

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 board a term names without listing every board first. Matches whole words and prefixes, not mid-word substrings: 'deploy' finds 'deployment', 'eploy' finds nothing. Three characters minimum. Returns a short line per hit, not the full ticket or comment — follow up with get_ticket, get_ticket_comments or get_wiki_page. Each excerpt marks the matched words with the control characters \x01 and \x02 rather than with markup; strip them before showing the text to anyone.

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. To search tickets and wikis together across a whole workspace, use `search` instead.

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 exists; read `blocked_by` and `blocks` on the ticket for that. Either uuid being unreadable, on a board you cannot open, or nonexistent is a 404.