buddie

io.github.tsyyanPublished by GitHub account tsyyanv2.0.8Updated Nov 3, 2026

Checks AI agents' claims against primary evidence, with no model; observes only what you grant.

Overview

buddie's local MCP server; no sign-in required; STDIO; 8 tools.

No AI overview yet: these facts come from the registry entry and the server itself.

Installation

In SourceWeft

  1. Open buddie in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

Why buddie?

An agent finishes a task and tells you that CI passed, that a source supports its summary, or that your laptop has CUDA and Python 3.12. It sounds certain, and often it is right. When it is wrong, the mistake hides inside a confident sentence.

buddie separates what can be checked from what is only claimed. It checks supported claims against the evidence itself, gives the agent real observations of your machine instead of guesses, and marks what it could not check as unchecked. In 929 checkable quotations from published deep-research reports, 212 were altered or absent from the page they cited; buddie flagged 207 of them (research). In Claude Code with the plugin, a seeded false quotation reached the reader in 24 % of paragraphs instead of 88 % (BDX-003).

What buddie does

Verify. buddie checks supported claims against their evidence: a quotation against the page it links to, a file or commit against your repository, a merged PR or a green CI run against GitHub, a test result against the session's record of the command. No language model takes part in the check, so the agent cannot argue its way to a different verdict.

Catch mismatches. In Claude Code and Codex, buddie's hook checks supported claims at Stop and returns failures with the reason. In Claude Code the answer is already visible at that point; buddie asks for corrected lines instead of another copy of the whole answer. Supported message checks before delivery retain their existing behavior. Other clients call the checks through MCP or the command line and decide what to do with the result.

Observe. Before it suggests a command, an agent can ask buddie for the parts of your machine the task needs: the operating system, CPU, memory, GPU, Python, runtimes, tools. buddie reads only the categories you have granted, changes nothing, and records how each value was observed.

Discover. The compact Claude plugin includes a Discovery skill for evidence triage with the tools available in the current session. It uses real Core verification when connected, performs independent checks otherwise, and marks unavailable checks as not checked. Local hooks and MCP capabilities vary by surface; Cowork, Chat and mobile require separate live verification. Projects/Context remains a future design.

See it in action

Verify an agent's claim

An agent reports that it fixed a date parser and that the test suite is green. It marks the claim with a small anchor, ⚓ run:pytest -q => 41 passed, that buddie can check. The session transcript records what the test command actually printed:

[Verify, from a real run on the bundled examples/work fixture. Agent claim: the test suite is green, run:pytest -q => 41 passed. Evidence check, session transcript: 1 failed, 40 passed in 3.1s. Verification outcome: FAIL, effects 0/1 hold, 1 broken, exit 1.]

Run it yourself from a clone; the report and transcript are in examples/work:

bash
cd buddie/examples/workbuddie verify report.md --transcript session.jsonl --no-github
BLOCK anchor line 3 ⚓ run:pytest -q => 41 passed: output has no '41 passed'; it ends: ….......................................... 1 failed, 40 passed in 3.1snote  pr:/ci:/run: anchors show what happened (PR state, checks on a commit, a command and its output), not that the code is correctbuddie FAIL: effects 0/1 hold, 1 broken

The files are a teaching fixture: buddie reads the recorded output rather than rerunning pytest. --json receipt.json also writes a receipt naming the evidence behind the verdict. Quotation, PR and CI examples, and which integration checks what: verification guide.

Know the environment

An agent is asked to set up a local development environment. Instead of guessing the operating system, GPU or Python version, it asks buddie for three categories, which the person has granted:

[Observe, from a real run on one Windows machine. Task: configure local development environment. Authorized categories: system.os, hardware.gpu, software.python. Observed: OS Windows 11; GPU NVIDIA GeForce GTX 1650, 4 GiB; Python 3.14.6 with pip and venv.]
bash
buddie snapshot --category system.os --category hardware.gpu --category software.python \  --task "configure local development environment" --json diagnostics.json
buddie snapshot: diagnostics of 3 categories (grants active, policy absent; these govern the categories only)  system.os: collected    name: Windows 11  [os_interface]  hardware.gpu: collected    adapters: [model NVIDIA GeForce GTX 1650, source nvidia_smi_gpus, vendor NVIDIA, vram_bytes 4294967296]  [fixed_program]  software.python: collected    buddie_runtime: implementation cpython, pip True, venv True, version 3.14.6  [buddie]

Abridged from a run of buddie 2.0.0: the lines shown are unedited, and the machine's other observed values are left out. diagnostics.json holds the full document, with the method and time of each value.

Nothing is observed until you grant it (/buddie:init offers it). The template grants the low-sensitivity categories, Docker and Podman clients included:

bash
buddie snapshot --grant-baseline          # writes the grants file, baseline only (never over yours)buddie snapshot --grant-template          # prints it, to edit by handbuddie snapshot --grants                  # what is granted now

Sensitive categories (the Docker daemon, disk usage, a project, a repository) are added to it one by one.

A category you have not granted is reported as denied, and its collector never runs. A value buddie cannot read is marked unavailable, with the reason. Diagnostics is read-only and installs nothing; it gives the agent better facts, not a guarantee that its next command is right. Categories, grants and the document.

Get started

buddie needs Python 3.11 or newer and has no dependencies.

Claude Code

The recommended start. The plugin adds the answer check, the MCP tools including environment diagnostics, and run: checks against the session transcript:

/plugin marketplace add tsyyan/buddie/plugin install buddie@buddie

It installs the latest released plugin (the plugin-stable branch), not unreleased work on main. To allow diagnostics, save the categories you choose as environment.toml in ~/.config/buddie/ (%APPDATA%\buddie\ on Windows). For the demo above:

toml
version = 1allow = ["system.os", "hardware.gpu", "software.python"]roots = []

Levels, the intro mode and what the hook reads: Claude Code guide.

Other integrations

  • Codex: codex plugin marketplace add tsyyan/buddie, then codex plugin add buddie@buddie, and enable its hook in /hooks. The check runs at Stop; run: claims stay unchecked. Codex guide
  • Any MCP client: uvx buddie serve starts the stdio server. There is no gate: the agent calls the tools. Integrations
  • Command line and CI: pip install buddie, then buddie verify REPORT.md --json receipt.json. It exits 1 on FAIL; GAPS and EMPTY exit 0, so a CI step that requires PASS should read the receipt's outcome.
  • Claude Desktop: the .mcpb bundle from Releases, without a gate. Desktop guide

Every surface in detail: getting started.

Release status

Version
Release described here: PyPI, GitHub Releases, the Desktop bundle, the MCP Registry2.0.8

Upgrading from 2.0.5 changes nothing you have to do: 2.0.8 makes the hook's Python commands explicit for Anthropic directory inspection, preserving isolated mode, interpreter fallback and hook behavior. Claude Code's marketplace continues to install releases from plugin-stable.

Upgrading from 2.0.2: 2.0.4 includes canonical Discovery, the README-style dog icon and Toolkit positioning, Linux worker guard hardening, and Stop-hook guidance that asks for corrections without repeating the already displayed answer. No new permissions are required; on Linux a failed parent-death guard now prevents the regex worker from running. Discovery leaves unavailable checks unverified. The 2.0.3 candidate was superseded before publication.

Upgrading from 2.0.1 changes nothing you have to do: 2.0.2 adds the local feedback tools (feedback_start, feedback_resolve, feedback_accept), GitHub citation checks and versioned public release notes. Upgrading from 2.0.0 changes nothing; 2.0.1 fixed how the MCP server reads its input on Windows systems whose code page is not UTF-8. Upgrading from 1.1.1 changes nothing for a 1.x setup. What can differ, and why, is in the changelog.

Documentation

TopicRead
Install on every surfaceGetting started
What each integration doesIntegrations
Checks, outcomes and receiptsVerification, receipts
Environment diagnosticsEnvironment
Security and privacyLimitations, security, privacy
ContributingCONTRIBUTING.md
Everything elseDocumentation index

Limitations

buddie is not a truth detector. It checks claims in the forms it recognises, such as quotations with links and anchored claims about files, PRs, CI and commands, against the evidence it can read. Paraphrases and unanchored claims stay unchecked. PASS covers only what was checked, and GAPS and EMPTY are not passes.

The answer check exists only in Claude Code and Codex, and it returns an answer rather than locking it: the agent fixes the claim or discloses it as unverified. An agent running as your user can edit local evidence, settings and the diagnostics grants file; only an administrator's protected policy sets limits it cannot raise.

buddie runs locally, with no model calls and no telemetry. It fetches the pages a report cites and calls GitHub for PR and CI claims. All limitations · Security boundaries · Privacy


Source: README.md at commit b4a9b4c

Tools

8

verify_report

Verify a report

Check a report before accepting or passing it on: every quote must be in the bytes of the source it links to (verbatim), every `⚓` anchor must hold in the repos, on GitHub (pr:, ci:) or in the session transcript (run:). Returns a receipt with outcome FAIL / GAPS / PASS / EMPTY, the blocking items and a one-line summary. Only quotations in quotation marks with a link to their page in the same sentence, and ⚓ anchors in backticks, are checked: write e.g. Article 2.10 says «Юридическое лицо, присоединившее другое юридическое лицо, подлежит ответственности» ([КоАП РФ, ст. 2.10](https://www.zakonrf.info/koap/2.10/)). EMPTY means nothing was checkable, not that the text is right.

Parameterspathtextfetchreposstoreaccesschecksgithubmodulesnumbersprofilereceipt+1 more

snap

Snapshot pages

Snapshot URLs (bytes by sha256) so quotes can be taken from and checked against them. Call it before quoting a page, then copy the words from source_text and link the same URL.

Parametersurlsrequiredstore

source_text

Read a snapshot

Visible text of a snapshot (URL or sha256 prefix). With grep, only the matches with context. Copy quotes from here character for character, put them in quotation marks “…” or «…», and link the snapshot's URL right after the quote in the same sentence.

Parametersrefrequiredgrepstorecontext

summary

Subagent summary

When no subagent is left: the summary built by code from the hook's records (what each subagent did with its receipt outcome, who was lost, the next steps with auto/ask verdicts, open PRs and red CI) and `card`, a ready AskUserQuestion input with at most three steps and «Ничего не запускать». Show `text` as is and ask with `card` unchanged; launch `auto` steps yourself and the picked ones with the anchor ⚓ choice:<summary_id>=<step>.

Parametersqueuereposstalesession

environment_snapshot

Observe this machine (granted categories)

Before giving system-specific instructions (install commands, drivers, setup), observe the parts of this machine the task needs instead of guessing: ask only for those categories (list: true names them). buddie collects what the person granted in their local grants file and the administrator's protected policy allows; anything else comes back denied, unsupported or unavailable with the reason. A request cannot grant: there is no consent argument, and an approval of this call is not a grant. The grants file states the person's intent; an agent with their file access could edit it, so only the protected policy is a ceiling it cannot change. This tool collects diagnostics categories only, never files or reports. Each observation says what it rests on (basis); unavailable means not observed, not absent. Nothing is installed or changed.

Parameterslistpathtasktoolscategories

feedback_start

Start verification feedback

Check a report and open a verification feedback chain (docs/feedback.md): buddie runs the check itself, keeps the chain and its check options in files of its own, and returns a feedback-v1 with at most one bounded action per finding. To answer it, correct only what an action names and call feedback_resolve. Feedback is advice: a verified report is not a finished task unless the requirements you state are met (state.task).

Parameterspathtextfetchreposstoreaccesschecksgithubmodulesnumbersprofiletranscript+2 more

feedback_resolve

Resolve verification feedback

Answer a chain's open feedback with one corrected text: buddie checks the corrected text itself with the chain's own check options, judges the correction (scope, no added lines but 'buddie:' disclosures, verified claims kept) and appends the decision to the chain. Returns the decision and the next feedback. A refused submission (code) changes nothing.

Parameterschainrequiredfeedbackrequiredsubmissionrequiredoriginal_textrequiredcorrected_textrequired

feedback_accept

Accept a final report from a feedback chain

Before accepting a final report from a feedback chain: whether it is the text the chain verified. accepted is true only when the chain's disposition is verified and the report is byte for byte the chain's last accepted text; a report edited afterwards, a refused repair handed in anyway, or any report of a chain that is not verified is refused (reason). Reads the chain, checks nothing, changes nothing.

Parameterschainrequiredfinal_textrequired

Version history

8
  1. v2.0.8LatestNov 3, 2026
  2. v2.0.7Oct 31, 2026
  3. v2.0.6Oct 29, 2026
  4. v2.0.1Oct 26, 2026
  5. v2.0.0Oct 25, 2026
  6. v1.1.1Oct 20, 2026
  7. v1.0.1Oct 20, 2026
  8. v1.0.0Oct 19, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts