Leave a comment on a task - a question, a blocker, or progress context for the humans watching the board. Use add_result for the actual deliverable.

Attach your output to a task: what you did, what you produced, where it lives. Post this before moving the task to done, so the work is auditable. Requires that you hold the claim.

Instance-level administration: change someone's instance role, make someone a manager of a board, or mint and revoke API keys. Off unless the operator sets PLANKA_ALLOW_USER_ADMIN, and this server will never raise its own account's role or hand out admin.

create_api_key returns the key once - Planka cannot show it again, and it replaces any key that account already had, breaking whatever was using it. A key is a long-lived credential that acts as that person, and the value will pass through this conversation and any transcript of it, so treat the output as a secret and hand it over out of band. revoke_api_key clears one.

Assign people to a task, adding them to the project first if they are not members yet. Each name is resolved against the project's members and the user directory; an ambiguous name is reported rather than guessed. Granting project membership needs membership rights, so a worker can assign existing members but cannot pull new people onto the project.

Attach a link to a task - a pull request, document or dashboard you produced. Use this alongside add_result when the output lives somewhere else. Only tasks you hold, or unclaimed ones, can be changed.

Claim a task for yourself before working on it. This is atomic: the claim is a unique assignment row in Planka, so a second worker racing for the same task gets already_taken back and should simply pick another task. Claiming a task you already hold succeeds again without side effects. You can only ever claim a task for yourself, never for another user.

Clone a project's layout: its columns with their exact types and order, and optionally its labels and members. No cards are copied - this produces an empty project shaped like the original.

Prefer this over create_project when an existing project is the template. Naming a column 'Done' is not the same as copying it: a list's type decides whether Planka marks cards dropped there as finished, and only a copy carries that across.

Create a board - the container that holds projects (tabs).

Needs an admin or projectOwner account; Planka refuses project creation for anyone else. Create the board first, then fill it with create_project or copy_project_structure.

Add a workflow stage to a project. Note that Planka closes any card placed in a closed list, so use that type only for a genuine done stage.

Create a new project (tab) inside a board, pre-populated with workflow lists so it is immediately usable. Requires admin rights on that board.

To reproduce an existing project's layout, use copy_project_structure instead - it carries the exact list types across, which naming alone cannot.

Create a new task in the todo stage of a board - follow-up work you discovered, or a task you were asked to file. It lands unclaimed, so claim it before working on it. Labels must already exist on the board; this tool never invents board structure.

Delete an empty list. A list holding cards is never deleted - move the cards out first, or retire the stage with update_list(list_type='inactive').

Find work handed out in comments but never actually assigned.

Teams often hand off by writing "Assigned to: @Name" in a comment. In Planka that is just text: the person is not a member of the task, so it never reaches their queue, no board view shows them as owner, and it is invisible to reporting. This reports every such comment where the mentioned person is not a member of the task, and gives you the exact assign_people call that would make it real. Read-only - it changes nothing on its own. Confirm with a human before acting on findings; a mention is not always a hand-off.

Search tasks across every project you can see - including other people's.

Unlike list_actionable_tasks, which is your own ready-to-work queue, this answers questions about the whole workspace: what is Ada working on, what is overdue, where did that card about the login bug go.

Searching for a person finds all three ways work reaches them: tasks they are assigned to, tasks holding a checklist item assigned to them, and tasks where they were mentioned in a comment. Each result says which, in matched_by, and carries the specific checklist items and mentions. Results are read-only context; claiming and editing still go through the usual tools, and other people's tasks remain off limits to edit.

Full structure of one project: its lists and what status each maps to, its labels and how heavily they are used, its members and their roles, and your own role. Read this before changing structure or assigning people.

Full detail for one task: description, labels, subtasks, assignees, comments and anything it is waiting on. Use it after you claim a task, to understand what has to be done.

List tasks that are genuinely ready to be worked on, most urgent first.

Call this first, before any other tool. The filtering happens on the server: only cards sitting in a 'todo' stage of an active list, not closed, and either unassigned or already assigned to you are returned. Each entry carries what you need to choose: title, priority, due date, effort, labels, subtask counts and a description excerpt. Pick one, then call claim_task.

List the boards you can reach - the containers that hold projects. Use it to find where a project lives, or before creating a new project.

List people and their roles - members of one project, or the whole directory. Use it to resolve a partial name before assigning work.

List the projects (tabs) you can work in, with the role you hold on each. Start here when you are asked to do something on a named project.

Create, rename or remove the labels a project uses for priority, size and state. A label still applied to cards is never deleted.

Move a task to another list, or to a different project entirely. Use this for stages that are not part of the todo/in_progress/review/done flow - a 'Blocked' or 'Icebox' list, say - where update_status does not apply.

Give up your claim on a task so another worker can take it. Only your own claim is ever removed - other people's assignments are untouched. Nothing is deleted; the task and its history stay on the board.

Add people to a project, change the role they hold, or remove them from it. Requires membership rights on that project. Removing a member does not delete anything they created, and never touches their account.

Apply or take labels off a task - how you change its priority or size, since Planka stores both as labels. Labels themselves are untouched; only their link to this task changes.

Take people off a task. Their project membership is untouched - this only removes the assignment.

Rename a board (container), describe it, hide it or favourite it. Requires managing that board - instance admin, or one of its managers.

Break a task into checklist steps and tick them off as you go, so progress is visible on the board while you work. Only tasks you hold, or unclaimed ones, can be changed. Items are never deleted - reopen them instead.

Rename a list or change its type. Retiring a stage is a type change to inactive, which keeps every card intact and reversible.

Rename a project (tab) or change how it behaves: default view, the kind of task it creates, whether checklists open expanded. Requires structure rights.

Move a task you have claimed to a new status. Legal moves are todo -> in_progress -> review -> done (plus in_progress -> todo to hand work back). Illegal jumps are rejected. You must hold the claim on the task, and the board must have a list for the target status.

Refine a task's title, description, deadline or labels - for example after investigating and learning what the work actually involves. Only tasks you hold, or tasks nobody has claimed, can be edited; another worker's task is never touched.

Who this server is acting as, and what it is allowed to do. Call it when a request might exceed your rights, so you can say so instead of failing.