Kaiku

Attach a file to an issue: pass its bytes as 'contentBase64', or its content as 'text' when the file is text. Attaching a filename the issue already has replaces that file rather than adding a second copy, so retrying this call cannot double it. A file on the person's own disk — a screenshot, a PDF — is better attached by path through the pm-files MCP server than typed out as base64; local_files_setup says how to connect it. Returns the attachment's download URL. Requires permission to edit issues in that project.

Add a comment to an issue, or reply to one of its comments ('replyTo' is a comment id from get_comments). A reply notifies the author of the comment it answers, whether or not they watch the issue — no mention needed — and they are told once even if also mentioned. Requires permission to comment in that project (read-only members cannot). Answers with 'notified' (who this actually reaches, the answered author included), 'answered' (for a reply: whose comment it answers, and 'notified' false with a 'reason' when they are not told) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land. Where the workspace has agents, [~agent:role] (e.g. [~agent:product]) calls one to answer in the thread on your behalf: 'agents' lists each call with its requestId and status, and an agent that will not come is in 'unresolvedMentions' with its reason (agent_unknown, agent_off, agent_plan, agent_budget, too_many, agent_outsider — the writer is not of the company).

Put a reference to a legal act on an issue or a wiki page — as «Add» in the block «Legal acts» does: it is yours, accepted at once. 'url' is the act's address on one of the official sites acts are read from (a refusal lists them); an act not read yet is read in the background, so 'hasText' may be false at first. 'place' is the place in the act in words («Article 18»). With 'commentId' the reference stands in that comment instead of the issue's or the page's own text. The same place of the same act already there is that reference ('added' false). Requires permission to edit the issue or the page — to comment, for a comment's — and a project that keeps legal references.

Attach a file to a wiki page, identified by 'pageId' or by 'spaceKey' + 'title': pass its bytes as 'contentBase64', or its content as 'text' when the file is text. Re-attaching a filename the page already has replaces its bytes and bumps its version, as the wiki does everywhere else, so retrying this call cannot leave two copies. A file on the person's own disk — a screenshot, a PDF — is better attached by path through the pm-files MCP server than typed out as base64; local_files_setup says how to connect it. An attached file is not *on* the page until the body references it — the answer hands you the Markdown to add with update_wiki_page. An image may also carry a dark-theme version, attached as the same name with '-dark' before the extension (diagram.svg + diagram-dark.svg); the body still references the plain name. Requires permission to edit the page.

Comment on a wiki page, or reply to one of its comments ('replyTo' is a comment id from get_wiki_page). A reply notifies the author of the comment it answers, whether or not they watch the page — no mention needed — and they are told once even if also mentioned. Identify the page by 'pageId', or by 'spaceKey' + 'title'. Markdown is rendered; mention someone as [@Their Name](user:username), the wiki's own form. Requires permission to comment in that project. Answers with 'notified' (who this actually reaches, the answered author included), 'answered' (for a reply: whose comment it answers, and 'notified' false with a 'reason' when they are not told) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Administrators only: where a bank transfer is to be sent (PM-625) — beneficiary, account and its own currency, bank and SWIFT, the intermediary bank if there is one, the purpose line, how many days a wire is given, and who last changed all of it. 'offered' is the one flag that answers «may a customer pick a transfer right now»: it is switched on AND carrying everything a payment needs, which is not the same as 'enabled'. A bill already issued carries its own frozen copy of these details and is not changed by what this returns. Amounts are always USD, whatever the account's own currency is.

Administrators only: the error collector's week — events and distinct errors per project against the week before, errors first seen that week with their release, the loudest by events and by people, and errors that came back after being resolved. The same numbers the weekly error report carries. A project the collector did not answer about has null counts and a reason, never zeros. Ask for an earlier week with weeksAgo.

Administrators only: the installation as a business over a period — registrations, how many of them became working companies, purchases and conversion by cohort, churn, and money. Money comes in two halves that must not be added together: 'stock' is what recurs every month at today's prices, 'revenue' is what actually arrived inside the period. Each carries its own currency. Figures come from the fleet's ledger, so 'machines' says how current each machine's copy is — a machine that is behind makes the totals older than they look, it does not make them wrong. 'activation' is how many of the companies registered in the period have had their first agent come in (the first request with a configured token), and how soon — within the hour, the day, the week. 'legal' is the same cohort narrowed to the companies that came for the law — the owner signed up through a page for lawyers, or the company was made with the requirements register — as four counts: registered, a project keeps legal references, a legal document's card opened in the first week, the add-on paid for. Its 'withReferences' is null and 'unknown' names the machines while they have not reported the switch — never zero. 'ai' is AI as money over the same period — what our key's calls cost at each provider, what companies were charged, the margin, the cost nobody was charged for and why, what has accrued and what 'ai' invoices still want — and is neither in 'stock' nor in 'revenue'. Its totals are null, never zero, while a machine has not reported its AI: 'ai.missing' names it and 'ai.reported' is the sum over the machines that did. Default period: the last 90 days.

Administrators only: what companies were asked to pay and what answered it — each invoice with its amount, its coin, whether it is paid and what is short, and the payments against it. Amounts are never added across coins: each row carries its own currency and they stay apart. The list is the fleet's ledger, so 'machines' says how current each machine's copy is. One invoice's delivery record belongs to the machine that took the payment and is not rolled up — the answer says so where it is missing rather than showing an empty list.

Administrators only: the landing site's week — visits, where they came from, clicks on sign-up, and the registrations that followed. The same numbers the weekly report carries into the monitoring chat. Ask for an earlier week with weeksAgo. The rendered message is not returned, only the figures.

Administrators only: how loaded this machine is and what the language models cost. Load is this machine's own — database, streams, memory, processor, traffic and stored bytes, each as used against allowed, where an allowance is known. Model spend covers the assistant, search-by-sentence and translation over a rolling window, with totals and breakdowns by feature, by model and by day; costs are estimates from the prices recorded at the time. Who spent it is not returned here.

Administrators only: the whole installation by the numbers — accounts, workspaces, projects, issues, comments and sprints, plus issues broken down by status and by project. Counted across every workspace, which is what makes it the installation's rather than one company's. A total is null, never zero, when a machine of the fleet did not answer: 'fleet' says which machines were asked and which are missing, and 'here' is always what this machine counted. The breakdowns are this machine's. Read a null as 'nobody knows', never as 'none'.

Administrators only, and this one CHANGES things: state where bank transfers are to be sent. Send the WHOLE set every time — anything left out is cleared, not kept, because details half of one bank and half of another are money sent to a mixture of two. Read admin_bank_transfer first and repeat what you are not changing. Switching the method on is refused while anything a payment needs is missing (beneficiary, account, swift, and a purpose line carrying {invoice}), and the refusal names the field; switching it off is never refused. 'minimumUsd' is a floor under the METHOD and not under the debt: a bill below it is offered the other ways to pay, and what is owed does not change. The change is recorded against the calling administrator. Bills already issued keep the details they were issued with.

Administrators only: what was done to one company and by whom — created, plan changed, period extended by hand, credited, suspended, resumed, erased — newest first, up to a hundred entries, each with the reason that was written down at the time. This is the answer to 'why is this company on a period nobody paid for'. The actor is our own operator, and is named because an entry without one answers nothing. A company living on another machine of the fleet is not here: the answer then names the machine to ask.

Administrators only: every company on the installation — its plan, what state it is in (trial, active, over-limit, suspended…), when what it paid for runs out, how many days are left, what it is using against what it may use, and its balance. Ask with endingInDays to get only the ones running out that soon, which is how 'whose trial ends this week' is answered in one call. 'attention' is the console's own short list of rows somebody has to look at. A meter reading null means the machine holding that company was not asked, not that it is idle. Owners are left out unless withOwners is true, and an e-mail address is never returned.

Answer a question that was put to you on an issue, by choosing one of its options. Only the person the question was addressed to may answer it; answering again with a different option changes the answer and says so in the thread. A question whose deadline already passed can still be answered — that replaces whatever the deadline took, and the change is recorded. The answer is written into the thread as an ordinary comment and the asker is told.

Approve a wiki page IN YOUR OWN NAME, in the edition you read: 'version' is the page's version as get_wiki_page gave it, and the call is refused if the page has been edited since — read it again first. The approval is a line in the page's journal: who, when, which edition, and an optional note. It is never edited or deleted (withdraw_wiki_page_approval adds a line that takes it back). A later edit of the page does not remove it — the page then says that the edition in force is the approved one and the newer text is not approved. Only the project's lead (or the company's owner or an admin), or somebody named on the page with ask_wiki_page_approval. Approving is a person's statement: do it when your person told you to, not because a page looks finished.

Ask one person a question with pre-written answer options, in an issue's thread — the way to get a decision that does not get lost in the comment stream. The question appears as an ordinary comment (so every Jira-speaking reader sees it) and is tracked separately: the person you ask sees it counted in their Questions list until they answer. It does not wait for ever — give 'defaultOption' and the deadline takes it if nobody answers, so a blocked run can go on. Requires permission to comment in that project. NOTE: this is not the bgs 'ask_question' tool, which is the background-agent ledger — this one is a question to a person on a PM issue.

Name the people who may approve a wiki page, and tell each of them: they get a notification that opens the page. 'who' is usernames or e-mails as 'a,b' — each must be able to read the page. Somebody already named is asked again, about the edition the page is at now. With release: true the people in 'who' are taken OFF the list instead; what they already approved stays approved. The project's lead, the company's owner or an admin only.

Tick or untick one checklist item by the 'id' get_checklist gave it. Written as a click on the item is: the same history line and the same notices to the issue's watchers, in your name — and only the item's box changes, so an edit somebody is saving to the description at the same moment is never lost. Ticking a ticked item changes nothing ('changed' false). An id that finds nothing means the item was rewritten or removed: read the checklist again. Requires permission to edit the issue.

Who calls a class, method or function, or what it calls, to a depth of up to 3 — each use with its file and line. Uses linked only by the bare name are counted, not listed, because they are often a different symbol of the same name. When several symbols share the name, the answer lists them to choose from.

Where a class, method or function is declared in the code of the repositories connected to a project: its file, line and signature. Ask by name, or Class.Method to say whose. Only repositories whose owners opened them to agents are asked.

Connect one more GitHub or GitLab repository to a project, by its address — 'https://github.com/owner/repo', a gitlab.com project or a company's own GitLab. No token is taken here, ever: the host is asked as anybody would ask it, so a public repository connects at once and a private one is refused, with the screen to connect it on with a token. With openSource: true it is also marked as the project's open source repository — asked without a token whether anybody can read it and under which licence — which is what set_project_public needs; marking opens nothing by itself. A repository already connected is marked rather than connected twice. Only the project's lead, a board administrator or a company admin may; the mark is written to the company's journal.

Attach a secret — a password, a key, a test login — to an issue or a wiki page, instead of writing it in a comment or a description, where everyone on the project reads it for ever. Pass issueKey or pageId, and a 'name' saying what it is. It can be read by the person whose token this is, by the people in 'readers', and by the project's lead, who reads every secret in the project — and by nobody else, however much of the issue they can see. The answer lists them in 'readableBy': say that to the person rather than 'only you'. There are two ways to give the value. WITHOUT 'value' nothing is stored and the answer is a 'form' link: it opens the attach dialog with the name and the readers filled in, and the person types the value there themselves. Prefer that whenever the value is not already in the conversation — a value that passes through you stays in your context and in your client's logs. WITH 'value' the secret is stored now and the answer carries its id and name, never the value; it is recorded against the token you are using. Do not repeat the value in any text you write — a comment, a description, a merge request, a log. A name in 'readers' that is unknown or cannot open the project is not stored and comes back in 'dropped' with the reason. Needs the right to edit the issue or the page.

Create an issue in a project visible to this token. Returns the new issue key. Requires permission to create issues in that project. Answers with 'notified' (who this actually reaches: the people mentioned, and for an assignment the new assignee as 'assignee' and the one taken off as 'unassigned' in 'as' — never yourself) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Administrators only: create a project — a new key, a starter board, and its own wiki space, led by you unless you name someone else. The key is yours to choose and is never invented for you: one already taken is refused, naming the project holding it, rather than quietly becoming KEY2 — the key shows in every issue key, link and commit, and renaming it later costs more than creating the project did. Calling it again with the same key and name returns that same project with created:false, so a retry after a lost answer cannot make a second project. Deleting one is not offered here: that is a decision a person makes looking at what is inside. Who may: an administrator of this workspace, or — for a subproject — the lead of the parent, since it hands over their own project's people.

Add a rule to a project: when an issue enters 'status', append 'template' to its description. A rule appends its checklist to an issue's description when the issue ENTERS the rule's state — from the board, the Jira API or update_issue alike. The block starts with a hidden marker line '[//]: # (pm-rule:<id>)'; while that line is in the description, entering the state again adds nothing (the journal says 'alreadyThere'). A [~username] in the template is a mention: that person is notified when the checklist lands. A checklist that would make the description too long is not added and the journal says 'tooLong'; the move itself still happens. 'trigger' says WHEN: 'entered' (the default — the issue entered 'status'), 'versionReleased' (a version it goes out in was marked released), 'subtasksDone' (every issue under it is finished — the rule acts on the PARENT) or 'subtaskStarted' (an issue under it was taken into work — the parent again); or what the project's repository said through its webhook: 'branchCreated' (a branch naming the issue was made), 'mrOpened', 'mrMerged' or 'mrClosed' (a merge request — a pull request on GitHub — naming the issue was opened, merged, or closed without merging). An issue is named by its key in the branch, the title or the description, and only this project's issues are touched. 'branch' narrows the three merge-request events to a request going INTO that branch, e.g. 'main'. Nobody is behind a webhook, so such a rule acts as whoever last saved or switched it on, whatever its action. 'deployed' fires when a pipeline reports that the issue went out to an environment (report_deployment); 'environment' narrows it to one of the project's environments by name, e.g. 'staging'. 'actChanged' fires on the issues that cite a legal act when its publisher's text changed, and 'actTouched' only on those where the change is in the place they cite (or that cite the act as a whole) — found once a week, only in a project with the «Legal acts» add-on; nobody is behind a publisher either, so these act as the rule's owner too. Only 'entered' has a 'status'; pass an empty one for the others. 'fromStatus' narrows any of them to an issue coming from that state: the state it has just left for 'entered', the state it stands in for the rest. A rule with action 'move' MOVES the issue to 'moveToStatus' instead of appending anything, and has no template (pass an empty one). The move is an ordinary one — made as whoever last saved or switched on the rule, asked of the project's workflow, written to the history with the rule's name, and followed by the rules of the state it lands in. A workflow that refuses it leaves a 'moveRefused' line with the reason in the journal and nothing else; 'moved' is a move made; 'tooDeep' is a move not made because rules had already moved issues three times off one event. A rule with action 'agent' is a DUTY instead: it says which issues may be handed to an agent role (agentRole, e.g. 'product') and what the agent may do with them. Its 'template' is then the INSTRUCTION — what doing such an issue means in this project — and nothing is appended anywhere. A duty may have no state (pass an empty 'status'): then an issue is handed only by a person. agentActions is a list from: describe, subtasks, ask, wiki, report, support, jira (propose a move or a comment in the project's linked Jira, applied by a person). agentFields names the fields it may set: priority, labels, duedate, or the project's own fields by name. doneStatus is the state it moves the issue to when done — never a finished one. capUsd raises what one task may cost, up to 5 dollars. Commenting is always allowed; finishing, deleting, reassigning and anything outside the issue never are. Saving or switching on a duty makes it yours: it runs on your behalf and access, and is switched off if you lose the project. The state and the type are NAMES of this project's own (list_project_rules lists them); an unknown one is refused with the list. Project lead or admin only.

Add a version to a project, at the end of its sequence. A version is what a project's work goes out in — '2.4.0', 'Autumn'. It is the project's own: an issue carries versions of its own project only, any number of them ('fixVersions' on create_issue, update_issue and get_issue; JQL 'fixVersion = "2.4.0"', 'fixVersion in unreleasedVersions()'). The name is unique in its project, whatever the case. Answers with the version as list_versions gives it. Releasing it is release_version's. Project lead or admin only.

Put one scene of a wiki page on other sites (PM-1076): a link anybody can open with no account, which plays the block's scene in our player and shows nothing else of the page — not its title, its words, its space or its author, only the 'caption' you give. Answers with the link and the ready <iframe> to paste into a site. The block is named by 'language' (anim, or anim-js where the company has scenes written in code) and its 'block' number among that kind's blocks, as get_wiki_page's 'anims' numbers them; the embed follows the block, so an edit of the scene shows everywhere. 'sites' limits which sites may frame it (https://example.org each; none is any); 'days' gives it a term (none is until removed). Only for somebody who may edit the page; it is a line in the page's history. delete_wiki_embed takes it down everywhere at once.

Create a wiki page from Markdown in a space you can write to. Hangs off the space home page unless you name a parent (by 'parentId', or by 'parentTitle' within the same space). Returns the new page id and its URL. Mention someone as [@Their Name](user:username) — on a wiki page that is the form that notifies, not the [~username] used in issues; link another page as [text](page:Title) or [text](page:SPACE/Title). A ```anim block (a scene as JSON the reader's browser plays — product_help topic 'anim') is read at once: the answer's 'anims' says, per block, whether it plays or every problem with where it stands. Answers with 'notified' (who this actually reaches) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Approve or decline one request to take part in a public project (ids from list_join_requests). Approved, the person becomes a reporter there — files issues and comments; a broader role is given on the project's people screen, as for anybody on the board. Declined, they may ask again in 14 days. The person is told by email either way, and the decision is written to the company's journal. Only the project's owner and its administrators may decide.

Confirm or reject every PROPOSED person of one source at once — the persons the reading found on one page, issue or comment. 'source' as list_persons' 'sources' names it; 'expected' is how many proposed persons of it you were shown, and if the count has changed nothing is written. Ask the person first. Members of the project who may write only. Only where the company's plan includes AI.

Decide what a held or failed letter to the support address is. 'release' files it as if it had just arrived, past the spam filter and the limits: it joins the request it proves it answers, or opens a new one (and the sender gets the usual acknowledgement). 'dismiss' says it is not a request; its files are dropped and the row is deleted with the other unfiled letters after 30 days. Requires full write access to the support project.

Confirm or reject every PROPOSED term of one source at once — a wiki page or an issue the terms were found on — as the terms screen's «Confirm all on this page» does. Read them first with list_terms and that 'source', and pass 'expected': how many proposed terms you read there. If the count is different now (somebody decided some, or the page was read again), nothing is written and the answer says so — read the list again. Confirm only what the person asked for. Members of the project who may write only. Only where the company's plan includes AI.

What a word means IN THIS COMPANY'S PROJECTS — a code like 'PW06' or 'F24', a project's own name for something, a notion its pages define ('петля', 'размерная подгруппа'). Ask it before guessing at a word you do not know in an issue or a page: the answer is the project's own short definition, where it is defined (a wiki page or an issue, and the heading on it) and the other ways it is written, and 'links' — the terms its definition rests on ('way': 'out', kind 'dependsOn' or 'specialCaseOf'), the ones that rest on it ('in'), and its opposites ('oppositeOf') — so a notion is read after what it rests on; term_graph has the whole picture. Matches the term or any of its spellings, case aside, then terms that begin so. Only confirmed terms, and only those whose source you may open. Empty 'terms' means the projects do not define it — then it is an ordinary word, or ask a person. Only where the company's plan includes AI.

Remove one agent-usage record from an issue, by the id that get_agent_usage returns. For correcting a record's numbers, re-send it with report_agent_usage instead — the same source + externalId updates in place. Requires permission to edit the issue.

Remove a file from an issue, by 'filename' or by attachment 'id' — both come back from get_issue. Requires permission to edit issues in that project.

Remove a claim from a project's register for good, with what it rests on — it cannot be undone, so do it only when the person asked for this very one to be deleted; confirm its label with them first. Its journal keeps its lines and one that it was deleted. A claim that turned out false is not deleted: set_claim_status 'refuted' or 'retracted' keeps it said. Members of the project who may write only.

Remove one computation from an issue, by the id list_computations gives — for a job reported against the wrong issue. To correct one, report it again under its own name instead. Requires permission to edit the issue.

Remove a credential, by the id from list_credentials — the value, its reader list and the record of who read it go with it, and it cannot be brought back. Only the person who attached it and the project's lead may. To take one person's access away, use update_credential's 'readers' instead.

Remove a recurring issue from a project. The issues it already filed stay as they are. The project's lead, the company's owner or an admin only.

Remove a person from a project's register for good, with all their spellings and facts — it cannot be undone, so do it only when the person asked for this very one to be deleted; confirm the name with them first. The journal keeps a line that a person was deleted, without the name. To turn down a PROPOSED person use set_person with state 'rejected' instead, so they are not proposed again. Members of the project who may write only.

Remove a column from a project. Answers with how many issues lost a value, because that number is what the decision was about — the issues themselves are untouched. Project lead or admin only.

Remove an issue type of this project's own. Refused while any issue is of it or any field is kept for it — change those first; a rule on it goes with it. Project lead or admin only.

Remove a project rule, by its id from list_project_rules. Checklists it already added stay in their issues; its journal goes with it. To stop it for a while instead, update_project_rule with enabled=false. Project lead or admin only.

Remove a term from its project for good — it cannot be undone or restored, so do it only when the person asked for this very term to be deleted; confirm the name with them first. To turn down a PROPOSED term use set_term with state 'rejected' instead — a rejected term is remembered and not proposed again; a deleted one may be found and proposed anew. Members of the project who may write only.

Remove a file from a wiki page, by its 'filename' as listed by get_wiki_page. Identify the page by 'pageId', or by 'spaceKey' + 'title'. References to it in the page body are left alone — they simply stop resolving, so tidy the body too if it named the file. Requires permission to edit the page.

Take an embed of a wiki page's scene down (PM-1076): its link answers 404 at once on every site that has it. It cannot be undone — an embed made again of the same block gets a new link. Only for somebody who may edit the page; a line in its history.

Delete a wiki page. Identify it by 'id', or by 'spaceKey' + 'title'. A page with children takes its whole subtree with it, so that is refused unless you pass includeChildren: true — the answer names what would go. The space home page can never be deleted. Requires permission to edit the wiki.

Answer a hint of list_persons' 'similar' with «these are two different people» — «Mikhailov» and «Mikhaylov» who are not one — so the pair is not hinted again; or, with 'undo', take that answer back. ASK the person first, naming both as list_persons shows them; never decide it yourself from the names. A person merged into another answers as the one they were merged into. merge_persons on such a pair still merges, and the answer goes. Both journals keep a line. Members of the project who may write only. Only where the company's plan includes AI.

Evaluate Wolfram Language with the very engine a wiki page's ```wl cells are evaluated by (mathics-core-rust's wl-wasm), on the server and now — to check an expression before putting it on a page, or what a page's cells will say. Pass 'code' for one cell, or 'cells' for several evaluated in one session and in order, as the page's «Evaluate all» does (a definition in one is seen by the next). The whole call has 10 seconds: the cell running when they are out is 'timeout', one that runs out of memory or stack is 'limit', and the cells after either are 'skipped'. Answers each cell's outputs — results with their Out[n], messages and prints, each as text, InputForm ('input') and TeX ('tex', 'latex') — and the engine, its commit and the seconds it took. Cells this engine already evaluated for a page of the company are answered from that output ('saved': true). Nothing is kept. Only where the company has the wiki.wl switch; at most 10 evaluations a minute per person.

Which issues and wiki pages refer to a legal act — the list on the act's card. Per document the value names (the same act in two languages is two): 'total' issue-and-place and page-and-place lines, 'hidden' of them where you may not read (counted, never named), and 'items' — the 'place' cited with the 'issue' (key, summary) or the 'page' (id, title, spaceKey). Only accepted references in projects that keep them count; a comment's reference is its issue's. Name the act by its key (e.g. 32015L0849), its address, the document id, or words of its title. The same set of issues is JQL's legalRef = "…".

Find issues by what they are ABOUT, in plain words — by meaning as well as by words (where the server has its embedding model), so an issue that says the same thing differently or in another language is found, which search_issues (JQL) cannot do. The same search answers with `pages` (wiki pages) and `files` (PDF and Word files attached to an issue or a page, found by the words inside them): "everything on this counterparty" finds the contract and not only the issue that names it. Best first; `match` says what found each (words, meaning, or only near words — the weakest). `unread_files` lists the files this search could NOT read (a scan, a damaged or protected file, an old .doc): nothing found says nothing about those. Use search_issues for questions about fields (mine, overdue, in status X).

Who a name in this company's texts is — «Гупта», «N. D. Gupta», «Sjogren». Ask it BEFORE writing a person's name with initials or in another script: the answer is every person the spelling may be, each with all their spellings by script ('latin', 'cyrillic') and form ('full' — with initials or a first name, 'surname', 'inflected' — a declined form), each spelling with the source it was read from and the words there, and 'checked': 'checked' (the quote stands in its source), 'unchecked' (nobody gave a source — somebody remembered it) or 'stale' (the quote stood in its source and was edited out of it, or the source is gone: the spelling may still be right, its proof is not). Write the name as found — «Гупта (N. D. Gupta)» — and never complete initials from memory. 'ambiguous' is true when more than one person is written exactly so (two Guptas): then say which one you mean, or ask. Nothing found: add what you know with set_person, with the source and quote you read it in. Matches any spelling, case aside, then spellings that begin so. Only confirmed persons, and only spellings whose source you may open. Only where the company's plan includes AI.

What background-agent runs have cost an issue (local or mirrored/upstream): one record per run (tokens by kind, machine time, agent/model/host) plus the totals. A null metric means nobody reported it — which is not the same as zero, so 'reporting' says how many records carried each metric.

Read one file attached to an issue — its bytes, base64-encoded — by the issue key and the 'filename' as get_issue lists it. The bytes travel as text through the conversation and cost roughly a third more than the file itself, so there is a size ceiling; the pm-files MCP server saves a file to a path instead, without spending the conversation on it (local_files_setup says how to connect it). Reading needs only permission to see the issue.

The files one merge request, pull request or commit touches, with their diffs. Large diffs arrive cut.

Read an issue's checklist — the '- [ ]' lines of its description — as items, in order: each with a stable 'id' (pass it to check_checklist_item), 'checked', its words ('text', without reminder or picture), its 'depth' when nested, its 'reminder' ('YYYY-MM-DD HH:MM' or null) and its 'picture' — the attachment it shows of how the item should look, with the 'content' address its bytes are read at with this same token, or null — and its 'request' when the item asks somebody for a document (a 📎 in its line): 'state' (waiting, overdue past its 'due' day, sent with a file not yet ticked, done once ticked) and the 'files' sent to it, or null for an item that asks for nothing. Needs only permission to see the issue.

One claim of a project (see list_claims), with its journal: every change of its status — from what, to what, who and on what ground — newest first, and when it was created and edited. Name it by 'id', or by 'project' and 'label'. Anybody who sees the project.

Read the discussion on an issue, oldest first. Without 'startAt' you get the END of the thread — the most recent 'limit' comments — because catching up means reading the latest, not the first ever written; 'earlier' says how many stand before the page you got, and 'startAt' walks back through them. Each 'body' comes back exactly as written, which is also the text update_comment's 'edits' are matched against. A reply carries 'replyTo', the id of the comment it answers (null otherwise) — pass the same id to add_comment's 'replyTo' to answer one. Comments that were deleted are not listed. Needs only permission to see the issue.

Get one issue by key (e.g. 'UK-1') if it is visible to this token, including its description, status, assignee, labels, sub-tasks, the issues it is linked to and the wiki pages linked to it. 'comments' is a COUNT, not the text — read the thread itself with get_comments whenever it is not zero: decisions, the map of what is attached and how to run the thing are often written there rather than in the description.

Which Jira of its own a project is connected to: the site, the account whose token it uses (what a write there is signed as), whether a token is held ('secretSet' — the token itself never comes back) and whether the connection is switched on; and under 'confluence', whether the same site's Confluence is read too, whose account answered there, and whether it has a token of its own ('ownToken') rather than the Jira one. 'connected' false means none. 'canConfigure' says whether you may change it: connecting, or giving a new token, is done on the board's Jira sheet at 'url', since the token is a secret that is never typed in this chat; switching it on or off is set_jira_connection. Any member of the project may ask.

Which issue of the project's own Jira this issue is, and what that Jira says of it now — its summary, status, assignee and link — read with the token the project's administrator connected. 'connected' false means the project has no Jira; 'jira.state' is 'found', 'missing' (no such issue, or one the token cannot see), 'refused' (the token no longer opens the site), 'unreachable', 'off' or 'sealed'. Where the project keeps its statuses in step with that Jira (get_jira_sync), 'sync' says which way and, in 'problem', why the two were left apart: 'conflict' (both moved), 'no_pair_here' / 'no_pair_there' (a status with no pair), 'refused_here' (this project's workflow refused the move), 'no_move' (the site lists no move to the paired status), 'refused_there', 'missing', 'token'. Set the link with set_jira_link.

How a project keeps its issues' statuses in step with its own Jira (see get_jira_link): 'direction' — 'off', 'both', 'from_jira' (Jira moves, the issue here follows) or 'to_jira' (the issue here moves, Jira follows); 'pairs' — which status here is which there, in order; 'actsFor' — the person whose name a move made here carries, and 'ownerStands' false when they can no longer be acted for (the sync then waits until somebody saves it again); 'webhook' — whether the site's webhook is set up and when it was last heard (the address itself is only shown on the screen); 'statuses' here and 'jiraStatuses' there to pair; and the issues left with their statuses apart, with why ('conflict', 'no_pair_here', 'no_pair_there', 'refused_here', 'no_move', 'refused_there', 'missing', 'token'). For whoever administers the project.

A legal act that issues or wiki pages you can read refer to, as it is kept here: title, publisher, 'state' (fresh, stale, waiting — named and not read yet, or unreachable), 'asOf' — the day its text is as of, how many issues and pages refer to it ('references': total, and 'hidden' of them where you may not read), its articles with their offsets ('outline', on the first look) and a window of its text, at most 12000 characters. 'changedAt' is when its words were last found changed on the publisher's site, 'editions' the earlier texts kept (from, to — the days the site was asked, not the days the act was amended — and the headings each change was under), 'failing' a site that has stopped giving it. Pass 'find' («Article 18») to land on a place, or 'offset' to read on from 'nextOffset'. Reads no site: the text is the one already read. Name the act by the document id a reference gives, by its address, or by its key (e.g. 32015L0849); an act nothing you can read refers to is not found.

Read one page of the Confluence of a project's own Jira site — switched on beside the Jira (get_jira_connection's 'confluence') — on the project's token, as the agents read it: its title, space, the pages above it, its version and who changed it last, and its body as Markdown (cut at 12000 characters, which it says). A page there is 'confluence_page_id', with its 'confluence_url'; it is not a page of this tracker's wiki (get_wiki_page). What it says was written by people on that site. Name the project by 'project', or an issue here by 'issue'. For the people who work in the project; at most 10 reads of the linked site a minute per person, Jira and Confluence together. A refusal has a 'state': not_connected (with the 'url' of the screen that connects one), off, missing, refused, unreachable, busy, sealed, no_access, bad_request.

Read the comments of one issue of a project's own Jira (see get_linked_jira_issue), the newest first: who wrote each, when and what, and how many there are in all. Name the project by 'project', or an issue here by 'issue' — then its project's Jira is read, and the issue's own key there is the default. For the people who work in the project; at most 10 reads of the linked Jira a minute per person.

Read one issue of a project's own Jira — the one its administrator connected (get_jira_connection) — on the project's token, as the issue screen and the agents read it: summary, type, status, priority, assignee, reporter, dates, labels, versions, parent, sub-tasks, links there and the description (cut at 12000 characters, which it says). An issue there is 'jira_key', with its 'jira_url'; it is not an issue of this tracker (get_issue). What it says was written by people on that site. Name the project by 'project', or an issue here by 'issue' — then its project's Jira is read, and the issue's own key there is the default. For the people who work in the project; at most 10 reads of the linked Jira a minute per person. A refusal has a 'state': not_connected (with the 'url' of the screen that connects one), missing, refused, unreachable, busy, off, sealed, no_access, bad_request.

A project rule's journal, newest first: each time an issue entered the rule's state and matched its conditions — which issue, who moved it, and the outcome: 'applied' (checklist added), 'alreadyThere' (its marker line was already in the description, nothing added) or 'tooLong' (the description would have been too long, nothing added); for a duty, 'handed' (the issue went to its agent), 'busy' (an agent already had it), 'tooMany' (the duty's fifty a day were used up) or 'refused' with a 'reason' (agent_off, agent_budget, …), and 'ownerLost' when the duty was switched off because its owner lost the project. The place to look when a checklist did not appear or an agent did not take an issue. Any member may read it.

What this company and one of its projects could still set up in the tracker, and what is set up already — call it when the person has just started or asks what else the tracker can do. Each step has 'id', 'scope' ('company' or 'project'), 'done', 'why' (one sentence) and 'how': the next move, either an MCP 'tool' with example 'args' to call, or a 'url' of the screen to open when the step needs a token, a key or a browser — never ask for such a secret in the chat. Steps not yet done come first. Only steps the caller may take are listed: the ones that need the project's lead or the company's owner or an admin are counted in 'hidden', with a 'note' to ask them. Without 'project', the only project the caller can see is used; with several, 'projects' lists them and only the company's steps are answered.

Read one letter to the support address whole — the quoted thread and the signature that the request's comment leaves out, the HTML part as text, and the headers. 'letterId' comes from list_support_letters or from get_support_request's messages. A letter in a request is readable by whoever can read that issue; any other only by the support project's full members.

Read who is behind a support request: the requester's name and email, whether they asked signed in (and from which workspace), their client version, what the product knew when they asked from inside it ('context': the screen, the client, the last refusal the server gave them with its request id), and which comments of the issue the requester can see ('messages', by comment id and direction; 'autoRule' names the rule when the desk's automatic answer wrote it rather than a person, 'autoWording' says whether the model worded it or the template went). Every other comment on the issue is internal — the requester never sees it. Answers found=false for an issue that is not a support request.

Read one file attached to a wiki page — its bytes, base64-encoded — identifying the page by 'pageId' or by 'spaceKey' + 'title' and the file by 'filename' as get_wiki_page lists it. This is how a file is copied from one page to another: read it here, write it with add_wiki_attachment. The bytes travel as text through the conversation and cost roughly a third more than the file itself, so there is a size ceiling; for anything larger — or for putting the file on disk — the pm-files MCP server saves it to a path instead (local_files_setup says how to connect it). Reading needs only permission to see the page.

Get one wiki page by id, or by space key + title, if it is visible to this token. Returns the page text, its labels, its parent and child pages, its comments, and the issues linked to it. Pass withMarkdown: true when you intend to edit it — you then get the page's Markdown source to change and hand back to update_wiki_page, and each comment's own Markdown, version and anchor for update_wiki_comment. A large page is read a part at a time: 'outline' lists its headings and how big each section is, then 'section' returns one of them (or 'offset'/'limit' a run of lines), and update_wiki_page's 'edits' changes just the words you mean without sending the page back. A page with ```manim code blocks (where the company has scenes switched on) also returns 'scenes': each block's drawing state — queued, rendering, done or failed — manim's own error when it failed, and the attachment it was drawn into. A page with ```anim blocks (a scene as JSON the reader's client plays itself, no rendering) returns 'anims': for each, whether it can be shown, its length, or every problem with where it stands.

A wiki page's APPROVAL: which edition is in force. 'version' is the edition the page is at now and 'approved' whether that very edition is approved. 'inForce' is the newest edition somebody's approval stands on — its 'version', when it was written, when it was approved and 'by' whom (null: the page was never approved). When 'inForce.version' is lower than 'version' the page was EDITED AFTER it was approved: the text you read with get_wiki_page is not the approved one. 'approvers' are the people named on the page as those who may approve it (the project's lead always may), 'canApprove' / 'canAsk' what you may do, and 'journal' every line ever written, newest first — asked, released, approved, withdrawn; no line is ever changed or removed.

A wiki page as REQUIRED READING: whether somebody is asked to read it and mark so. 'edition' is the version to read — the approved edition in force where the page has one (see get_wiki_page_approval), else the one its lead last asked about; null when the page is asked of nobody. 'required' says whether it is asked of YOU and 'readAt' when you marked that edition (absent: not yet). 'readers' is the list as written: a person, 'members' (everybody on the project) or a team role. For the project's lead there is also 'people' — everybody the page is for today, each with 'askedAt', 'readAt' and 'remindedAt' for that edition, so who has NOT read it is whoever has no 'readAt' — and 'earlier', the marks on earlier editions. A mark is on an edition: a newer approved edition leaves the old marks in 'earlier' and asks everybody again.

Link two issues: link_issues('PM-419', 'PM-417', 'is blocked by') records that PM-419 is blocked by PM-417. 'type' is the PHRASE, said as a person says it — 'blocks', 'is blocked by', 'duplicates', 'is duplicated by', 'clones', 'relates to' — so the direction is in the words and the arguments cannot disagree; a bare type name ('Blocks') points outward, as it does in Jira. A phrase this workspace does not have is REFUSED and the ones it does have are named, rather than quietly becoming 'relates to'. The link then shows on both issues (get_issue returns 'links'), and linking the same pair the same way again changes nothing. Requires permission to edit BOTH issues — a link is a change to the issue at each end. 'to' may also be an issue of ANOTHER company's PUBLIC project, as 'company/KEY-12' (e.g. 'math/D5-12') or its address there: it is read as somebody with no account reads it, linked only while public, shown in get_issue's 'publicLinks' with a 'state' that says 'unavailable' once its project closes, and the other company is not told. That needs permission to edit 'from' only.

Say how one term of a project stands to another (PM-1053): 'from' rests on 'to' ('dependsOn', the default), is a special case of it ('specialCaseOf'), or is its opposite ('oppositeOf'). 'state' 'confirmed' (the default) keeps the link — shown to readers beside the term and used for the order of reading; 'rejected' turns down a link term_graph proposed, so the definition does not offer it again; 'none' takes a link away. Terms are named by id or spelling, as term_graph returns them; 'to' must be of the project or one above it. Members of the project who may write only.

Link a wiki page to an issue. The link then shows on both the issue and the page, and survives the page being renamed or moved. Identify the page by 'pageId', or by 'spaceKey' + 'title'. Linking the same page again updates that link instead of adding a second one. Requires permission to edit the issue.

A project's claims — its theorems, lemmas, propositions, corollaries, conjectures and questions — each with its label (what a paper's \label and a citation name it by, e.g. 'thm:d5-rank5'), its number in the paper, its statement (Markdown with formulas), how far it is proved and what it rests on. 'status' is on one fixed scale: 'open' (not proved), 'paper' (proved on paper), 'computer' (by a computation), 'lean' (formalised in Lean), 'refuted', 'retracted' (taken back — the † of a result). A basis is a wiki page with the proof ('page', its id and title — or 'hidden' where you may not open the page), a computation by the name a [comp:…] cites ('computation'), a Lean declaration ('lean') or a source in words ('source'). This register is where a claim's status is kept: read it here rather than from a page's words, and change it with set_claim_status. Ordered by number, then label. Anybody who sees the project.

List a directory of a repository connected to a project. Only repositories whose owners opened them to agents can be read.

The computations issues rest on, as their runners reported them: state, progress, the commit and repository, the job's page and output, and what came of it. With 'key', one issue's; with 'projectKey', the project's, newest first and the ones still going on top — state 'open' (queued or running) is what is going now, which is the first thing to ask after a lost session instead of reading status comments. 'state' may also be one of queued, running, done, failed, cancelled, lost.

List the credentials attached to an issue or a wiki page that this token may read — names and who attached them, never the values. Pass issueKey or pageId. Use reveal_credential to read one value, and only when you are about to use it.

A project's environments, in order, and its ten newest deployments. An environment is one of the places a project's work is put out to — 'dev', 'staging', 'prod' — in order; the LAST one is where finished work ends up. A deployment is a pipeline saying «this went out, there». Each issue it carried then says where it lies ('deployedTo' on get_issue), gets one history line per environment, and the project's rules with trigger 'deployed' run on it. Also 'canEdit' (you may change the list) and 'canReport' (you may report a deployment). Any member may read them.

Questions with answer options, in either direction: what is waiting on YOU to answer (role='to_me'), what YOU asked and are waiting on somebody for (role='asked'), or everything on one issue. This is how you find out whether the question you asked has been answered — poll it, since ask_issue_question does not wait. With no 'key' the default is role='to_me'; with a 'key' it is every question on that issue. Open ones by default; pass state='all' for the answered, withdrawn and expired ones too.

A project's RECURRING ISSUES: issues it files by itself on a calendar — a monthly report, a quarterly review, a licence renewed every year. Each has the issue as words (summary, description, type, assignee, priority, labels), the cadence ('every' N of 'unit': week or month — 3 months is a quarter, 12 a year), 'nextDay' it files on, 'dueInDays' (the filed issue's due day, counted from the day it is filed), whose it is (it files in that person's name) and, when the last day filed nothing, 'halted' ('owner_lost': its owner can no longer configure the project and it is switched off; 'refused': the filing was refused, 'lastError' says why). 'lastIssueKey' is the last one filed. Any member may read them.

The requests of people outside the company to take part in a public project: who asked, what they wrote, when — those waiting first, then the last twenty decided. Approved, a person files issues and comments in that project and nothing else; they take no seat and see nothing else of the company. Only the project's owner and its administrators see and decide them.

List the acts in the legal library — what this installation's agents have already read off the official sites: url, title, the day the text is as of (fetched_at), when the site last confirmed it (checked_at) and its length. Open where the company lets an agent role read laws.

The legal acts one issue or one wiki page refers to — in its own text and in the comments on it. Each reference: its 'id' (pass it to remove_legal_reference), where it stands ('in': issue, comment, page or wikiComment, with 'commentId'), the act ('document': id, url, sourceUrl, title, hasText, asOf — the day its text is as of), the 'place' cited («Article 18»), the 'quote' it was read from, 'foundBy' (url, pattern, model or hand) and 'state' — 'proposed' is the model's offer that nobody accepted yet, 'rejected' one somebody said no to. 'editionChangedAt' is set when the act's text was found changed since the reference was made and nobody has looked at it since ('editionReaches': whether the change is in the place cited, null when that cannot be told) — a person marks it looked at on the screen. 'enabled' false means the project does not keep legal references, and the list is empty. Needs only permission to see the issue or the page. In JQL and CQL the same is the field legalRef.

List the external MCP connections configured for a project. Auth tokens are never returned (only whether one is set).

A project's register of persons — the people its texts name — each with their spellings by script and form, each spelling's source and whether it is checked (see find_person), facts (born, died, wikidata, mathGenealogy, orcid, mrAuthor) the same way, and the project's note on why they are here. 'state' is 'confirmed', 'proposed' (found in the texts, waiting for a person — set_person with state decides it) or 'rejected'; proposed and rejected ones only to members who may write. 'reading' says whether the project has its texts read for persons. 'q' narrows to persons with a spelling holding those words. To a member who may write, 'similar' pairs two persons that look like one, with the two spellings and why — 'form' (the same up to the form of the words, «Гупта» / «Гупты»), 'letter' (one letter apart in a long Latin name, «Sjogren» / «Sjorgren»), 'transliteration' («Сьёгрен» / «Sjogren») or 'initials' («N. D. Gupta» / «Narayan D. Gupta») — a hint for the person to decide, never a fact: merge_persons only when they agree, distinct_persons when they say the two are different people — 'distinct' lists those answers. 'merged' lists the persons merged into one, whose spellings and facts are shown among its own with 'mergedFrom'. Only spellings whose source you may open; a person none of whose spellings you may see is not listed. Only where the company's plan includes AI.

The columns a project keeps about its issues: name, kind, and a list's options with their colours. Also the customfield_… name each one answers to, for searching by JQL. Any member may read them.

The ready-made projects a project can take in one action — today 'requirements', a register of what a company is obliged to do: an issue type, ten columns (the norm, the obligation, who answers, what proves it, when it is reviewed), a four-state workflow, the year's recurring compliance work and two wiki page templates. Says what each brings, by name, before anything is taken.

A project's rules: when an issue enters a state, a checklist from a template is appended to its description. A rule appends its checklist to an issue's description when the issue ENTERS the rule's state — from the board, the Jira API or update_issue alike. The block starts with a hidden marker line '[//]: # (pm-rule:<id>)'; while that line is in the description, entering the state again adds nothing (the journal says 'alreadyThere'). A [~username] in the template is a mention: that person is notified when the checklist lands. A checklist that would make the description too long is not added and the journal says 'tooLong'; the move itself still happens. 'trigger' says WHEN: 'entered' (the default — the issue entered 'status'), 'versionReleased' (a version it goes out in was marked released), 'subtasksDone' (every issue under it is finished — the rule acts on the PARENT) or 'subtaskStarted' (an issue under it was taken into work — the parent again); or what the project's repository said through its webhook: 'branchCreated' (a branch naming the issue was made), 'mrOpened', 'mrMerged' or 'mrClosed' (a merge request — a pull request on GitHub — naming the issue was opened, merged, or closed without merging). An issue is named by its key in the branch, the title or the description, and only this project's issues are touched. 'branch' narrows the three merge-request events to a request going INTO that branch, e.g. 'main'. Nobody is behind a webhook, so such a rule acts as whoever last saved or switched it on, whatever its action. 'deployed' fires when a pipeline reports that the issue went out to an environment (report_deployment); 'environment' narrows it to one of the project's environments by name, e.g. 'staging'. 'actChanged' fires on the issues that cite a legal act when its publisher's text changed, and 'actTouched' only on those where the change is in the place they cite (or that cite the act as a whole) — found once a week, only in a project with the «Legal acts» add-on; nobody is behind a publisher either, so these act as the rule's owner too. Only 'entered' has a 'status'; pass an empty one for the others. 'fromStatus' narrows any of them to an issue coming from that state: the state it has just left for 'entered', the state it stands in for the rest. A rule with action 'move' MOVES the issue to 'moveToStatus' instead of appending anything, and has no template (pass an empty one). The move is an ordinary one — made as whoever last saved or switched on the rule, asked of the project's workflow, written to the history with the rule's name, and followed by the rules of the state it lands in. A workflow that refuses it leaves a 'moveRefused' line with the reason in the journal and nothing else; 'moved' is a move made; 'tooDeep' is a move not made because rules had already moved issues three times off one event. A rule with action 'agent' is a DUTY instead: it says which issues may be handed to an agent role (agentRole, e.g. 'product') and what the agent may do with them. Its 'template' is then the INSTRUCTION — what doing such an issue means in this project — and nothing is appended anywhere. A duty may have no state (pass an empty 'status'): then an issue is handed only by a person. agentActions is a list from: describe, subtasks, ask, wiki, report, support, jira (propose a move or a comment in the project's linked Jira, applied by a person). agentFields names the fields it may set: priority, labels, duedate, or the project's own fields by name. doneStatus is the state it moves the issue to when done — never a finished one. capUsd raises what one task may cost, up to 5 dollars. Commenting is always allowed; finishing, deleting, reassigning and anything outside the issue never are. Saving or switching on a duty makes it yours: it runs on your behalf and access, and is switched off if you lose the project. Answers with each rule's id (the other rule tools take it), action, trigger, state, conditions (type, label, fromStatus, branch — null means any), template, moveToStatus and whether it is on, and for a duty its 'agent' part; with the state and type names, the triggers and the actions a rule may use, the agent roles, actions and fields a duty may name where agents are on; and 'canEdit'. Any member may read them.

List the projects visible to this token (a project-scoped token sees only its project). A project with a 'parent' is a subproject of that one: it has its own issues, board and wiki, and shares only who may reach it.

The GitHub and GitLab repositories a project is connected to: each one's id, host, path and address, whether it is the project's open source repository (with the licence its host named and when that was last confirmed), whether a token is set (never the token), whether agents may read its code, and whether a webhook is set. Also whether the project itself is open source and public, whether you may change the list, and the screen where a token is given. Any member may read it.

List letters to the support address that did not become part of a request: 'held' (looked like spam, or too many at once from one address or on one request), 'failed' (we could not file them), 'ignored' (an autoresponder, a bounce, a mailing list, our own letter), 'dismissed'. Without 'state', held and failed — the ones waiting for a person. Each has an id, the reason, the sender, the subject and the file names. Only a full member of the support project may read them: they are strangers' words.

The support desk's queue: open requests, the most urgent first — overdue, then due soonest, then those waiting on their requester. Each item says whose turn it is ('clock.turn': 'first' = nobody has answered yet, 'reply' = the requester wrote again, 'requester' = we answered last and the clock is stopped), since when it has waited, the working hours waited, when the answer is due and whether it is 'onTime', 'dueSoon' or 'overdue'; plus the assignee. 'numbers' has the current counts and, over the last 30 days, the median time to a first human answer and to resolution (in working hours — weekdays only) and the share answered within the promise. An automatic acknowledgement or automatic answer is never counted as an answer; 'numbers.auto' says how many requests the automatic answer got, how many were then resolved with no human reply and no further word from the requester ('settled'), and how many requesters wrote again after it ('askedAgain') — per rule too. An item's 'autoRule' is set when the request got an automatic answer. Readable by anybody who can read the support project.

A project's terms: each word, its other spellings, its short definition, its kind, and its source (a wiki page or an issue, with the heading on it). 'state' is 'confirmed' (shown to readers, marked in texts), 'proposed' (found on a page by its markup or by the model, waiting for a person — set_term with state 'confirmed' or 'rejected' decides it) or 'rejected' (kept so it is not offered again). Proposed and rejected ones are listed only to members who may write. Only terms whose source you may open. 'uses' is how many times the project's pages and issues use the term by any spelling (null: not counted yet); the most used come first, a page at a time — 'total' says how many there are. To a member who may write, 'similar' pairs a term of this page with another that looks like it up to the form of its words (plural, case) — merge_terms joins them if the person agrees. Only where the company's plan includes AI.

The tracks a project is cut into: a track is a LABEL the project declared meaningful — a play, a campaign, a rollout — and work joins one by carrying that label. A track has no key of its own; its issues keep the project's key, which is what makes it a different thing from a subproject (a separate project, see create_project's parentKey). Any member may read them.

List the people you can assign work to or mention: the members of the projects this token can see. Optionally filter by free text (username, display name or email) or narrow to one project. Mention someone in a description or comment as [~username] — a mention matches the username, never the display name — and pass the same username (or the email) as 'assignee'.

A project's versions, in their sequence. A version is what a project's work goes out in — '2.4.0', 'Autumn'. It is the project's own: an issue carries versions of its own project only, any number of them ('fixVersions' on create_issue, update_issue and get_issue; JQL 'fixVersion = "2.4.0"', 'fixVersion in unreleasedVersions()'). Each with its id, name, description, startDate and releaseDate (YYYY-MM-DD), whether it is released or archived (put away: still on its issues, no longer offered), 'overdue' (its day has passed and it has not shipped), and how many issues it carries — 'issues' — and how many of those are not finished — 'open'. Also 'canEdit': whether you may make, change and release versions here. Any member may read them.

The scenes of a wiki page — or of every page of a space you may edit — put on other sites (PM-1076): for each, its id, the block ('language' anim or anim-js and its number among that kind's blocks, as get_wiki_page's 'anims' numbers them), the link and the ready <iframe> code, the caption, the sites allowed to frame it (empty is any), the term ('expiresAt', null until removed), who made it and when, and how many times it was opened. Only for somebody who may edit the page; give 'id' for one page or 'spaceKey' for the space.

The labels of one wiki space with how many pages carry each, most used first — counted over the pages visible to this token. `service` marks a label that does a job rather than describe a page ('template'). search_wiki with `label` lists a label's pages.

List the wiki spaces visible to this token. Every project has exactly one space, keyed like the project.

How the person connects pm-files — a small local MCP server that attaches files from their own computer to issues and wiki pages by path, and saves attachments back to files, so no bytes pass through the conversation. Call it when you need a local file (a screenshot, a document, anything past the base64 ceiling) and pm-files is not among your tools: hand the person the command for their client, with this workspace's address already in it. It never contains a token, and you must never ask for one — the command takes it from the person's clipboard. Changes nothing.

Mark a wiki page as READ, IN YOUR OWN NAME: «I have read this edition». 'version' is the edition you read and must be the one get_wiki_page_reading gives as 'edition' — the call is refused when the edition to read is another one. Only for somebody the page is required reading for. The mark is a line in the page's journal — who, when, which edition — and is never changed or removed. It is a person's statement: make it when your person told you they have read the page, not because you fetched its text.

Merge one person of a project's register into another when they are one human being — «Sjorgren» into «Sjogren». ASK the person first, naming both as list_persons shows them: 'similar' there is only a hint. Nothing is removed: the one merged keeps their spellings and facts with their sources, and from then on find_person, list_persons and the marks answer the other for any of their spellings. unmerge_person undoes it. Into a person already merged is into the one they were merged into; a rejected person is not merged into. Both journals keep a line. Members of the project who may write only. Only where the company's plan includes AI.

Join one term to another of the same project when they are one notion — «Размерные подгруппы» into «Размерная подгруппа». The joined term's name and spellings become the target's variants (so the reading does not offer that spelling again), its links move to the target, and the joined term is gone; this cannot be undone. The target keeps its definition, kind, source and place — with 'takeDefinition', the joined term's definition replaces it, together with the source and place it was read from. The result is confirmed if either was; two proposed terms stay proposed. 'similar' in list_terms names terms that look alike up to the form of their words. Members of the project who may write only. Only where the company's plan includes AI.

Move an issue into another project, taking its comments, history, attachments, links and sub-tasks with it. The key does NOT change: 'PM-12' stays 'PM-12' wherever it lives, so every existing link and branch name goes on working. Call it with apply=false first (the default): the answer says what the move would cost — values in columns the target project does not have are LOST, the sprint is cleared, and a secret attached to the issue becomes readable by the target project's lead. Refuses when the target has no state by the issue's status name; say what that state becomes with 'statuses'. A sub-task cannot move on its own — move its parent. Needs full write access in BOTH projects.

How the TRACKER ITSELF works — not what is in anybody's project: what a feature does, where it is on the screen, who may use it, and what the product does not do. Use it when the person asks about the tool ('how do sprints work here', 'where do I switch on due reminders', 'can a wiki page be restricted') rather than about their work. Without 'topic' it lists the topics, each with the questions it answers; with one it returns that topic's text. Buttons and menu items are quoted in «…» in the person's interface language — repeat them as given. 'availability' is set when the feature is switched off for this company: say that first. The text is the whole of what the help says; what it does not say, say it does not cover — do not fill it in from other trackers, and do not answer a question about the product from the project's wiki.

Read one file from a repository connected to a project. A long file arrives cut and says so; generated and binary files are not read.

Mark a version released — or, with released=false, take the mark back. A version is what a project's work goes out in — '2.4.0', 'Autumn'. It is the project's own: an issue carries versions of its own project only, any number of them ('fixVersions' on create_issue, update_issue and get_issue; JQL 'fixVersion = "2.4.0"', 'fixVersion in unreleasedVersions()'). Releasing runs the project's rules that wait for a version to ship (list_project_rules, trigger 'versionReleased') on the issues it carries, and tells the project's webhooks. It does NOT refuse a version that still carries unfinished issues: 'open' in the answer says how many, and 'openIssues' names up to twenty of them — check before you release, or say so to the person. With no 'releaseDate', today is written as the day it shipped — over a planned day, as the releases screen does. Releasing a version that is already released changes nothing and answers 'already': true. Project lead or admin only.

Take a legal reference off an issue or a wiki page, by the 'id' list_legal_references gave it — as «Remove» in the block «Legal acts» does. A reference read from words that still stand in the text is kept as a «no» ('keptAsRefused' true, its state 'rejected'), so the next save does not put it back; one put by hand with no words of its own is deleted. Requires permission to edit the text it stands in.

Undeclare a track. THE LABEL STAYS ON THE WORK: what goes is the declaration, so the issues keep their tag and declaring the track again brings exactly the same ones back. Nothing here can lose work — but the name, icon and place ARE lost, and the track's issues count as 'outside every track' afterwards. For a track that is merely finished, archive it instead: set_track with archived=true. Needs permission to write in the project.

Write to the person who opened a support request. The text becomes a comment the requester can read on their page and is emailed to them — unlike add_comment, which is always internal and never reaches the requester. Write it to the customer, in their language (get_support_request says which). Requires full write access to the support project. Answers with the comment id and whether the letter went ('emailed'; 'emailError' when it failed — the reply is kept either way).

Record what one agent run cost an issue (local or mirrored/upstream): tokens by kind and machine time. Re-sending the same 'source' + 'externalId' updates that record instead of adding a second one, so a retry never doubles the spend. Omit a metric you did not measure — omitted is 'not reported', which is different from zero. Requires permission to edit the issue.

Say how a computation an issue rests on stands — a GAP run, a batch of work units, a Lean build that ran somewhere else; the tracker runs nothing. Call it when the job is submitted, as it progresses and when it ends, with the same 'source' + 'externalId' every time: that is one job, updated, never a second. Send only what you know now — a field left out keeps what an earlier report said, so a progress report need not repeat the commit. 'state' is queued, running, done, failed, cancelled or lost (a job whose runner stopped answering); 'starting' reads as running. Report the commit it ran at and the repository's web address: that is what makes a [computer] result checkable, and the answer's 'commitUrl' links it where the host is GitHub or GitLab. 'result' is what came of it, in a sentence — Markdown and $…$ formulas work. Answers with 'created' and 'stateBefore'. A name already reported on another issue is refused with that issue's key. Requires permission to edit the issue.

Say that something was deployed to one of a project's environments — the call a pipeline step makes. An environment is one of the places a project's work is put out to — 'dev', 'staging', 'prod' — in order; the LAST one is where finished work ends up. A deployment is a pipeline saying «this went out, there». Each issue it carried then says where it lies ('deployedTo' on get_issue), gets one history line per environment, and the project's rules with trigger 'deployed' run on it. Name the issues it carried in 'issues', or give 'from' and 'to' — two revisions — and the keys are read off the messages of the commits between them in the project's connected repository (a merge commit names its branch and merge request). Both may be given. The same 'id' for the same environment again changes nothing and answers 'repeated': true, so a step that runs twice is safe. 'version' also puts each of those issues in that version of the project. Answers with the issues it found, 'unknown' (keys you named that are no issue of this project), how many times a rule ran, and — on the project's last environment — 'unfinished': the issues that went out while not in a finished state. Needs permission to change issues in the project.

Read one credential's value, by the id from list_credentials. This is the same act as pressing reveal on the screen and carries the same cost: it is recorded against the token you are using, and the person who owns the secret can see that you read it. Call it when you are about to use the value, not to have it on hand. The answer is marked secret: do not copy it into a comment, a description, a merge request or a log.

Find where a string appears in the code of the repositories connected to a project, with the file, the line number and the lines around it. Only repositories whose owners opened them to agents are searched, and the answer says when what it searched was out of date.

Search the issues visible to this token, with a JQL query — the same JQL the Jira REST surface takes, read by the same parser. A query naming a field this tracker does not have is REFUSED and named, never run: it would match everything and read as an answer. Without `jql`, the shorthand arguments filter instead. Most recently created first unless the query says ORDER BY. Archived issues are left out unless the query names `archived`, and `archivedLeftOut` says how many matches that hid — an empty list with it is not "there are none".

Search the laws, regulations and standards this installation's agents have already read off the official sites (EUR-Lex, legislation.gov.uk, Fedlex, FATF and others) — by words and by meaning. Not a web search. Each hit: the act's url, title, the day its text is as of, an offset into the text and a snippet around the match. Open where the company lets an agent role read laws.

Search the Confluence of a project's own Jira site (see get_linked_confluence_page) with CQL, as its own search does — e.g. 'type = page AND text ~ "onboarding" ORDER BY lastmodified DESC', 'space = ENG AND title ~ "release"', 'parent = 123456'. Answers each page's confluence_page_id, confluence_url, title, space, an excerpt and when it changed; read one whole with get_linked_confluence_page. A query the site cannot read comes back with its reason. This tracker's own wiki is searched with search_wiki. Name the project by 'project', or an issue here by 'issue'. For the people who work in the project; at most 10 reads of the linked site a minute per person.

Search a project's own Jira (see get_linked_jira_issue) with JQL, as its own search does — e.g. 'project = ACME AND status != Done ORDER BY updated DESC', 'text ~ "login"'; currentUser() is the project token's owner, not you. Answers each issue's jira_key, jira_url, summary, type, status, priority, assignee and when it changed; read one whole with get_linked_jira_issue. A query the site cannot read comes back with its reason. This is the other site's JQL; this tracker's own issues are searched with search_issues. Name the project by 'project', or an issue here by 'issue'. For the people who work in the project; at most 10 reads of the linked Jira a minute per person.

Search wiki pages visible to this token by free text: by words in any form and by meaning (where the server has its embedding model), and literally — the title, the body, the labels written on an attached SVG diagram. Best match first; `match` says what found each page. `files` are PDF and Word files attached to pages, found by the words inside them. Optionally restrict to one space key. Without `text`, the pages most recently updated first.

Add a claim to a project's register, or change one — its kind, label, number in the paper, title, statement or bases. A claim is named by 'id', or by 'project' and 'label': one that does not exist yet is created (with 'statement'; 'status' says how far it is proved from the start, 'open' if left out, and 'reason' on what ground). An existing claim's status is NOT changed here — use set_claim_status, so the journal says why. A field left out keeps its value; 'bases' given replaces the whole list. Write the statement in Markdown with $…$ formulas. The label is the paper's \label: a letter, then letters, digits and ':', '.', '_', '-' — once per project, case aside; 'newLabel' renames it. Members of the project who may write only.

Move a claim on the scale — open, paper, computer, lean, refuted, retracted — with the ground it moved on in 'reason' (a merge, a computation that finished, a reviewer's word, the issue it was decided in). The journal keeps the line: who, when, from what to what and why; this is the one place a status changes, so the paper and the site that read it agree. Name the claim by 'id', or by 'project' and 'label'. The same status again changes nothing. Members of the project who may write only.

Make a project's environments exactly this list, in this order — the last is where finished work ends up. An environment is one of the places a project's work is put out to — 'dev', 'staging', 'prod' — in order; the LAST one is where finished work ends up. A deployment is a pipeline saying «this went out, there». Each issue it carried then says where it lies ('deployedTo' on get_issue), gets one history line per environment, and the project's rules with trigger 'deployed' run on it. A name the project already has is kept as it is, with what was deployed there; a name it does not have is added; and an environment LEFT OUT is removed together with the record of what was deployed to it and any rule waiting for it. So to rename one, add the new name and tell the person — there is no rename here. Project lead or admin only.

Fill in a project's own columns on one issue, by their NAMES: 'Segment=AI; Country=Poland; Started=2026-08-01', or a JSON object. A country column takes the country's name or its two-letter code. A link column takes issue keys and wiki pages (a page's address or page:471), comma-separated, and REPLACES the records you can see with them — records you cannot open stay. An empty value clears the field, which is not the same as an empty one. A value that does not fit the field's kind — an option nobody offered, a date that is not one, a country that is neither — refuses the WHOLE call rather than writing part of it.

Add a recurring issue to a project, or change the one named by 'id' — the WHOLE of it as you write it here: what you leave out of a change is cleared, not kept. From 'nextDay' on, every 'every' weeks or months, the project files this issue at nine in the morning on YOUR clock and in YOUR name: with your access, through the same rules, notifications and watchers as an issue you filed yourself. In 'summary', {date}, {month}, {quarter} and {year} are read off the day it is filed ('VAT return {quarter}' → 'VAT return Q4 2026'). If the one filed before is still open, the new one is filed all the same and linked to it. A day missed — a paused project — files once when it can, never a backlog. Refused, with the reason, if the issue could not be filed as described today (an unknown type, an assignee nobody has). The project's lead, the company's owner or an admin only.

Switch a project's Jira connection on or off, keeping its token — and, with 'confluence', whether the same site's Confluence is read too. Off, nothing reads that Jira or writes to it — the issue screen, the agents, the status sync — and issues keep their keys there. Switched on, the held token is asked of the site first and refused with the site's reason if it no longer opens it. Connecting a Jira, or giving a new token — Confluence's own included — is done on the board's Jira sheet (get_jira_connection's 'url'), never here. For whoever administers the project.

Say which issue of the project's own Jira this issue is: its key (ACME-123) or its link on the site. The key is asked of that Jira first — one it does not have, or the token cannot see, is refused. An empty 'jiraKey' removes the link. One Jira issue per issue; the change is a line in the issue's history. Needs a Jira connected to the project and permission to edit the issue.

Set how a project keeps its statuses in step with its own Jira: the direction and the pairs of statuses. Either left out keeps what is there. Moves on either side go through that side's own workflow and are never forced: a move one refuses is left undone and said on the issue (get_jira_link's 'sync'). A move made here because Jira moved is made in YOUR name from now on — whoever saves this is whom it acts for — and Jira's history names the project token's owner. Switching it on moves nothing by itself: the next change on either side does. Both sides moved before the two were compared: neither is moved, and the issue says so. The site's webhook (quicker than the five-minute poll) is set up on the screen, since its address is a secret. For whoever administers the project; needs the connection switched on, with its token.

Add a person to a project's register, or change the one named by 'id': add spellings and facts, remove them, change the name shown or the note, and confirm or reject a proposed person with 'state'. A spelling or fact given with 'source' (the page, issue or comment you READ it in: 'page:471', 'PM-12', 'comment:88', 'wikicomment:7' or an address) and 'quote' (the source's own words that hold it) is checked now, and refused if the quote is not there or does not hold it. One without a source or quote is written UNCHECKED and the answer's 'unchecked' lists it — so write a name from memory only when the person asked for it, and never invent initials. A spelling the person already has is written over with the source you give. What you leave out stays. A person written here is confirmed at once. Members of the project who may write only. Only where the company's plan includes AI.

Add a column to a project, or edit the one that already has this name. Keyed by name rather than by id: 'make sure there is a Segment field with these options' is the request, and a name is what you just read. A field's KIND cannot be changed once it exists. Project lead or admin only.

Add an issue type of this project's own — e.g. 'Показ' — or rename one it already has. Keyed by name. The shared types (Epic, Story, Task, Bug, Sub-task, Client) are every project's and cannot be renamed here. Another project never sees this type. Project lead or admin only.

Make an existing project a subproject of another, or take it back out with an empty parentKey. This is about ACCESS, not about names or issues: everyone who may reach the parent may reach the subproject too, in the role they hold there. Nothing is renamed, no issue moves, and the keys stay ordinary keys. Attaching needs an admin or somebody who leads BOTH projects, since neither can be volunteered by whoever leads the other; detaching needs a lead of either, since it only takes access away. One level: a subproject cannot have subprojects.

Open a project to be READ by anybody — nobody signed in, or somebody who does not work in the company — or close it again. Opened, its board, issues, comments, attached files and wiki can be linked to from anywhere; nobody outside can write in it, people's email addresses are never shown, and the company's other projects and the project's own subprojects stay closed (a subproject has its own switch). Closing takes effect at once. Only an open source project may be opened — one created or configured with a public repository (create_project's openSourceRepo, connect_repository with openSource, or the project's repositories screen) — and it is closed by itself if that repository stops being public. Only the project's lead (or its parent's, or an admin) may do either, and both are written to the company's journal. Confirm with the person before opening: everything already in the project becomes public.

Mark a repository already connected to a project as the project's open source repository, or take the mark off. Marking asks its host, without a token, whether anybody can read it and under which licence, and is refused for a private one. Taking the mark off the last marked repository of a public project closes the project to readers outside at once, as the screen does — confirm with the person first. Only the project's lead, a board administrator or a company admin may; both are written to the company's journal.

Add a term to a project, or change the one named by 'id' — and confirm or reject a proposed one with 'state'. On a change, what you leave out stays as it is. A term written here is confirmed at once. 'variants' REPLACES the other spellings: send all of them — for a word that declines, the forms running text uses ('размерной подгруппы', 'размерных подгрупп'), since a text is matched by these and not by a stemmer. 'source' is the wiki page or issue that defines it — 'page:471', 'PM-12' or its address — and must be one you can open; an empty string removes it. Members of the project who may write only. Only where the company's plan includes AI.

Declare a track on a project, or edit the one that already has this tag. The tag is the LABEL issues carry to join it ('cherry-orchard'), so it cannot contain a space — labels are stored space-separated. The name is what a reader sees ('The Cherry Orchard'); leave it out and the tag speaks for itself. Declaring a track writes nothing to any issue: the ones already carrying the label are in it at once. Needs permission to write in the project.

Say whom a wiki page is REQUIRED READING for, and tell them. The three arguments together are the WHOLE list and replace the one before — read it with get_wiki_page_reading first and pass back what should stay. 'users' is usernames or e-mails as 'a,b' (each must be able to read the page); 'members: true' is everybody on the page's project, whoever they are on the day; 'teamRoles' is the project's team roles by name as 'a,b'. Everybody on the list who has not been told about the edition to read gets a notification that opens the page, and one reminder two working days later if they have not marked it. An empty list switches it off; marks already made are kept. With 'askAgain: true' the list is left as it is and everybody who has NOT read the edition is told once more — and on a page with no approved edition, the edition to read becomes the one the page is at now. The project's lead, the company's owner or an admin only.

How a project's website was visited, from the service that counts it: Google Search Console (clicks, impressions, ctr, position by query, page, country, device or date), Vercel Web Analytics (visitors and page views by page, referrer, source, country, device or date) or Google Analytics 4 (sessions, active users, page views, engaged sessions and key events by source, channel, landing page, country, device or date). Only connections opened to agents are read. The totals are the site's — rows of a breakdown do not add up to them — and the answer's period and notes say what was actually counted.

Give a project a ready-made setup (see list_project_presets) — only what it does not already have: a column, a type, a recurring issue or a page of the same name is left as it is, so taking it twice adds nothing. The workflow is taken only by a project with no issues whose states are still the ones a new project starts with; otherwise 'workflow' answers 'issues' or 'own' and the project's own workflow stays (the workflow screen offers the same one, and asks where each state's work goes). The recurring issues come SWITCHED OFF, each with the day it would first be filed on: read them with list_issue_schedules and switch on the ones meant with set_issue_schedule. It also switches legal references on for the project and, where the project told nobody of due days ahead, sets that to 14, 7 and 1 days. With 'samples', five sample requirements and three sample pages about an invented company are filed as you, all labelled 'sample' so they are found and removed together. Words are in 'language' — 'en' or 'ru'. The project's lead, the company's owner or an admin only.

What a project's terms rest on (PM-1053): its confirmed terms and its parent projects', the links between them, and 'order' — the terms in the order to read them, each after what it rests on, the ones resting on nothing first — with 'circles', terms whose definitions rest on each other (worth putting right). A link is 'dependsOn' (the definition rests on the other term), 'specialCaseOf' or 'oppositeOf'; its 'state' is 'confirmed' or, to a member who may write, 'proposed' — offered because the definition names the other term, waiting for a person (link_terms decides it). The order rests on confirmed links only. With 'term', only what stands within 'depth' links of it — the way to look at a large dictionary. Only terms whose source you may open. Only where the company's plan includes AI.

Remove a link between two issues: name both ends (and, when more than one link joins them, the phrase — 'blocks', 'relates to'), or give the 'linkId' get_issue returned. Ambiguity is refused rather than guessed: two issues joined twice and no phrase given comes back with the links listed. Requires permission to edit BOTH issues. The issues themselves are untouched.

Remove the link between an issue and a wiki page. Identify the page by 'pageId', or by 'spaceKey' + 'title'. Requires permission to edit the issue. The page itself is not touched.

Undo merge_persons: the person merged is a person of their own again, with every spelling and fact they had. Name them by their own id — 'merged' in list_persons lists them under the person they were merged into. Ask the person first. Both journals keep a line. Members of the project who may write only. Only where the company's plan includes AI.

Edit a comment on an issue: pass 'body' to replace the whole of it, or 'edits' to change part of it — exact find-and-replace against the comment as get_comments hands it back, each 'oldText' occurring exactly once. One body axis per call. With 'edits' the answer says where each one landed rather than giving the comment back, so correcting one number in a long comment costs neither a resend nor a re-read. Nothing here takes a version and none is needed: an 'oldText' is matched against the comment as it stands now, so an edit whose text somebody has since rewritten is refused rather than applied over their words. The author may edit their own comment; anyone with full write access in the project may edit any. Answers with 'notified' — and note that this is only the people the *edit* newly reaches: names already present in the old text are not notified again, and the comment is not re-announced to watchers.

Change a credential, by the id from list_credentials: its name, its value, or who may read it — each on its own, and only what you pass is touched, so taking somebody off the list never needs the value. 'readers' REPLACES the list; noReaders: true empties it. Only the person who attached it and the project's lead may change one: being shown a secret is not being given it to pass on. The answer never carries the value. Do not repeat the value in any text you write — a comment, a description, a merge request, a log.

Update an issue: any of summary, description, type, assignee, priority, labels, dueDate, parentKey, fixVersions, or status (which performs the transition, and fires the project's rules — a rule may append a checklist to the description, in which case 'description' is listed in 'changed'). Only the fields you pass are changed. A project's workflow may put conditions on a move — that only certain people may make it, or that it must set certain fields — and a refusal names the condition and, where it is about who you are, lists the states you CAN reach. Fields a move requires must be sent in this same call, with 'resolution' and 'fields': a value set by an earlier call does not satisfy the condition. Answers with 'notified' (who this actually reaches: the people mentioned, and for an assignment the new assignee as 'assignee' and the one taken off as 'unassigned' in 'as' — never yourself) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Change a project rule, by its id from list_project_rules. Only what you pass changes: pass just 'enabled' to switch a rule on or off, or any of the others to edit it. An empty string for 'type' or 'label' removes that condition; an empty 'fromStatus' or 'branch' removes that one too; for a duty, an empty 'status', 'agentActions', 'agentFields' or 'doneStatus' clears that one. A rule's action cannot change. A rule appends its checklist to an issue's description when the issue ENTERS the rule's state — from the board, the Jira API or update_issue alike. The block starts with a hidden marker line '[//]: # (pm-rule:<id>)'; while that line is in the description, entering the state again adds nothing (the journal says 'alreadyThere'). A [~username] in the template is a mention: that person is notified when the checklist lands. A checklist that would make the description too long is not added and the journal says 'tooLong'; the move itself still happens. 'trigger' says WHEN: 'entered' (the default — the issue entered 'status'), 'versionReleased' (a version it goes out in was marked released), 'subtasksDone' (every issue under it is finished — the rule acts on the PARENT) or 'subtaskStarted' (an issue under it was taken into work — the parent again); or what the project's repository said through its webhook: 'branchCreated' (a branch naming the issue was made), 'mrOpened', 'mrMerged' or 'mrClosed' (a merge request — a pull request on GitHub — naming the issue was opened, merged, or closed without merging). An issue is named by its key in the branch, the title or the description, and only this project's issues are touched. 'branch' narrows the three merge-request events to a request going INTO that branch, e.g. 'main'. Nobody is behind a webhook, so such a rule acts as whoever last saved or switched it on, whatever its action. 'deployed' fires when a pipeline reports that the issue went out to an environment (report_deployment); 'environment' narrows it to one of the project's environments by name, e.g. 'staging'. 'actChanged' fires on the issues that cite a legal act when its publisher's text changed, and 'actTouched' only on those where the change is in the place they cite (or that cite the act as a whole) — found once a week, only in a project with the «Legal acts» add-on; nobody is behind a publisher either, so these act as the rule's owner too. Only 'entered' has a 'status'; pass an empty one for the others. 'fromStatus' narrows any of them to an issue coming from that state: the state it has just left for 'entered', the state it stands in for the rest. A rule with action 'move' MOVES the issue to 'moveToStatus' instead of appending anything, and has no template (pass an empty one). The move is an ordinary one — made as whoever last saved or switched on the rule, asked of the project's workflow, written to the history with the rule's name, and followed by the rules of the state it lands in. A workflow that refuses it leaves a 'moveRefused' line with the reason in the journal and nothing else; 'moved' is a move made; 'tooDeep' is a move not made because rules had already moved issues three times off one event. A rule with action 'agent' is a DUTY instead: it says which issues may be handed to an agent role (agentRole, e.g. 'product') and what the agent may do with them. Its 'template' is then the INSTRUCTION — what doing such an issue means in this project — and nothing is appended anywhere. A duty may have no state (pass an empty 'status'): then an issue is handed only by a person. agentActions is a list from: describe, subtasks, ask, wiki, report, support, jira (propose a move or a comment in the project's linked Jira, applied by a person). agentFields names the fields it may set: priority, labels, duedate, or the project's own fields by name. doneStatus is the state it moves the issue to when done — never a finished one. capUsd raises what one task may cost, up to 5 dollars. Commenting is always allowed; finishing, deleting, reassigning and anything outside the issue never are. Saving or switching on a duty makes it yours: it runs on your behalf and access, and is switched off if you lose the project. Project lead or admin only.

Change a version: its name, description, days, or whether it is archived. Only what you pass is changed. A version is what a project's work goes out in — '2.4.0', 'Autumn'. It is the project's own: an issue carries versions of its own project only, any number of them ('fixVersions' on create_issue, update_issue and get_issue; JQL 'fixVersion = "2.4.0"', 'fixVersion in unreleasedVersions()'). An issue that carries the version goes on carrying it under a new name. Archiving puts it away — still on its issues, no longer offered for new ones — and is undone the same way. Releasing is release_version's, not this tool's. Answers with the version as list_versions gives it. Project lead or admin only.

Edit a comment on a wiki page — your own, or anyone's with full write access in that project. Read it first with get_wiki_page(withMarkdown: true), which gives each comment its 'markdown' and 'version'. Pass 'markdown' to replace the whole comment, or 'edits' to change part of it (exact find-and-replace on that Markdown, each 'oldText' occurring exactly once) — the answer then says where each landed, not the comment. An inline comment's anchor moves with 'inlineSelection': the page text it should point at, copied exactly; an empty string turns it into an ordinary footer comment, which is the only way it ever stops being anchored. Mention someone as [@Their Name](user:username), the wiki's own form. Answers with 'notified' — only the people the *edit* newly reaches, since names already in the old text are not notified again and the page is not re-announced to its watchers.

Change an embed of a wiki page's scene (PM-1076) — its caption, the sites that may frame it, its term — keeping its link, so the sites that have it keep working. Only what you pass changes: an empty caption takes it off, an empty 'sites' allows any site, days 0 removes the term. Only for somebody who may edit the page; a line in its history.

Edit a wiki page: retitle it, change its body, move it under another parent (or to the top of its space), or set its labels. Identify it by 'id', or by 'spaceKey' + 'title'. To change part of the body, pass 'edits' (exact find-and-replace on the Markdown source, each 'oldText' occurring exactly once) or 'replaceSection' — the answer says where each landed, not the page, so a one-line fix to a long page costs one line. 'markdown' replaces the whole body — read it first with get_wiki_page(withMarkdown: true) and edit that, or the page's links, images and macros are dropped; 'appendMarkdown' adds to the end and leaves what is there untouched. Mention someone as [@Their Name](user:username), the wiki's own form. Requires permission to edit the page. A page with ```anim blocks answers 'anims': per block, whether it plays or every problem with where it stands. Answers with 'notified' (who this actually reaches) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.

Admin only: create or update a project's external MCP connection. Pass 'id' to update an existing one (omit to create). 'token' is stored server-side and never returned; omit it to keep the current token when updating. The assistant panel calls the server's read-only tools (readOnlyHint) directly and turns every other non-destructive tool into a card the person applies; 'forAgents' also gives the project's agents its read-only tools.

Take back a question you asked, when it no longer needs answering — you worked it out, or the task moved on. The comment stays in the thread (the conversation happened) and the question stops counting on the other person's list. The person who asked, or anybody with full write access in the project.

Take an approval of a wiki page back: your own, or — the project's lead — somebody else's ('who'). Without 'version' it is the newest edition that person's approval stands on. Nothing is deleted: a 'withdrawn' line is added to the page's journal after the approval it answers, with your note. If nobody else's approval stands on that edition, an older approved edition is in force again, or none.