Skip to main content
Glama

biii

by io.github.philpof102-svg

till_export

ACCOUNTING EXPORT: turn the verified receipts into an accountant-ready CSV that QuickBooks / Xero / Excel import (the export finance teams need to adopt). Every row carries its own txHash + Basescan link, so the accountant re-verifies each amount on Base themselves — the export is a POINTER to the chain, never a book to trust. Non-custodial (BIII moved no funds). Columns: date, receipt_no, reference, description, payer, gross_usdc, tip_usdc, charged_usdc, token, chain, tx_hash, basescan_url, status. Dedup by txHash; optional block-time window; brand slugs the filename. WINDOW HONESTY: a receipt with no on-chain block time cannot be proven to fall inside a dated window, so it is excluded from one — and summary.undatedExcluded reports HOW MANY were, with the same warning prepended to disclosure. If that count is non-zero the CSV is short by those rows: re-run with no window to see them all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brandNoWHITE-LABEL: a partner brand (string or {name}) — slugs the download filename; the non-custodial disclosure stays regardless.
receiptsYesthe verified receipt objects (from till_receipt), each carrying a txHash
toBlockTimeNooptional — only export receipts settled at/before this unix block time
fromBlockTimeNooptional — only export receipts settled at/after this unix block time

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels: it discloses non-custodial behavior, per-row txHash and Basescan links, dedup by txHash, optional block-time filters, and the crucial window-honesty caveat about undated receipts being excluded and reported in summary.undatedExcluded.

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

Conciseness5/5

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

The description is dense but every sentence earns its place. It uses clear signposts like 'ACCOUNTING EXPORT' and 'WINDOW HONESTY' to structure information, and the length is justified by the tool's complexity — covering purpose, columns, dedup, window logic, and caveats without redundant words.

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?

For a tool with 4 parameters, no output schema, and a subtle edge case (undated receipts), the description is remarkably complete. It explains the CSV columns, the pointer/chain trust model, dedup behavior, window filtering, the undatedExcluded counter, and gives a recovery instruction (re-run without window). This is fully actionable.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds meaningful semantics beyond property names: brand slugs the filename, receipts are expected to carry txHash, and the from/toBlockTime parameters are explained in terms of window filtering and the undated-exclusion behavior. This goes well beyond the schema's simple descriptions.

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?

The description clearly states the tool's function: turning verified receipts into an accountant-ready CSV for QuickBooks/Xero/Excel. It names the specific verb 'export' and the resource (receipts to CSV), and its emphasis on accounting/basescan distinctiveness sets it apart from sibling receipt and payment tools.

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?

It provides clear context for when to use: finance/accounting export needs, with a strong rationale ('pointer to the chain'). However, it does not explicitly name when not to use it or an alternative tool such as till_receipt or till_check_payment, so it stops short of the full 5.

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

All biii toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation3/5

Many tools have distinct, well-named purposes (vet_agent vs vet_merchant), but there is notable overlap between till_trust and till_vet_merchant (both provide trust verdicts), and till_launch_funder vs till_funder_history are closely related. The descriptions are detailed enough to differentiate, but an agent could still misselect between a few pairs.

Naming Consistency3/5

All tools share the till_ prefix, but the pattern is mixed: some use verb_noun (check_invoice, create_charge, watch_wallet) while others are noun phrases (key_exposure, open_approvals, rug_powers) or bare nouns (floor, trust, roll). This is readable but not predictable, so an agent cannot reliably guess a tool name from a verb.

Tool Count2/5

At 29 tools, this server exceeds the 25+ threshold that signals an overgrown toolkit. Even with a broad domain, many tools are one-off niche scanners (till_b20_authentic, till_floor, till_meter) that inflate the surface and could be consolidated or externalized.

Completeness4/5

The toolkit covers the payment lifecycle comprehensively: create charges/invoices, check payments, verify delivery, generate receipts, rolls, and accounting exports. It also spans identity, trust, security scanning, and theft tracing. Minor gaps exist (no update/cancel for charges, no token-general vetting), but the non-custodial, read-only design makes these acceptable.

Resources