Skip to main content
Glama

Audit Standard Book

audit_standard_book
Read-only

Audits one Standard Books document — a set of books: chart, journal, registers, parties and recorded documents — for bookkeeping errors. Supply the book by transfer handle (a sealed book package, a book body, or {book, annotations}), or a small one inline as book. The book is authenticated when sealed and admitted under book law before anything is spent; a book sealed under an older format is refused and must be resealed.

Exact controls are computed in arithmetic with no model: unbalanced entries, entries outside the period, balances opened with nothing stating them or against equity (alone or in a multi-account opening), income debited by purchases, credits beyond the charge. Findings are model judgments over the whole book at once, laid out as a bookkeeper reads it, and each finding quotes the entries and documents it rests on, in ASCII, checked against the book before it is accepted: a purchase posted to income, an opening bill expensed again, a refund or credit that does not match its sale, conflicting dates, entries that need support, and more. Every finding is a question for the bookkeeper with its evidence; certainty says whether it is a confirmed discrepancy, a suspected error or missing information.

Nothing is changed: not the book, not the workspace. The result is a summary with the exact controls inline and the whole report — every finding, citation and question — behind a multi-read download handle; analysed_book_handle names the book with this audit written on it as its analysis, sealed. A book already carrying its own audit, or already audited in this workspace, is answered with no model run; a call for a book whose audit is running attaches to that run, so after a timeout call again with the same book. status is reviewed, needs_information, or incomplete when a request could not be answered (incomplete names which). Findings vary between runs and do not certify that problems are absent. Model-backed and metered; typically three to five minutes.

Input Schema

NameRequiredDescriptionDefault
bookNoA small book inline: a sealed book package, a book body, or {book, annotations}. Exclusive with handle.
handleNoWorkspace-scoped transfer handle (upload:N or download:N) naming the book: a sealed book package, a book body, or {book, annotations}. The usual path; a book is hundreds of kilobytes.
workspace_tagYesActive workspace id (the workspace_tag create_workspace and list_workspaces return). Scopes the call and its metered usage.

Output Schema

NameRequiredDescriptionDefault
bookYesWhich book was audited: identity, chart_identity, name, reporting_currency and its counts, as verify_standard_document reports them.
engineYesStamped engine build/version identity for the tool result.
handleYesMulti-read download:N handle naming the whole report: status, controls, findings (kind, certainty, summary, accountIds, entryIds, citations, questions), questions, incomplete and limitations.
statusYesreviewed (nothing found), needs_information (controls or findings to answer), or incomplete (a request could not be answered).
controlsYesThe exact controls: code, message, question, postings, reports and evidence.
retainedYesDownload descriptor for the report: session_id, handle, file_name, media_type, byte_count, sha256, expires_at, download_program.
incompleteYesRequests that could not be answered: scope (the chart accounts) and message. Empty unless status is incomplete.
analysed_bookNoDownload descriptor for the analysed book.
control_countYesExact arithmetic controls that fired.
finding_countYesFindings in the report; one problem reported from several accounts counts once.
finding_kindsYesFindings per kind: opening_balance_gap, expense_in_revenue, opening_liability_expense, refund_mismatch, credit_mismatch, date_conflict, missing_support, other_book_issue.
workspace_tagYesWorkspace scoped by the tool call.
question_countYesQuestions for the bookkeeper across controls and findings.
analysed_book_handleNoMulti-read download:N handle naming the book with this audit written on it as its analysis, sealed: the book again, not a new one (its identity is unchanged).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the annotations: nothing is mutated, the call is model-backed and metered, takes three to five minutes, refuses books sealed under an older format, and findings vary between runs so absence of problems is not certified. The no-model-run and attach-to-running-audit semantics are exactly the kind of context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, authentication rule and input routes are front-loaded, and the dense sentences each carry real information about determinism, output shape and retry behavior. It is long, and the enumeration of book package forms duplicates the schema description, costing some tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully characterizes the return: a summary with exact controls inline, the full report behind a multi-read download handle, an analysed_book_handle, and the reviewed/needs_information/incomplete status values. Nothing an agent needs to call or interpret this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so handle, book and workspace_tag are already documented, including the upload:N/download:N form and the size rationale. The description mostly restates the accepted book shapes and adds only the resealing constraint, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (audits one Standard Books document) and defines what a book comprises: chart, journal, registers, parties and recorded documents. That scoping distinguishes it from siblings like compare_standard_books, report_standard_book and verify_standard_document without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the two input routes (handle as the usual path for large books, inline book for small ones) and gives concrete operational guidance: a book already audited is answered with no model run, a call during a running audit attaches to that run, and timeouts should be retried with the same book. It does not explicitly compare against the closest audit/report siblings, which keeps it below 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources