@mybestie/check

@mybestie/check

CLI and stdio MCP for Bestie Check. Workspace packages (@repo/check-*) are bundled into Node bins; they are not published dependencies.

Preparing a document is always available. An agent can put a document into Check custody and read the free Claim and Assumption Quick Look: the claims the document makes and the assumptions they rest on.

Paid verification follows the server. quote, create, verify and repair run only when the Check server reports paid checks ready for your credential (check capabilities shows paidExecution.available). Otherwise they exit 4 with paid_execution_unavailable and the server's reason, after one read-only capabilities call, and dispatch nothing. Paid runs stay quote-bound: approve with the quote id, its hash, an authenticated --approval-ref and a credit ceiling. A bare --approve is always rejected, and nothing in this package approves spend for you.

quote returns a confirmationUrl. The human approves that exact quote on the authenticated Bestie page; the CLI then sends its server-issued approvalRef. A chat confirmation alone does not create approval. verify reuses the quoted --upload; it never ingests a different file for that quote.

npx @mybestie/check@0.4.0 login
npx @mybestie/check@0.4.0 capabilities
npx @mybestie/check@0.4.0 prepare --file memo.pdf --wait --progress
npx @mybestie/check@0.4.0 prepare --text "…" --wait --until first-claim
npx @mybestie/check@0.4.0 inspect --upload <uploadHandleId>
npx @mybestie/check@0.4.0 retry --upload <uploadHandleId>
npx @mybestie/check@0.4.0 mcp

The CLI and the MCP servers serve funded accounts: an account that already has units. The stdio MCP server lists the paid tools only when the server says paid checks are ready for your account; CHECK_MCP_AVAILABILITY=preparation|paid overrides that explicitly (full adds offline replication fixtures and is for contract tests only). Units are added on the website, never here.

Every command prints JSON on stdout (errors as JSON on stderr). A preparation snapshot carries nextAction: wait, review (Quick Look finished; partial if some units failed), retry (run check retry), replace_source (ingestion failed; prepare the same source again), or put_bytes.

Exit	Meaning
0	success (prepare --wait / wait: nextAction is review)
1	API or internal error
2	usage error
3	a valid state that needs you to act (retry, replace_source, put_bytes)
4	not available: this account has no units yet, or paid verification is closed on this server (the message says which)
5	timed out while still running; nothing failed, wait again
6	`findings --fail-on <blocking
130	cancelled

check login runs a managed WorkOS OAuth flow with dynamic client registration and loopback PKCE: it creates an S256 challenge, opens the provider consent page, receives the loopback callback, and stores access and rotating refresh credentials in a local credentials file (Unix 0600 / Windows ACLs). Requests refresh near expiry under a process-safe rotation lock. The CLI never reads a WorkOS session cookie. BESTIE_API_KEY still overrides the stored file. AI_GATEWAY_API_KEY is unrelated and ignored.

check mcp serves the same preparation tools over stdio (inspect_capabilities, prepare_deliverable, prepare_file_upload, confirm_file_upload, get_preparation, retry_preparation, plus reads of existing checks). The paid tools (quote_check, verify_deliverable, create_repair) are listed when the server reports paid checks ready for your account, which means the account has units.

Published on the public npm registry as @mybestie/check (@bestie is a third-party npm user and cannot be used). The journey contract is packages/check-api-contracts/AGENT-JOURNEY-CONTRACT.md in the monorepo.