Skip to main content
Glama

Conecto Bookkeeping

Add or change a tax

books_save_tax
Idempotent

A tax rate the books use (VAT, GST, sales tax), matched by name. Tax charged on sales is owed on sales_account (default: the sales tax account); tax paid on purchases is reclaimed on purchase_account (default: the tax to reclaim account; null when it can't be reclaimed, and it stays part of the cost). A rate in use can't change: add a new tax and archive the old one. Invoices make the taxes they need on their own. kind makes a new tax one the business owes itself, like Xero's reverse charge rates: rc_eu (services from another EU country), rc_abroad (from outside it), rc_home (reverse charge at home) or eu_goods (goods from another EU country); on an expense or a bank line it books the VAT owed and reclaimed at once, the amount paid being without VAT. kind import is import VAT paid at customs, no rate: what is booked with it is the VAT itself, reclaimed whole on the import VAT account (1310, made with it), where an expense or a bank line counts with no tax named (box 62 in Germany, box 4 in the UK). Conecto gives no tax advice; the rates are the business's. Costs $0.001 per call; nothing if it fails.

Input Schema

NameRequiredDescriptionDefault
kindNoFor a new tax: VAT the business owes itself, or import VAT.
nameYes
rateNoPercent, e.g. 19.
archivedNo
new_nameNo
sales_accountNoAn account code from the chart, e.g. "6600".
purchase_accountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare non-read-only, idempotent, non-destructive; the description adds material context beyond them, including default account codes, that purchase_account is null when VAT is unreclaimable and then stays in cost, the immutability of in-use rates, and per-call pricing with no charge on failure. It does not contradict the hints — archiving is a reversible state change, not the destructive deletion the hint denies.

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 body is a dense semicolon-chained run-on that mixes tax doctrine, enum semantics, default accounts, and pricing into one paragraph. Every clause is informative, yet the lack of structure forces the agent to parse a wall of text to extract the operational bits.

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

Completeness3/5

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

For a 7-parameter mutation tool with no output schema, the description covers the accounting semantics unusually well, but omits the meaning of new_name (the only way to rename a tax) and never indicates what the call returns on success. Those gaps sit on the two parameters an agent most needs to disambiguate when updating rather than creating.

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?

With only 43% schema coverage, the description does heavy lifting for kind (expanding all five enum values with reverse-charge and import-VAT behavior), sales_account, and purchase_account defaults/nulls. However, new_name is never mentioned at all and archived is only alluded to via 'archive the old one', while name and rate are left entirely to the schema — so it compensates unevenly rather than fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title 'Add or change a tax' plus the opening clause 'A tax rate the books use (VAT, GST, sales tax), matched by name' make the resource and the create-or-update action clear. It does not need sibling differentiation because there is no other tax-rate tool in the sibling list, but the description itself never states the verb directly, leaving the action to be inferred from title + body.

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 real usage rules: 'A rate in use can't change: add a new tax and archive the old one' tells the agent the correct two-step workflow, and 'Invoices make the taxes they need on their own' warns against pre-creating rates. 'Conecto gives no tax advice' scopes responsibility. No alternative tool is named, but no equivalent sibling exists to route to.

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.

Resources