stub

Create income expenses bulk

create_income_expenses_bulk

Create many income and expense records in one transaction — prefer this over repeated save_income / save_expense calls. Optional top-level transactionid links every record to that bank transaction; a per-item transactionid overrides it. An expense accountid set to a purchase document's id (cont-…) records it as a payment against that bill. All-or-nothing; per-item salestax is not supported (use save_expense). Returns the new ids.

Input Schema

Name	Required	Description	Default
`income`	No
`expenses`	No
`transactionid`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

changedInput schema / properties / expenses / items / properties / accountid / description

Previous value: -"Chart-of-accounts category account id, or an exact account name to resolve (see list_accounts). Set to a bill / purchase order / GRN document id (cont-…) to record this expense as a payment against that document."New value: +"Chart-of-accounts category account id, or an exact account name to resolve (see list_accounts). Set to a bill / purchase order / GRN document id (cont-…) to record this expense as a payment against that document. Set to a customer id (cli-…) to record a refund paid to that customer: it posts once to Receivables, tagged to the customer, with no VAT, and draws down their credit balance."

changedInput schema / properties / income / items / properties / accountid / description

Previous value: -"Chart-of-accounts income category account id, or an exact account name to resolve (see list_accounts)."New value: +"Chart-of-accounts income category account id, or an exact account name to resolve (see list_accounts). Set to a supplier id (sup-…) to record a refund paid by that supplier: it posts once to Payables, tagged to the supplier, with no VAT, and draws down the credit they owe."

Changed1 schema field changedSep 29, 2026

addedInput schema / properties / expenses / items / properties / total

Added value: +{
+  "description": "Total including quantity. Used only when amount is omitted: amount becomes total ÷ quantity, and must come to whole cents. If amount is also sent, amount wins.",
+  "type": "number"
+}

First observedSep 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the readOnly/destructive annotations by disclosing all-or-nothing transaction semantics, the top-level transactionid inheritance with per-item override, the special meaning of an expense accountid pointing at a cont-… purchase document, and that the new ids are returned. The only missing behavior is any bound on how many records a single call accepts.

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?

Five dense sentences, each carrying distinct operational information — preference, transactionid inheritance, document-payment special case, atomicity, and the salestax exclusion — with the primary use case front-loaded and zero filler.

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?

With no output schema the description correctly closes the loop by stating it returns the new ids, and it covers atomicity and the notable id-overloading cases. What remains unstated is any batch-size limit or what happens when an array is empty, which matters for a tool whose whole premise is 'many'.

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?

Top-level schema coverage is 0% (income, expenses and transactionid have no schema descriptions), though the nested item properties are documented in detail. The description compensates for the most important gap by explaining that the top-level transactionid is inherited by every record unless a per-item value overrides it, but it never explains the shape or per-entry requirements of the income and expenses arrays themselves.

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 and resource with scope ('Create many income and expense records in one transaction') and immediately distinguishes itself from the one-at-a-time siblings save_income and save_expense. An agent can decide between bulk and single-record creation without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to prefer this over repeated save_income / save_expense calls, and names the one case where it must NOT be used ('per-item salestax is not supported (use save_expense)'), routing the agent to the correct alternative with the selecting condition.

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

All stub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?