MCP · PG-03 # The accounting MCP server for agents that read and propose MCP parity with the HTTP surface — same semantics, same error taxonomy, same authorization model — remote or stdio, and air-gap capable with your own local model. - scoped per-tool credentials - no agent approvals - every call provenanced - remote or stdio Ledgerbook AI is an accounting MCP server: agents connect over MCP and reach the same ledger as the HTTP surface, with the same semantics, error taxonomy and authorization model. The surface is read and propose. Agents read balances, entries, lineage and provenance; they propose entries that run the server-side materiality gate. An agent cannot approve, finalize or correct — approval is a content-hash-bound object that any edit voids, and credentials are scoped per tool, expiring, with a test class that can never write to a production ledger. Every call appends a provenance event. MCP runs in-core: remote or stdio, air-gap capable with your own local model, no vendor inference endpoint. The full tool surface is on the roadmap. Verified 2026-09-19 · Sources: Ledgerbook product docs — MCP interface (FR-343) and deployment (NFR-6) · Phase: PH-1 read/propose; full tool surface Roadmap Phase legend: ✓ PH-1 shipped now · ◇ Roadmap arrives with PH-2. Labels are always present — colour is never the only signal. ## What stops an agent from posting whatever it wants? The gate is an invariant enforced server-side, not a prompt instruction or an app-level permission setting. It applies identically to MCP, REST, CLI and streaming callers. ### Scoped per-tool credentials MCP credentials are bound to one audience and scoped per tool: ledger, entity, book, scenario, account range, action class and expiry. A read-only credential never reaches a write path; a credential scoped to entity A asking about entity B gets an authorization error — never an empty result. FR-802 · PH-1 ### Agents cannot approve, finalize or correct An agent credential carries read and proposal scopes only. Approval, posting and correction rights cannot be granted to an agent actor — enforcement lives at the credential, not the prompt. Automated finalization happens only under T0 policy, attributed to a system actor with its policy id. FR-220, FR-804 · PH-1 ### Approvals are content-hash-bound An approval binds the entry id, revision number, content hash, policy id, tier, approvers and decision inputs — and is usable exactly once, for the hash it names. Any material edit voids a pending approval and returns the entry to Provisional. FR-215/216 · PH-1 ### Materiality tiers evaluated in the core Tiers are computed server-side from stored policy — amount, account class, actor kind, period state — and no request field, header or tool argument can downgrade one. T0 (auto, within a recorded ceiling) and T1 (single approver) ship at PH-1. FR-217–219 · PH-1 T0/T1 ◇ Roadmap T2 dual / T3 governance tiers, with derived and recorded thresholds, arrive with PH-2. ## Connect without a browser round-trip Agent and builder credentials are bootstrap-issuable programmatically: a self-host bootstrap token or an admin-minted registration, straight from the CLI or a script. No signup UI stands between an operator and a scoped credential. Issue a credential scoped to one (ledger, audience) target and to a named tool set, with an expiry and scope-bounded registration. Issuance, rotation and revocation are themselves chained administrative events — auditable like any other write. FR-807, FR-802, FR-814 · PH-1 ### Live / test split A test-class credential exists that can never write to a production ledger: attempts are rejected before any state change and audited. Per-credential usage counters (requests, writes, rejects) surface through metrics, so an operator can see exactly what a fleet of agents did. FR-807, NFR-7 · PH-1 ## The tool surface: read, then propose Every MCP tool has an HTTP equivalent with identical semantics and the same typed errors — a locked scenario fails with SCENARIO_LOCKED over MCP exactly as it does over REST. Tool descriptions state required scopes and the writability errors they can raise. As-of and as-believed balances by ledger, book, scenario and account, returned with the chain position of the events that produced them. Filter entries by scenario, book, status and date — explicit or wildcarded scenario filters are resolved server-side against the writability matrix. Traverse qualified relationships across objects and source documents: the full ancestry of a number, multi-hop, in one call. Dry-run the full validator — balance, currency, account state, dimensions, equation, policy — and get structured errors without writing anything. Propose an entry. Proposals run the materiality gate; a pending approval is bound to the content hash, and any material edit voids it. Submit a proposal for review under its evaluated tier. The agent holds no posting rights of its own; every call appends a provenance event. | Tool | Class | Scope | Phase | |---|---|---|---| | get_balance | read | ledger:read | ✓ PH-1 | | query_entries | read | ledger:read | ✓ PH-1 | | get_lineage | read | ledger:read | ✓ PH-1 | | validate_entry · preview_entry · evaluate_policy | pre-flight | ledger:read | ✓ PH-1 | | create_provision · revise_provision · submit_provision | propose | provision.write · provision.submit | ✓ PH-1 | | Full tool surface — scenario operations, approval decisions, audit and credential administration, direct posting paths | write | per-tool scopes | ◇ Roadmap | Transport: remote MCP over HTTPS with OAuth 2.1 (resource indicators, PKCE, dynamic client registration) or a stdio package for air-gapped hosts. The stdio package and the MCP-registry listing (ai.ledgerbook, DNS-verified namespace) ship with the developer preview. FR-343, NFR-6 · PH-1 `# MCP client config — stdio transport, air-gap ready { "mcpServers": { "ledgerbook": { "command": "ledgerbook-mcp", "args": ["--ledger", "grp-eu", "--scopes", "/etc/ledgerbook/mcp-scopes.json"] } } } # remote transport: MCP over HTTPS · OAuth 2.1 (resource indicators, PKCE) # tools registered at PH-1: get_balance · query_entries · get_lineage · validate_entry # create_provision · revise_provision · submit_provision` MCP vs API-only — and why the gate is the product MCP is table stakes. Any vendor can wrap an API in the transport; that is not where governed access is won. The difference is what sits behind the socket: per-tool scoped credentials, a server-side writability matrix agents cannot bypass, content-hash-bound approvals, materiality evaluated inside the core, and a provenance event on every single call. And because MCP runs in-core, an air-gapped deployment keeps the identical tool surface: no SaaS hop, no vendor inference endpoint, no part of the write path that depends on someone else's cloud. [Connect an agent in under 10 minutes](/developers) **Context note — agent payment rails.** Authorization-and-settlement rails such as Visa VIC/TAP, Mastercard Agent Pay, Stripe SPT/MPP, x402 and AP2/ACP stop at payment: none posts to your books (captured 2026-09-19). Ledgerbook consumes their artifacts — mandate, token or receipt ids, agent id, policy id — as external references on linked source objects, never as ledger content. Native interop with these rails is ◇ Roadmap (PH-2). PD §1.8 · FR-235 mandate_ref · OI-24 ## MCP server FAQ It can be — if the server enforces the same governance as every other write path. Ledgerbook's MCP surface uses short-lived, scoped credentials (including a test class that can never write to a production ledger); agents receive no privileged bypasses of the server-side writability matrix; proposals run the materiality gate; and every call appends a provenance event. At PH-1 the MCP surface ships read and propose; the full tool surface is roadmap. Related: [AI-agent audit trail](/ai-agent-audit-trail) · [Security posture](/security) Read balances, entries, lineage and provenance; validate and preview proposed entries before commit; and create, revise and submit proposals. The read and propose tools ship at PH-1 — ◇ Roadmap the full tool surface — scenario operations, approval decisions, direct posting paths — arrives with PH-2. No. Agents hold read + propose scopes only; approve, finalize and correct remain human actions, enforced by the credential system — separation of duties is structural, not policy advice. Yes. MCP runs in-core — there is no SaaS hop and no vendor inference endpoint. In an air-gapped deployment the tool surface, its OAuth 2.1 authorization and every tool call function with inference served by your own local model runtime, and every non-agent surface stays fully usable with no local model present. [Self-hosted & air-gap](/self-host) covers the deployment classes. No. Ledgerbook AI is an accounting MCP server for a double-entry ledger of record. It is unrelated to hardware wallets, crypto tooling or payment ledgers; money in Ledgerbook is fiat ISO-4217 only, in integer minor units. The name is disambiguated deliberately: this is accounting infrastructure, and the entity is Ledgerbook AI. ## What Ledgerbook is not The surface is ours. The agent, the model and the conversation are yours. - **No models in the core (NG-4).** Ledgerbook ships no model and calls no external one. Your agent brings its own — including a local model in an air-gapped deployment — and governance is enforced at the credential, never inside the model or the prompt. - **No chat UI (NG-1).** The MCP client is whatever you already use. We publish the tools, the scopes, the provenance envelope and the error taxonomy; the conversation lives in your application. - **Not an ERP (NG-2).** An agent that needs to raise a purchase order still raises it in the system that owns purchase orders. What it gets here is a governed way to write the accounting consequence — and no way to approve its own entry. ## Give your agents a governed ledger surface Scoped credentials, proposal-only writes, provenance on every call — with the full surface on the roadmap.