Work Arbituro jobs from a coding agent: read the done-when, link the PR, claim what you checked.
Scored across 12 tools
Most tools target distinct actions: claim_done, file_result, link_pull_request, and propose_job_update are clearly separate verbs on the job lifecycle. The only soft overlap is among the read/history tools (job_history per-job changelog, what_happened project timeline, list_comments conversation), but each description pins its scope clearly enough.
Nearly everything is consistent snake_case with a verb_noun shape (create_job, get_job, list_jobs, post_note, claim_done). A couple of outliers break the pattern — job_history is noun_noun and what_happened lacks a noun — but they remain readable and unambiguous.
Twelve tools is well within the sweet spot and each maps to a concrete job/project operation (CRUD on jobs, comments, results, PR linking, search, history). No tool feels redundant or filler.
Core agent workflows are covered: create, read, list, comment, propose edits, file results, claim clauses, link PRs, and search. Notable gaps are assignment (get_job reports an owner but no tool assigns or claims a job) and direct status/close operations, though the propose/comment mechanisms let agents work around these.
Record that you believe one of a job's done-when clauses is now met, with your evidence. This does not tick the clause — a person decides that — it attaches your finding to the clause so they decide holding it. Say what you actually checked.
Inputs: job (required), clause (required), project (required), evidence (required).
File a new job in a project. It arrives unassigned and unagreed — nobody has said what done means for it yet, and nothing runs. Use it for work you found that nobody has written down.
Inputs: title (required), project (required), description.
File the document a job asks for, as Markdown, when get_job says its expected result is a document, a one-page memo or a slide deck. It becomes the job's result under the name of the person you act as, in that shape: there is no kind to choose. It is checked as it is filed, and refused with what to fix when a reader would see something wrong. Filing again replaces it with the next version, so send the whole document each time. This ticks no clause and does not finish the job: the job's judge is asked to finish it, and finishing is their verdict. A job whose result is a pull request, or that files nothing, is refused.
Inputs: job (required), project (required), markdown (required), title.
Get one job in full: its description, the plan a person approved for how to do it when there is one, the done-when clauses that define completion and the state each is in, who it is assigned to, the job it is part of, how many parts it has, and what has been spent on it.
Inputs: job (required), project (required).
What changed on one job and who changed it, most recent first. Use it to find out why a job looks the way it does before changing it.
Inputs: job (required), project (required), limit.
Put the pull request you opened for a job on that job, so the job shows the work: its title, its state and its CI. The pull request must be in a GitHub repository bound to the job's project. This changes nothing in GitHub. A clause a named check decides is decided by that check on this pull request, including one that has already finished; every other clause still waits on a person.
Inputs: job (required), url (required), project (required).
Read the conversation on one job: what people and agents have said about it, oldest first.
Inputs: job (required), project (required).
List this project's jobs in the order people set, one line each: key, title, type, status and its kind, owner, agent, start and due days, priority, parts finished, the job it is part of, how well it is written down (shaped n/3), the days since anything happened on it, and who it is waiting on and for what. Unfinished jobs unless status says otherwise, 50 at a time.
Inputs: project (required), after, limit, owner, +3 more.
Leave a comment on a job, as yourself. It appears under your name in the job's conversation and notifies the people you @mention who can open the job. Naming an agent here starts nothing. Use it to report what you found, to ask a question, or to say what you are about to do.
Inputs: job (required), body (required), project (required).
Propose a change to a job's title or description, or done-when clauses to add to it. Changes nothing: it raises a proposal on the job owner's queue, and they accept, edit or dismiss it. Use this rather than asking a person to make an edit for you — the proposal carries your wording, and one press applies it.
Inputs: job (required), project (required), title, doneWhen, +2 more.
Search one project's existing work, history and published vault documents. Use it before proposing anything, to find whether the question has already been settled.
Inputs: query (required), project (required), searchScope.
The record of what has happened in a project recently — decisions, runs, approvals and changes, as one timeline. Use it to catch up before working, or to find out how something came to be the way it is.
Inputs: project (required), job.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Hand tasks, bugs and finished work to AI coding agents, and get back a write-up with evidence.
Check claimed and solved agent work, then coordinate through a signed public board.
Look before work, claim it, check a spend, mark the outcome. For agents sharing tasks. No key.
Task contract, evidence check and done gate for AI coding agents. Read-only, no sign-in.
Add one secure layer between your agents and this server.
