Skip to main content
Glama

Split a row

purch_split_transaction

Say how one statement row breaks down: several categories that add up to it exactly. The row itself never changes. One line on a statement is often several things: a payroll run is wages, employer taxes and the processor's fee; a warehouse trip is supplies and groceries. The statement only knows the total, so the breakdown comes from the person or from a document they have — the payroll report, the receipt. Never invent the split; ask, or leave the row whole.

The legs must add to the row's amount exactly. They are refused otherwise, with the gap named, for the same reason a statement is: a breakdown that does not add up is a transcription error. The row keeps its amount, its date and the line it came from; only the ledger sees the legs, each posting to its own category against the account the money moved on. Pass remove to drop a split and put the row back to its single category. Effects: split legs recorded, replacing any earlier split.

Input Schema

NameRequiredDescriptionDefault
partsNoThe parts it breaks into. At least two, adding to the row exactly.
reasonNoWhere the breakdown came from — the payroll report, the receipt.
removeNoDrop the split and leave the row whole.
transaction_idYesThe row, e.g. T-0014.

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?

Beyond the annotations, the description discloses key behavior: the row's amount, date and source line are preserved; invalid legs are refused with the gap named; legs post to their own categories against the source account; and an existing split is replaced. This is unusually rich behavioral context for a mutation tool.

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?

The description is front-loaded with the core operation and ends with a clear 'Effects' line. It is somewhat narrative and includes illustrative examples and rationale, but the length is mostly justified by the behavioral details.

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 mutation tool with no output schema and only basic annotations, the description covers the important gaps: validation and refusal behavior, preservation of the original row, ledger-side effects, replacement of an earlier split, and how to remove a split.

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 coverage is 100%, so the schema already documents transaction_id, parts, reason and remove. The description reinforces the exact-sum constraint and explains where reason should come from, but it does not add much parameter syntax or format detail beyond the schema.

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: splitting one statement row into several category legs that add to the row exactly. It also clearly distinguishes the operation from simply editing or retagging the row by saying the row itself never changes and only the ledger sees the legs.

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 gives clear usage context: use this when one statement line is really several things, and get the breakdown from the person or a document rather than inventing it. It also covers the remove path. It does not explicitly name sibling alternatives, so it falls short of a 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.