Describe the key this server is using and the project it is bound to. CALL THIS FIRST when you do not already know the project: it returns the project id, code and name, the key's scopes, and the project's whole vocabulary - `workflow` as `id` + `label` pairs, plus task types, priorities, ticket statuses and ticket types. Workflow statuses are defined per project and are NOT a fixed enum, so this is the only way to learn the status ids `axon_task_move` takes and `axon_task_list` filters on; `isDone` on a status marks the ones that close work. The scopes say what the key may do at all: `read` to look, `write` to create and change, `admin` for every delete. A missing scope is a refusal no retry can fix. Takes no arguments and writes nothing.

One page of tasks. Filters combine as AND, and paging is explicit: follow `nextCursor` to read more. Ids come back raw - `axon_member_list` maps an assignee id to a person and `axon_sprint_list` a sprint id to a sprint. Not every filter combination is indexed; one that is not is refused with a 400 asking for fewer filters or the default sort, not a 500.

One task in full, by key or by document id. A key has an endpoint of its own, so either form is a single request. The task carries fields this API cannot write - subtasks, attachments, blockers, time tracking - because it is serialized straight from the stored document.

Creates a task. Only `title` is required. The task is always created at the workflow's first status; `axon_task_move` takes it from there. Counts against a limit of 30 task creations a minute per reporter.

Changes a task's fields. Only the fields you send are written; anything omitted keeps its value, and a nullable field set to null is cleared. There is deliberately no `status` here. The API writes the other fields first and applies a transition afterwards, so one request carrying both can land the edits and still fail the move with a 409; `axon_task_move` owns the status instead, and nothing here can leave a half-applied update behind. `labelIds` is the field that puts labels on a task, and it is the one the app renders and `axon_task_list` filters by. The older `labels` is refused with a 400, so do not reach for it: they are different fields, not two spellings of one.

Moves a task to another workflow status, running the project's own transition rules. This is the only way to change a task's status. A rule that refuses the move is a 409 whose `details.errors` names every validator that failed - read it and fix the cause (assign the task, close the blocker, add the comment) rather than retrying the same call. Some transitions require a comment and refuse the move without one. A resolution is not set here: use `axon_task_update`, which can write one before or after the move.

Assigns a task to a project member, or unassigns it. `assigneeId` is required rather than optional, so unassigning is an explicit `assigneeId: null` and can never happen by omission.

Deletes a task for good. Needs an `admin` key. Nothing that references the task is cleaned up: its comments, its activity and any task blocked by it are all left pointing at an id that no longer resolves. The endpoint is addressed by document id, so a key is resolved to one first - that costs an extra request.

One page of the comments on a task, oldest first. The `id` of each is what `axon_comment_update` and `axon_comment_delete` take, and `authorId` is what the API compares against this key's own identity when deciding whether a comment may be edited at all.

Adds a comment to a task. It posts as the key's own identity with the author name `API`, and only comments posted this way can be edited or deleted through this API afterwards.

Replaces the text of a comment. The whole body is replaced; there is no partial edit. A key may only edit a comment it authored itself - anyone else's is a 403, an `admin` key included, and retrying will not help.

Deletes a comment for good. Needs an `admin` key. A key may only delete a comment it authored itself - anyone else's is a 403 however wide the key's scope. Unlike the other deletes in this API this one answers with a record rather than an empty response, so the deleted id comes back.

One page of tickets, newest first. This is also how a ticket id is found: tickets are addressed by document id everywhere else in this API, and the `id` field here is that id.

One ticket in full, by document id.

Files a ticket. `ticketType`, `title`, `description` and `priority` are all required - the description may be an empty string, but it has to be sent. The ticket is created open, unassigned and unlinked. It is an intake record, not work: `axon_ticket_convert` turns it into a task when someone decides to do it.

Changes a ticket's fields. Only the fields you send are written; anything omitted keeps its value, and a nullable field set to null is cleared. The status is not here: `axon_ticket_move` owns it, so a lifecycle change is always deliberate. `notifyMembers` cannot be changed after creation.

Moves a ticket through its own lifecycle. The four statuses are a fixed enum of the API's, not the workflow statuses a task moves through, and no project rules are run. Moving to `resolved` stamps who resolved it and when; moving back to `open` or `in_progress` clears those and the resolution note with them.

Assigns a ticket to a project member, or unassigns it. `assigneeId` is required rather than optional, so unassigning is an explicit `assigneeId: null` and can never happen by omission. Assigning a ticket does not assign the task a conversion creates.

Turns a ticket into a task: creates the task, links the two, and moves the ticket to `in_progress`. WHAT COMES BACK IS THE NEW TASK, NOT THE TICKET. Read `data.task` for the task that was created - its key and id are what everything else in this API takes. The ticket itself is unchanged in the response because it is not in the response; read it back with `axon_ticket_get` if you need it. A ticket already linked to a task is a 409, and the new task counts against the limit of 30 task creations a minute per reporter.

One page of sprints, newest first. This is where a sprint id comes from - the `sprintId` every task tool takes is the `id` field here.

One sprint in full, by document id. `committedTaskIds` and `committedStoryPoints` are absent until the sprint is started: they are the snapshot a burndown is measured against, written once by `axon_sprint_start`.

Creates a sprint. `name`, `startDate` and `endDate` are required. The sprint is created at status `planning` and holds no tasks: put tasks in it with `axon_task_update` (`sprintId`), then begin it with `axon_sprint_start`, which is a separate and irreversible call.

Changes a sprint's fields. Only the fields you send are written. A date is validated against the merged sprint, so moving one end alone cannot leave the sprint ending before it starts. There is no `status` field: the API rejects one outright. A sprint's status is changed only by `axon_sprint_start` and `axon_sprint_complete`.

Starts a sprint. Needs an `admin` key, and there is no way back through this API. Starting OVERWRITES the sprint's start date with the current time, and snapshots the tasks in it and their points as the commitment every burndown is measured against - both are written once and never again, so a sprint started before its scope is ready has the wrong commitment for good. A sprint that is not in `planning`, or a project that already has an active sprint, is a 409.

Completes a sprint. Needs an `admin` key, and there is no way back through this API. Every task in a done status is stamped as completed in this sprint; EVERYTHING ELSE IS MOVED OUT OF THE SPRINT - an unfinished task loses its sprint and lands back in the backlog. Check what is still open with `axon_task_list` before calling this. A sprint that is not `active` is a 409.

List the project's epics, newest first, one page at a time. An epic id from here is what a task's `epicId` takes, and `parentEpicId` is null on a top-level epic. An epic's `status` is a read-only rollup recomputed from its tasks and sub-epics, not a field anything can set.

Read one epic by id. An epic's `status` is a read-only rollup recomputed from its tasks and sub-epics, not a field anything can set.

Create an epic. There is deliberately no `status` argument: an epic's status is derived from its tasks and sub-epics, and sending one is rejected. Creating an epic attaches nothing to it - point a task at it afterwards with `axon_task_update`.

Change an epic. Only the fields you send are written, so anything you omit keeps its value. There is no `status` argument here either, for the same reason as on create.

Delete an epic. Needs a key with the `admin` scope, and there is no undo. The epic is emptied before it goes: its tasks are detached and its sub-epics re-rooted to the top level. On a large epic that cascade runs in several batches and is NOT transactional, so a failure part-way can leave tasks already detached from an epic that still exists. If this fails, re-read the epic and its tasks rather than assuming nothing changed.

List the project's versions, newest first, one page at a time. A version id from here is what a task's `versionId` (its fix version) takes.

Read one version by id, including its status and release date.

Create a version. It is always created `unreleased`, whatever dates you give it; ship it later with `axon_version_release`.

Change a version. Only the fields you send are written, so anything you omit keeps its value. This is also the way to release one: send `status: "released"`, with a `releaseDate` if the release already happened and should be backdated.

Mark a version released. Exactly the request `axon_version_update` makes with `status: "released"` and nothing else, so the release date is stamped with the current time; to record a release that already happened, use `axon_version_update` and pass `releaseDate` as well. Releasing a version that is already released leaves its release date alone.

Delete a version. Needs a key with the `admin` scope, and there is no undo. Every task carrying this fix version is detached from it first, then the version goes - so tasks survive, but their `versionId` is cleared and there is no record of which ones it was.

List the project's components, newest first, one page at a time. A component id from here is what a task's `componentIds` and a ticket's `componentId` hold; `leadId` is a member `userId`.

Read one component by id. Its `leadId` is a member `userId`; resolve it to a person with `axon_member_list`.

Create a component. Creating one attaches nothing to it; tasks and tickets point at a component of their own accord.

Change a component. Only the fields you send are written, so anything you omit keeps its value.

Delete a component. Needs a key with the `admin` scope, and there is no undo. The id is stripped from every task that carries it and cleared from every ticket that points at it first, then the component goes - so the work survives, but which items belonged to the component is not recorded anywhere afterwards.

List the project's labels, newest first, one page at a time. A label's `id`, not its `name`, is what `axon_task_list` filters on, so resolving a name to an id starts here. Putting a label on a task happens elsewhere: send the id in the `labelIds` of `axon_task_create` or `axon_task_update`, which replaces that task's whole set.

Read one label by id. `nameNormalised` is the trimmed, lowercased form the uniqueness check compares, which is why "Bug" and "bug " collide.

Create a label. Names are unique within the project, compared trimmed and case-insensitively. A name already in use is a CONFLICT rather than a quiet hand-back of the existing label, and the conflict carries that label's id in `details.labelId` - which is the id you were after, so a conflict here is recoverable rather than fatal: read the id out of the error and use it instead of retrying. This is deliberately not a find-or-create, because "Bug" and "bug " differ by a typo as often as by intent. Putting a label on a task happens elsewhere: send the id in the `labelIds` of `axon_task_create` or `axon_task_update`, which replaces that task's whole set.

Change a label. Only the fields you send are written, so anything you omit keeps its value. Renaming onto another label's name is a conflict carrying that label's id in `details.labelId`; the two labels are not merged.

Delete a label. Needs a key with the `admin` scope, and there is no undo. The id is stripped from every task's `labelIds` first, then the label goes. Unlike the other deletes this answers with a body rather than nothing: `{ id, deleted, tasksUpdated }`, where `tasksUpdated` counts the tasks that lost the label and is the only record of how far the strip reached. Putting a label on a task happens elsewhere: send the id in the `labelIds` of `axon_task_create` or `axon_task_update`, which replaces that task's whole set. Those tasks cannot be given it back afterwards: the label is gone, and `labelIds` refuses an id the project no longer has.

List the project's members, most recently joined first, one page at a time. Use it to turn a name or an email into the id other tools want. Each member carries TWO ids and they are not interchangeable: `userId` is the value `assigneeId` on a task and `leadId` on a component take, while `id` is the membership document and is accepted nowhere. Membership is managed in the Axon app; this API only reads it, so there is no tool here to add, change or remove a member.

Read the project's activity log, newest first, one page at a time. It covers what people do in the Axon app as well as what API keys do, so it is the way to see whether a change came from a teammate or from an agent: `actorName` is the literal `API` for anything this API recorded and a person's name otherwise. An event with no `taskId` is project-level rather than about one task, and the per-event `metadata` carries whatever that event type records.