The tools

What a call does to a report's stamp. Nothing, by having been made: the server keeps no per-session history of tool calls. Each stored row of a report carries three facts the server observed as it wrote the row — waited, with a reference, through the brief. Two tools bear on them through what they leave behind: manage_work_reference, when a reference stands at the moment a report is stored, and get_assessment_brief, through the handle a report can send back. This says nothing about whether a tool writes or retains data; read each description for its actual effects.

Find a method

list_recipes

List the recipes available in your organization: the ones labbel serves and the ones authored here — slug, title, status and step count, and nothing of what any of them contains. This is how you find a recipe slug.

get_recipe

Read a recipe and its step overview: your organization's recipes, including drafts, and labbel's built-ins. The answer says the recipe's form — a run in one step or a run in steps — and its profile. Every run in steps includes labbel's current delivery guidance for the agreement on saving and reporting, resuming and the return; the profile decides which guidance.

get_step

Read one step at a time as work progresses. labbel records which version it hands you and when it first did, not how often. For a run in steps, read get_recipe first for the recipe, its form and the delivery guidance. With a run open on your account you are handed the version it was opened on, and a step added since is refused.

get_eval_criteria

Evaluation criteria: structural checks and rubrics. Name domain or profile; with neither, an overview. domain is what a recipe declares — built-in, or your organization's own: its latest stamped edition or the one version names, never a draft. profile: learning is the learning profile's. level: meta is what a recipe is held to, level: object what work from one is held to. Under profile, object is labbel's example edition: copy it in your words, add origin: labbel/examples/scaling-a-service, file it with submit_domain.

get_recipe_template

The recipe guide — how to write one, the main document's YAML frontmatter and markdown body. Name domain or profile: code-review (the guide reviewers work from), your organization's own domain, or domain-authoring — not a domain but the guide to creating one; profile: learning for the learning profile's. With neither, an overview. Always the meta level. Any other word is answered with a document naming the words there are.

Do the work and hand it in

submit_step

Hand in the work a recipe asks for, done. In a domain your own organization authored, a run in one step: you send the work itself, it is never stored, the server checks only that something was handed in, and the run is minted with an empty conformance list. criteria_version is the version word you read: with another edition in force the submit is refused with both words; without it the run is minted against the edition in force, which the receipt names. A run in steps is refused here unread: its steps are written with submit_recipe and document_kind: step, and what a person does with them is saved with save_progress. On the code review recipe the work is a review of a change: the domain's structural checks run as conformance, every one a block, and a review that holds them all mints the trace — the review itself is never stored. Every receipt carries the run reference to keep beside the original, and says when the follow-up falls due on a run that keeps a window; list_due_runs lists the runs past theirs.

save_progress

Save step progress in labbel, linked to this account's run of the recipe. Explain that it also reveals session patterns and completion; obtain explicit conversational approval or use a visible approval covering it. not_started writes nothing; the first in_progress or completed save opens the run under the edition in force, freezes its follow-up days on it, binds it to the recipe's steps as they stand and asks that every declared step is written. A finished run cannot be overwritten; open_run: true starts another only after completion. Never put personal data about an individual participant in context_note — only working state, no names, contact details or verbatim conversation content. A run in one step — code-review, or your own domain in one step — stores nothing here; its record is the trace from submit_step.

get_progress

Get the participant's progress across the steps: status (not_started, in_progress, completed) and context notes per step, with one section per run, oldest first. Kept for a run in steps. On a recipe whose run is one step — code-review, or your organization's own domain in one step — there is no progress to read and the answer says so: the record there is the trace submit_step mints.

submit_recipe

Submit a recipe's main document or, with document_kind: step and recipe_slug, one step document of a run in steps (YAML frontmatter + markdown body). Every structural finding comes back, but only severity block refuses the save. A main document's slug is derived from its title, so a resubmit under a title with the same slug replaces that recipe. The form follows the domain's edition: a run in one step carries exactly one step, minted from the main document; a run in steps declares steps, and each step is written here, one document a call. In a recipe in steps a changed step makes a new version. A step's slug is its position and title (1-the-review); get_recipe lists them. domain names a domain your own organization authored and a person on your bench stamped; labbel's own words take no recipe of yours, and a drafted, unsigned word is refused with what it awaits.

validate_recipe

Validate a recipe and all of its steps. Returns every structural finding with a severity — block, should_fix or note. Use this after submitting every step. A code-review recipe is also told the checks the server runs on a review. A recipe in a domain your own organization authored is read by the form its edition declares: a run in one step by that form's three rules, a run in steps whole — the form's rows for the recipe and each step, and the learning profile's rows where the edition declares that profile. It says which checks did not run: your own criteria are named here, never applied.

Report what happened later, and read it back

report_signals

Report a recipe run's observations. Types: For a recipe in the code-review domain: review_issued, change_outcome, finding_outcome, criterion_status (observations); finding_accuracy, review_usefulness (judgements); review_reflection (your reflection on the recipe). For a recipe in a domain your own organization authored: criterion_status, review_reflection. Under the learning profile a run in steps also takes checkpoint_result, calibration per step; at the return, criterion_status against its edition's criteria and scenarios. Under the learning profile: explain what goes to labbel and why; get explicit conversational approval, or a visible one covering these reports. Records link to this account's run; they are not anonymous. Respect refusal; the run can continue. No names, contact details, verbatim conversation content or identifying author/codebase details. Reflections: e-mails, URLs, phones and @-handles are removed before storage and removals reported; fields cap at 2000 characters. Names are not detectable; keep them out.

get_trace

Read back the traces of a recipe's steps: what the server stamped when the work arrived — the criteria it checked and whether each held, the gate (observed or reported), tier, versions and declarations. What report_signals adds is folded in, per domain and form: code review's change and finding outcomes, counted per review; your own domain's criterion statuses, counted per run, in one step or in steps as its edition puts the work. A review's outcome hangs on the review it was reported against rather than on the step. run reads one: the Nth run of this recipe — counted across your organization for a run in one step, by this account for a run in steps. In one step, as on its run reference: what the mint froze, whether its follow-up fell due, the decisions behind its versions; in steps: what it froze, each report's three facts, statuses counted, units.

get_insights

Your organization's own signal picture, counted live — each aggregate with its n and the stamps behind it. What an n counts follows from the recipe's domain and the form of its runs: distinct reviews in code review; in your own domain, distinct runs, in one step or in steps as its edition puts the work, with the reported rows beside it. The aggregates follow from the domain too: in the code-review domain, review_issued, change_outcome, finding_outcome, criterion_status, finding_accuracy, review_usefulness. Session pattern and completion are read by the server rather than counted.

get_assessment_brief

The brief for an independent report on one run: its criteria, when it is due and what remains — and none of the steps' documents, so reading it does not make you the one who delivered them. Where the brief hands out a handle, a report that sends it back as brief_handle carries through the brief on its rows about that run. run selects the subject, the Nth run of this recipe — counted across your organization for a run in one step, by this account for a run in steps (without it, in steps the earliest whose return is still owed, else the one that stands). A finished run's brief reads its sealed material and names what is missing. On a code-review recipe without run the brief lists the reviews on record by ordinal, date, age and outcome horizons, with the outcome question — never the verdict or the findings. In your own domain it carries the criteria the subject was frozen to, by number, and its wait — never earlier reports.

list_due_runs

Which of your organization's runs in one step — and of this connection's own finished runs in steps — have follow-up work remaining past a window: reviews on code-review and runs in your own domain, addressed by run, with the units their contract keeps: step, or criterion for a run in your own domain in steps. Another participant's runs in steps are never listed. A partly answered subject stays until its whole scope is handled; a unit waited on leaves until its retry_at. show asks for waiting or handled work instead. Figures count the page, never a total. It carries units, never answers: nothing reported, no outcome, no reason, no person or identifier. cursor is the line the previous page ended on, copied, even after an empty page. Organization and participant come from this connection and cannot be sent. Nothing is stored: asking puts no fact on any report. labbel reminds nobody: this is the question you ask us, never a message we send.

manage_follow_up

Say what happened to the work on one follow-up unit, never what it was worth: defer (waiting, with a reason and a next check within 30 days), unverifiable (tried, nothing verifiable), resume (opening it again). A result goes through report_signals; this is not a report and puts no fact on one. run names the subject as on get_trace, the Nth run of this recipe — counted across your organization for a run in one step, by this account for a run in steps; the unit is days or criterion in one step, criterion in steps. expected_revision is the revision your last reading gave: a stale one is refused with the one that stands, and one idempotency_key answers for one decision.

manage_work_reference

Say where the work of one run is, never what it was worth. add a git or a record reference as subject, result or deployment; remove one by its reference, or all. run names it as on get_trace, the Nth run of this recipe — counted across your organization for a run in one step, by this account for a run in steps; an owner or admin speaks for a run in one step, only its participant for a run in steps. Held apart from the outcomes and removable without them, the work itself never stored, credentials and access-granting links refused, nothing sent repeated back. 10 live and 100 ever per subject; idempotency_key makes an add safe to repeat. A reference standing when a report is stored puts with a reference on its rows.

Author your own domain

validate_domain

Run a domain draft against the deterministic gate. Read the guide first: get_recipe_template with domain: "domain-authoring". It returns every structural finding and its severity, the work's form and profile among them. The body is read by headings — rubric, scenario (in steps), horizon or outcome, structural checks — as domain_markdown says; criteria are numbered in the rubric's order, the numbers a step's serves names. follow_up_days counts from a moment the service observes itself — a run in one step handed in, a run in steps finished — never an external event. It reads your organization's editions for one thing: a draft whose form or profile is not the pair the edition in force declares is refused. Nothing you send is stored.

submit_domain

File a domain draft, after validate_domain, and open the bench case for it. Send the whole draft, your own reading of the material, and one verdict per real case you ran the draft against. What it stores is an edition, numbered by the server and frozen: a revision is a new edition under the same title, never an edit, and the domain's word is the slug of that title. An edition is the object level, level: object: the criteria work from a recipe is held to. This door takes it, not the meta level, the guide to writing recipes in the domain. Your reading and your verdicts are attached as your declarations, kept apart from the server's own record. Who is submitting comes from the connection. It does not stamp: a person at your bench puts their name to the edition, or does not.

Your account and organization

get_my_profile

Returns your user profile — id, name, email, role, organization — and the ledger of the exchange so far: runs held here, reports that came back, and which side is ahead, a line per domain. Call this first to confirm your identity and permissions.

list_members

List the people in your organization: for each one the e-mail address, the name, the role, the status, the tier and when the row was created — owners first, then admins, then members, oldest first inside each role, with your own row marked. No arguments: the organization is this connection's. It changes nothing.

invite_member

Invite someone into your organization by e-mail address. member_role is the role the invited person gets (admin or member); owner is not offered. Your own organization, identity and role come from this connection and cannot be sent. The answer never carries an invitation link, a password or a token. Safe to call again: an address already a user here comes back as a success that changed nothing, and one held elsewhere in labbel is refused without saying where.

set_member_role

Promote a member of your organization to admin, or put an admin back to member. member_role is the role that person gets from now on (admin or member); owner is not offered. Your own organization, identity and role come from this connection and cannot be sent. An owner may act on an admin or a member, an admin on a member only, nobody on an owner and nobody on themselves. An address that is not a member of your own organization is answered as if there were nobody there at all.

set_member_status

Suspend or reactivate a member. Set member_status to suspended or active; your identity, role and organization come from the connection. Suspension stops MCP tools and bench access on the next call. It revokes no credentials: setting active again lets them back in with the credential they already had. An owner may act on an admin or a member, an admin on a member only, nobody on an owner and nobody on themselves. An address that is not a member of your own organization is answered as if there were nobody there at all.

remove_member

Remove a member of your organization for good: the account in Supabase Auth is deleted and then the user row, in that order, so a half-finished removal can always be finished by calling again. Their own rows go with them and the places they were only referenced keep the work and lose the name. An owner may remove an admin or a member, an admin a member only, nobody an owner and nobody themselves. Safe to call again. Not reversible.

The orientation the service itself gives on connection:

What this service is

labbel keeps methods for recurring work, and the record of how they turned out. A method lives here as a recipe: what the work should achieve, its constraints and how anyone would know afterwards, with room to decide how to carry it out. No model runs here; the thinking is yours.

A domain is one kind of recurring work, with its own criteria and its own clock for when the truth arrives. One comes built in, code review, where labbel serves a recipe. Your organization can author its own, held to criteria a person at its bench stamped; for work in steps, the learning profile's guide is get_recipe_template with profile: "learning". Each tool below says what it does in which domain.

list_recipes shows what is here, and what is yours.

A run goes in one of two forms:

• In one step — get_recipe → get_step → the work → submit_step, which hands it in.
• In steps, delivered to one person over time — get_recipe → get_step → the work with the person → save_progress after each step. The run belongs to that person's own account.

Then, in both forms, the return: after the wait the domain declares, list_due_runs shows what is due, get_assessment_brief gives the criteria to answer, and report_signals sends the answers.

What is kept is the trace of that run: what happened, your declarations beside the server's own stamps. The conversation is never stored.

The criteria the work is held to are readable before you write anything, through get_eval_criteria. They explain themselves rather than gate, and reading them is also how you decide whether this is work you want to take on.