Skip to main content
Glama

Build Lots

build_lots
Read-onlyIdempotent

Build the lot inventory per account and every disposal with basis, gain and holding period. PREMIUM (license).

Methods: fifo (the default rule when no specific identification is made, Treas. Reg. 1.1012-1(j)), lifo, hifo, or specific_id via a row's specific_lots {lot_id: qty}. Typical input {"ledger": , "method": "hifo", "transfers": } returns {"disposals": [{"row": "cb9", "asset": "BTC", "qty": "0.5", "proceeds": "31000.00", "basis": "20000.00", "gain": "11000.00", "term": "long", ...}], "open_lots": [...], "summary": {"short_term": {...}, "long_term": {...}}}. Fees: a cash purchase's fee joins basis; a sale's or exchange's fee reduces the amount realized (1.1001-7); a network fee paid in the transferred asset is a disposal of those units (transfer_fee_policy dispose) unless you choose ignore. Transfers between your own accounts move lots with their basis and acquisition date. Use once ledger_lint reports no errors. Not tax advice: it applies the stated rules to your rows and shows its work. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "method must be fifo, lifo, hifo or specific_id"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ledger": "<ledger>"
    },
    "name": "build_lots"
  }
}

Input Schema

NameRequiredDescriptionDefault
ledgerYescanonical rows.
methodNofifo, lifo, hifo or specific_id (rows without specific_lots fall back to fifo).fifo
tax_yearNowhen set, only disposals in that calendar year are returned (the inventory still runs from the start).
transfersNopairs from match_transfers ({"out": id, "in": id, ...}); empty to auto-match with the defaults.
on_missing_lotsNoerror (default), or zero_basis for lenient mode - disposals beyond the lots held get zero basis and unmatched transfer_out rows simply leave the inventory, each flagged.error
transfer_fee_policyNodispose (default) or ignore for network fees paid in the transferred asset.dispose

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context on top: PREMIUM licensing, fee treatment rules for purchases, sales, and network fees, transfer basis carry-over, and the crucial fact that it never raises a protocol error but returns an {"error":...} object, making retry-after-fix safe. That is exactly the behavioral detail 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?

Front-loads the core purpose in the first sentence, then layers methods, worked example, fee rules, and error contract in a logical order. It is dense and long, and the inline JSON example plus the fee discussion could be tightened, but nearly every sentence carries decision-relevant information.

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?

With an output schema present and 100% param coverage, the description still supplies workflow prerequisites, a concrete response shape, and error semantics. Nothing an agent needs to invoke it correctly, or to interpret a failure, is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: the Treasury Regulation basis for fifo as default, the specific_lots {lot_id: qty} shape for specific_id, and the meaning of transfer_fee_policy dispose vs ignore. It does not elaborate on tax_year or on_missing_lots beyond the schema text.

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 (Build) and resource (lot inventory) plus the outputs it produces: disposals with basis, gain, and holding period. It is clearly distinct from siblings like ledger_lint (validation), match_transfers (pairing), and form_8949_rows (reporting).

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?

Explicitly names the precondition 'Use once ledger_lint reports no errors', which tells the agent where this sits in the workflow, and explains when to choose specific_id over the automatic methods. It stops short of naming when NOT to use it or which sibling consumes its output (e.g. form_8949_rows).

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.