Skip to main content
Sixty-five tools. You do not need to learn them — the editor lists them and the model picks. What is worth knowing is the shape of the day they were written for.

​
The day

1

See what there is

my_work or find_cards, then read_card for the whole of one.
2

Before cutting a branch

branch_for_card. It answers with the name the team’s convention gives — and a branch named anything else is invisible to the board, so it never reaches the card it was for.
3

After pushing

read_inbox, then adopt_branch to link it.
4

Moving the card

move_card is what runs Git. Depending on where the card lands it cuts a branch, opens a pull request, or merges one.
Nothing here reads a file or runs a command. Tylon holds the work — cards, the flow, the branches each one owns, the releases they ship in. The code is on your machine, and reading and editing it is your editor’s job.

​
The two you cannot get locally

read_checks and read_reviews. The build ran on the forge and the reviews were left there, so no amount of looking at your working copy will answer either. The public API has both too, as JSON rather than sentences — see Checks and reviews.

​
By group

my_work find_cards read_card read_timeline branch_for_card read_checks read_reviews create_card update_card move_card comment link_repository open_pull_request remember read_diff edit_comment delete_comment unlink_repository delete_card
read_board read_flow read_backlog list_projects create_project update_project delete_project list_labels create_label update_label delete_label list_features create_feature update_feature delete_feature set_flow
list_releases read_trunk create_release set_release_cards freeze_release unfreeze_release promote_release cherry_pick complete_release delete_release
list_members invite_member change_member_role list_repositories list_connectable_repositories add_repository connect_git_url list_credentials
list_agents list_proposals approve_proposal reject_proposal list_runs
list_docs read_doc write_doc delete_doc
read_inbox adopt_branch dismiss_inbox_item

​
What a refusal looks like

A “no” comes back as a sentence at the tool’s normal result, not as a protocol error — “this needs the maintainer role”, “the PR opens on the first push”. That is deliberate: a model reads sentences, and an error where an answer should be is a client rendering nothing. It is also the difference from the public API, where a refusal is a status code because the reader is a program.

​
Two rules the tools enforce

Scope. A connection approved for workspace:read is told so when a write is attempted, rather than failing halfway. Role, live. Checked per board on every call, against your membership as it is right now — not as it was when you connected.