Loading ToolBench
Model Context Protocol server that fronts the open-source accounting suite's deterministic tools: bank-statement and OFX parsing, document classification, workpaper-spec validation, exact money math, and webhook HMAC verification.
Strong foundation with 8 well-named, action-verb tools and comprehensive parameter schemas. All tools have descriptions (avg 180 chars, within baseline 194). Input schemas are complete with types and descriptions for all parameters. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is present but generic (error_envelope pattern) without recovery guidance. No tool annotations (readOnlyHint, idempotentHint). Money and HMAC tools are in-process and deterministic; statement/OFX/document tools shell out to CLIs with availability checks via list_capabilities.
Classify a single accounting document's text into the kit taxonomy. Labels: ``w2``, ``form_1099``, ``invoice``, ``bank_statement``, ``receipt``, or ``unknown`` (honest abstention). Uses doc-classifier-kit's dependency-free keyword baseline. Returns ``label``, ``confidence``, and a short ``rationale``.
List every tool this server exposes and whether it is ready to run. Shell-backed tools depend on a sibling CLI being installed; this reports which resolve on the current host so an agent can plan around what is available. In-process tools (money, HMAC) are always ready.
Split an amount across ratios or evenly with no lost minor units. Uses the largest-remainder method: each recipient gets the floor of its proportional share, then the leftover minor units are handed out one at a time to the largest remainders (ties broken by lower index). The parts always sum back exactly to the original amount, with no lost or invented minor units. Exactly one of ``ratios`` or ``parts`` must be given.
Apply a rate to an amount with explicit rounding. Multiply an amount by a real ``rate`` (a tax rate, discount, or share). The exact product is computed in decimal and rounded to whole minor units with the requested strategy. Use this for tax, tips, or applying a percentage; the result is a clean integer minor-unit amount.
Output schemas not documented. LLMs cannot predict response structure (e.g., what fields are in 'statement' object, what 'error_envelope' contains). Baseline: 100% of A+ tools document return types.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). All tools are read-only or deterministic, but LLMs cannot infer this without explicit hints. Baseline: current spec (2026-07-28) rewards tool annotations.
Error handling lacks recovery guidance. error_envelope returns error code and message but does not tell LLM what to do next (retry? ask user? call list_capabilities?). Baseline: pattern:recovery-guide requires actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Normalize a raw bank or credit-card statement into transaction JSON. Pass the statement's text/content in ``content``. The format is auto-detected (CSV, OFX/QFX, MT940, CAMT.053, CAMT.052, QIF, or text); set ``fmt`` to force one. Deterministic and rule-based. Returns the normalized statement under ``statement``, or an error envelope.
Normalize an OFX/QFX or CSV bank export into transaction JSON. Backed by the ``ofxnorm`` CLI from ofx-normalizer. ``fmt`` is ``auto``, ``ofx``, or ``csv``. Returns the normalized statement under ``statement``. Note statement-normalizer also reads OFX/QFX if ofxnorm is not installed.
Validate a document against a cpa-workpaper-spec JSON Schema.
Constant-time verify a Stripe/hex/base64 webhook HMAC signature. Verify a webhook signature. Returns a verdict dict, never raises. Supports stripe, hex, and base64 schemes with constant-time comparison.
validate_workpaper description is vague (60 chars). Does not explain what 'cpa-workpaper-spec' is, what schemas are available, or when to use it. Baseline: descriptions should be 50-200 chars and answer WHAT, WHEN, and WHAT IT RETURNS.
normalize_ofx and normalize_bank_statement both parse bank statements but with different backends (ofxnorm vs statement-normalizer). Descriptions do not clearly distinguish when to use each. LLMs may conflate them.