Skip to main content
Glama

Review

purch_review_transaction

Say what a row is — purchase, recurring, transfer, income, fee, ignored — with a category, a vendor and a reason. Amount and date never change. A reasoned act (P-5). Read purch_vocabulary first and propose from the person's own categories and vendors. purchase is one-off spending; recurring is spending that repeats (rent, streaming, insurance) — name the vendor and the subscription is declared for you, then confirmed month by month (P-6). A transfer is money moving between the person's own accounts (card payoffs, brokerage, savings, an owner draw): give it a category saying WHERE it went, so the ledger's bank balance still ties to the statement. Leave that blank only when the money is already recorded elsewhere in these books, such as a client payment against an invoice you issued; those rows are then listed as not posted rather than counted twice. A fee is the bank's charge; income is money in; ignored is a row that is not theirs to track. Never alter the amount or the date — a wrong row means a wrong source, re-read and re-imported. Effects: status, category, vendor, note recorded; subscription declared for a recurring row with a vendor.

Input Schema

NameRequiredDescriptionDefault
noteNoAnything the person said about it.
reasonNoWhy — part of the record.
statusYesWhat it is.
vendorNoThe vendor's proper name; the row's description becomes its alias. Required for recurring.
cadenceNoFor recurring: how often. Defaults to monthly.
categoryNoThe person's own word for it (groceries, software, travel). Empty beats guessed.
claim_refNoThe expense report or claim it went on, if any.
transaction_idYesThe row, e.g. T-0012.
reimbursable_byNoA work expense someone pays back: who ("Acme Corp, expenses"). Clear it with an empty value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses important effects: status, category, vendor, and note are recorded, and recurring rows can declare a subscription. It also states a strong invariant that amount and date never change, and explains the downstream handling of transfers with blank categories. It does not discuss idempotency behavior, return values, or permission requirements, but it adds substantial behavioral context.

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

Conciseness3/5

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

The core purpose is front-loaded, but the description is a dense paragraph and includes references like P-5 and P-6 that are not explained. The status guidance is valuable, but the length and lack of structure make it less efficient than it could be for a nine-parameter mutation tool.

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

Completeness4/5

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

The description covers the main behavioral contract, including status meanings, prerequisites, effects, and the invariant that amount and date must not change. Because there is no output schema, the absence of return-value details is a gap, but the effects summary partially compensates. For a complex review operation, it is largely complete.

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 the schema already documents all nine parameters. The description still adds meaningful semantic guidance for status choices, vendor handling for recurring rows, and category behavior for transfers. It adds less value for parameters such as claim_ref and reimbursable_by, but overall it exceeds the baseline expected when the schema is fully described.

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 states a specific verb and resource: classify a transaction row by status, with category, vendor, and reason. It enumerates the status values and makes clear that this is a single-row review action, so the agent can understand the operation without opening the schema. It could distinguish itself more explicitly from reviewed-batch variants, but the purpose itself is clear.

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?

The description gives explicit prerequisite guidance to read purch_vocabulary first and to propose from the person's own categories and vendors. It also explains how to choose among statuses such as purchase, recurring, transfer, fee, income, and ignored. It does not explicitly name when to use this tool versus sibling tools like purch_review_batch, which leaves some routing inference to the agent.

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.