verifAIed

Am I done? The stop condition for a coding loop. **Free — no subscription, no token budget, no rate limit.** Composes what verifAIed already knows about a branch — failing tests plus the coverage of the functions you changed — into a single verdict you can gate on: - ``done`` (bool): ``true`` only when there are no gaps at all. This is the strict signal to stop. - ``status``: ``"done"`` | ``"done-with-warnings"`` | ``"not-done"``. ``done-with-warnings`` means the only remaining gaps are ones the repo owner marked non-blocking — read this yourself if you want to stop early. - ``scope``: ``"changed-functions"`` when a default-branch base exists (only added/modified functions are judged), else ``"all-functions"``. - ``gaps``: each remaining problem with a ``ref``, the id to act on (``function_id``/``test_id``), and a ``next_action`` pointing at ``get_baseline_prompt`` (free) or ``fix_branch`` (paid). Gap kinds: - ``failing_test`` — a test that failed or errored. - ``untested_function`` / ``partial_function`` — a changed function with no coverage, or only some. - ``unexercised_browser`` — a changed function that no browser reached, in either the browser-coverage or the manual dimension. Only judged once one of them exists. - ``visually_unreviewed`` — a changed component nobody has looked at. ``intent_mismatch`` — somebody looked and it didn't do what the change claimed. Both only judged once the branch has at least one ``verify_ui`` verdict. - ``unverified_recorded_test`` — a recorded test this branch has never run, or whose last run failed. Re-run it with ``verifaied test run "<feature path>/<name>"`` — the feature path is optional and may nest. Branch-wide, not diff-scoped. Absent entirely for a repo with no recorded tests. - ``visual_defect`` — something ``verifaied audit`` measured in the rendered page (overflow, contrast, a broken image, a console error), from the most recent audit of the branch. **The one kind that is a warning by default**, so it routes to ``done-with-warnings`` rather than blocking unless the repo owner turned it on. Only judged once the branch has been audited at least once. Gaps are ordered so a component's own gaps are immediately followed by its handlers' and render branches'; a sub-unit gap carries ``parent_ref`` (the parent's ``file::Name``) so you can group or indent them without parsing refs. The clustering is presentation only — every gap is still individually actionable by its own ``ref`` / ``function_id``. - ``not_checked``: signals that couldn't be evaluated (e.g. failing tests when no junit.xml was uploaded, or ``unexercised_browser`` when functions exist but no browser coverage was uploaded) — surfaced so a green verdict is never silently green. Pagination: ``gaps`` is capped at ``max_gaps`` per call (default 50) to stay within tool-result limits — a low-coverage branch can have hundreds. ``done``, ``status``, ``scope`` and ``gaps_total`` ALWAYS reflect the full gap set, never just the returned page, so a truncated page is never mistaken for a clean branch. When more gaps remain, ``has_more`` is ``true``, ``next_offset`` is the offset to pass next, and ``note`` spells out how to fetch the rest — call again with that ``offset`` until ``has_more`` is ``false``. The intended loop: run your tests with coverage (pytest → coverage.json, or ``vitest run --coverage --coverage.provider=istanbul`` → coverage/coverage-final.json) → ``upload_local_coverage`` → ``check_done`` → fix each gap (``get_baseline_prompt`` / ``fix_branch``) → re-upload → repeat until ``done`` is ``true``. ``repository`` is the GitHub 'owner/repo' (a repo UUID also works); ``branch`` defaults to the repository's default branch. Errors with an actionable message when no analysis exists for the branch yet — upload coverage first.

Reset the accumulated **manual-recording** dimension for a branch. Manual uploads are **additive**: each ``upload_local_coverage`` with ``coverage_kind="manual"`` unions that hand-driven session into the branch's manual dimension, so you can build a pass up one flow at a time. Call this to wipe that accumulation and start over — every function goes back to Unexercised. The branch's ``manual_languages`` are kept, so the Manual Recording view stays visible; only the per-function coverage is cleared. This does **not** touch browser coverage (``coverage_kind="browser"``), which has no clear at all: every producer there replaces its own contribution on its next run, so nothing accumulates to be reset. ``repository`` is the GitHub 'owner/repo' (a repo UUID also works); ``branch`` defaults to the repository's default branch. Errors when the branch has no local analysis to clear. Returns ``cleared_functions`` — the number of function rows reset.

The verifAIed documentation, for you and for the user's questions. **Free.** Call this whenever the user asks how something in verifAIed works or how to do something with it, and whenever you are unsure what a tool, a command, a gap or an error means. Three ways to call it: - no arguments: the table of contents — every page with a one-line summary — and how to use the rest. - ``query``: the question, or a few words of it. Returns the sections that match best, each with its own text, so one call is usually enough to answer from. A hit marked ``truncated`` was cut short: read its page for the rest. Start here when you do not know which page holds the answer. - ``page``: one whole page as Markdown. Pass a name from the contents (the first page is ``overview``); a title or a documentation URL also works. Pass ``page`` or ``query``, not both. Answer from the returned text rather than from memory, and give the user the page's ``url`` so they can read it themselves. A page with no ``url`` is one of the notes for agents: tell the user what it says, there is no link to give. When nothing matches, the documentation does not cover it: tell the user that, and do not infer an answer from what is missing. Pages in the group "For agents" are reference written for you and are not on the website: ``agents/gaps`` (what every check_done gap means and what closes it), ``agents/errors`` (what an error or refusal means and the fix) and ``agents/formats`` (exact file and JSON formats, exit codes). Every answer carries ``account``: the user's plan, and on the free plan a note on what is refused, so you do not suggest a feature this account cannot use. The table of contents has the full list of paid tools. This is the one tool that works with no account: a connection without credentials can read the documentation, and its ``account`` is null. Every other tool needs the user to sign in first.

Return the fix-it prompt the web UI's 'Generate prompt for everything wrong' button produces for a branch — the common-case one-shot for "fix everything broken here". Resolves the repo + branch, finds the latest analysis, generates (or fetches a cached) bulk prompt, and waits up to ``wait_seconds`` for completion. ``repository`` is required — pass the GitHub 'owner/repo' for the project the user is working in. You (the MCP client) almost always know this from the working directory's git remote, the open workspace, or the conversation; pass it explicitly rather than calling ``list_repositories`` first. A repo UUID is also accepted for callers that already have one. ``branch`` defaults to the repository's default branch. ``scope`` selects what to aggregate (default ``"everything"``): - ``untested`` — all functions with no tests yet - ``partial`` — all functions only partially covered - ``failing`` — all failing tests - ``everything`` — failing tests + all untested + partial functions - ``frontend`` — TypeScript components grouped with the handlers and render branches inside them that nothing exercises yet; Playwright/React-Testing-Library oriented rather than a flat function list Returns the same shape as ``get_bulk_prompt`` — on cache hit / completed generation, ``{status: "completed", prompt_text, ...}``; on timeout, ``{status: "pending", generation_id}`` so you can resume via ``wait_for_prompt``.

Get a ready-to-use test prompt for one function. **Free — no subscription, no token budget, no rate limit.** Rendered deterministically from the function's AST plus its coverage rows: the signature, what to call, which exact lines never execute, which branches only go one way, what it raises, and which tests already touch it. Use this as the default way to turn "this function is untested" into "here is what to write". ``get_generated_prompt`` is the paid, LLM-polished counterpart — it adds repo conventions and richer context, but this one is free and always available, and for most functions it is enough to write the test from. Also accepts a React sub-unit id. The prompt then matches what the unit is: fire this handler on this element and assert the effect, or render the component in the state that takes this branch. ``kind`` and ``display_label`` come back alongside the prompt. Errors if the function is already fully covered — there is nothing to prompt for. The exception is a covered function that no browser test and no recorded manual session has reached: that still has a real ask (drive it in a browser), so it returns a prompt saying exactly that.

Return a single meta-prompt covering many items in an analysis. ``scope`` selects which slice to aggregate: - ``untested`` — all functions with no tests yet - ``partial`` — all functions only partially covered - ``failing`` — all failing tests - ``everything`` — failing tests plus all untested + partial functions - ``frontend`` — TypeScript components grouped with the handlers and render branches inside them that nothing exercises yet; Playwright/React-Testing-Library oriented rather than a flat function list Cache hits return immediately; cache misses enqueue a fresh generation and poll for up to ``wait_seconds``. On timeout the caller gets the ``generation_id`` and can call ``wait_for_prompt`` to keep waiting. For the common 'fix everything wrong on a branch' workflow, prefer ``fix_branch`` — it takes 'owner/repo' directly and saves the list_repositories → list_analyses chain.

Source + uncovered lines for one function. The agent typically calls this after ``list_untested_functions`` to pick a target and write tests for it directly without going through the prompt generator.

Return a meta-prompt for writing tests for the function. Cache hits return immediately. Cache misses enqueue a fresh generation and poll the row for up to ``wait_seconds``. On timeout the agent gets the ``generation_id`` and can call ``wait_for_prompt`` to keep waiting.

List analyses for the given repository, newest first. ``repository_id`` is the GitHub ``owner/repo`` (a repo UUID also works). Mirrors the BranchView's per-branch state. ``commit_sha`` is the commit the analysis was refreshed against. For the common 'fix everything wrong on a branch' workflow, prefer ``fix_branch`` — it resolves the latest analysis for you.

List the caller's repositories. Wraps the same data the web UI's repo list shows. For the common 'fix everything wrong on a branch' workflow, prefer ``fix_branch`` — it takes 'owner/repo' directly and you usually know that from the working directory / git remote.

List functions in an analysis, filtered by coverage state. ``state_filter`` is a comma-separated subset of ``untested,partial,covered``. Default skips fully-covered functions — those are typically what an agent looking for "tests to write" cares about. Rows include React sub-units — an inline JSX handler (``Component.<onSubmit>``, ``kind="handler"``) or a conditional render branch (``Component.<branch#1>``, ``kind="render_branch"``) — because "this component's error state never rendered" is usually the actionable gap, not "this component is 80% covered". Filter on ``kind`` in ``("function", "component")`` when you want whole functions only.

Set verifAIed up for a repository. **Free.** Call this first after the verifAIed MCP is connected, and again after each step. Pass the repository as ``owner/repo`` from the git remote (a repo UUID also works) and the current git branch; the default branch is used when ``branch`` is omitted. Returns an ordered checklist. Each step has a ``status``: - ``done``: the server saw the result (a committed file, an analysis for the branch). No action. - ``todo``: required and not done. ``commands`` and ``files`` say exactly what to run and write. - ``check_locally``: required, but only your machine can tell (the CLI on PATH, the CLI's login). Run ``verify``; carry the step out if it fails. - ``recommended``: not required; verifAIed asks you to offer it to the user rather than skip it. - ``optional``: not required; mention it once. ``next_step`` names the step to do now and ``complete`` is true when no required step is left. A step with ``needs_user`` true needs a person — for ``cli_token``, to approve the ``verifaied login`` you run in the browser. This tool never mints or returns a token. This tool reads the repository through the GitHub App and never changes it. You write the files; the user commits them. ``facts`` says what was read, and ``facts.github_reachable`` is false when the tree could not be read, in which case every step the tree would have settled is ``check_locally``.

Upload local coverage + current source and get back what's still untested — the core self-correction loop for writing tests without waiting on CI. Works for Python (pytest-cov) and TypeScript/JavaScript (vitest + Istanbul). ``coverage_kind`` selects the dimension: ``"unit"`` (default) is the test-suite coverage flow described here; ``"browser"`` records an independent per-function *browser-session* dimension from a real browser run — any coverage format (Istanbul for a frontend harvest, pytest-cov for a coverage-instrumented backend serving the browser's requests), no junit. A branch's browser coverage is the **union** of what each producer last reached — its wrapped suite, and each recorded test's latest replay — and this upload replaces only the contribution of the producer it belongs to, per language (a TS-only browser upload never zeroes the Python dimension, and vice versa). It surfaces as ``browser_state`` (``exercised``/``partial``/``unexercised``) + ``browser_line_coverage_pct`` on each function and as the ``unexercised_browser`` gap in ``check_done``, and never changes unit state. Browser and manual uploads are also recorded in the branch's session ledger, so the Tests page can say what produced them. Pass ``session_id`` if you opened one; otherwise this upload becomes its own session, attributed to ``agent`` — you. Run your tests with coverage locally first: - Python: ``pytest --cov --cov-branch --cov-context=test`` then ``coverage json --show-contexts -o coverage.json`` (pytest-cov's own ``--cov-report=json`` drops the per-test contexts) - TS/JS: ``vitest run --coverage --coverage.provider=istanbul --coverage.reporter=json`` → ``coverage/coverage-final.json`` Pass a ``files`` map of {source_path: contents} for the files under test, plus **exactly one** of: - ``coverage_json`` — a single parsed report (pytest-cov or Istanbul). - ``coverage_reports`` — a list of parsed reports, merged with same-file-later-wins; use this to send both a pytest-cov and a vitest report in one upload for a mixed-language repo. IMPORTANT: the keys of ``files`` must exactly match the file paths the coverage report records (relative to the directory the tests ran from). If they don't, nothing matches and ``functions_matched`` comes back 0. Stored and returned paths are always repo-rooted. If your tests ran from a subdirectory of the repo (a monorepo package), pass ``path_prefix`` — the repo-root-relative directory the tests ran from (e.g. ``"backend"``; ``""`` if they ran at the repo root). Omit it and the server resolves the prefix against the repo tree best-effort, else stores paths as sent. All reports in one call share one root — split a multi-root upload into one call per root. ``functions_matched`` and the untested/partial lists count whole functions only; React sub-units matched by the same upload are reported separately as ``units_matched``, so those numbers stay comparable across uploads and against a repo's own sense of its size. Uploads are merged per language, so a TS upload never wipes a branch's Python coverage (``functions_preserved`` reports how many rows were kept). Upserts a single local analysis per branch, kept separate from any CI run. Returns the coverage summary plus the untested/partial functions and failing tests so you can fix them directly; the function ``id``s work with ``get_function_detail`` and ``get_generated_prompt``. ``repository_id`` is the GitHub ``owner/repo`` (a repo UUID also works) — the same reference every other tool here takes.

Judge a screenshot of the running UI. **Paid.** You drive the browser; verifAIed judges what you got. Take a screenshot of the change you just made, say what it was supposed to do, and this returns a verdict — plus records it, so ``check_done`` can hold the branch to it. Two modes: - With ``intent`` (recommended): checks one claim. "The error state now shows a Retry button" → ``pass`` / ``fail`` / ``unclear``, with a confidence and the reasoning. ``unclear`` is a real answer, used when the screenshot doesn't show the region the claim is about — treat it as "screenshot the right thing and ask again", not as a pass. - Without ``intent``: a rubric review (layout, hierarchy, legibility, consistency, obvious broken state) returning ``clean`` or ``issues`` with a defect list. ``target`` attaches the verdict to one component as ``path/to/File.tsx::ComponentName``, which is what clears that component's ``visually_unreviewed`` gap. A target that doesn't resolve is not an error: the verdict is still recorded against the branch and the response carries a ``warning`` saying so. ``screenshot_base64`` is the raw image bytes, base64-encoded (a ``data:`` URL prefix is fine). PNG, JPEG, GIF or WebP; a viewport-sized capture is plenty and anything over ~1.5MB of base64 is rejected with a resize hint. Pass ``console_errors`` when you have them — a visual defect and a console error are very often the same bug. The screenshot **is stored** as session evidence: each call opens a one-moment session in the branch's ledger and attaches the image to it, so the Tests page can show the frame the verdict was about. The reasoning text is still the record — the picture is the receipt. Failing an intent check creates an ``intent_mismatch`` gap; a changed component with no verdict creates ``visually_unreviewed``. Both activate only once this branch has at least one verdict, so a repo that doesn't use this tool never sees them.

Poll a prompt generation row until it transitions to completed or failed, or until the timeout. The companion to ``get_generated_prompt`` — call this if the first call returned ``status: pending``.