AgenticBooks

Re-point a counterparty rule at a different account

update_counterparty_rule

Idempotent

Changes the target account of an existing counterparty rule. This affects FUTURE classification only: events already booked from this counterparty are NOT re-categorised or re-synced — only events classified after this change use the new account. Writes an audit entry recording the before/after account. Idempotent: setting the account it already has is a no-op. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`org_id`	No	Optional. Defaults to the organisation the authenticated API key is bound to, so you normally omit it and never need to ask the user for their organisation UUID. If provided, it must match the key’s org or the request is rejected.	0e91146d-511c-469f-bdee-5c867b26ae0d
`reason`	Yes	Why the new account is correct. Stored verbatim in the audit trail.
`rule_id`	Yes	The rule_id from list_counterparty_rules.
`actor_id`	No	Optional. Defaults to the organisation entity (correct for an org-scoped key). If provided, it must be an entity belonging to this organisation — arbitrary UUIDs are rejected, so the audit trail cannot be attributed to someone else.
`approved_category`	Yes	The new account future events from this counterparty are classified as: a numeric chart code (4000 SaaS Revenue, 4100 Usage Revenue, 4900 Other Income, 5000 API & Compute Costs, 5100 Payment Processing Fees, 5200 Platform Commission, 6100 Software Subscriptions, 6200 Contractor & Freelancer, 6300 Marketing & Ads, 6400 Banking & Finance Fees, 6500 Payroll, 6600 Taxes, 6700 Foreign Exchange Gain/Loss, 6750 Unrealized FX Gain/Loss, 6800 Office & Equipment, 6810 Travel, 6820 Meals & Entertainment, 6830 Professional Services, 6840 Insurance, 6900 Other Expenses, 2100 Accounts Payable, 3900 Owner Contributions & Transfers, 1100 Cash & Bank, 1150 Stripe Receivable, 1160 App Store / Play Receivable, 1200 Stripe Settlement) or a rollup category (revenue → 4000, cost_of_goods → 5000, operating_expense → 6100).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rule_id`	Yes
`category`	Yes
`direction`	Yes
`account_code`	Yes
`counterparty_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds significant behavioral context beyond annotations: future-only classification, no re-categorisation of booked events, audit trail side effect, and idempotence as a no-op. These details are essential for an agent to understand the tool's real-world effects and are not conveyed by the annotations alone.

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?

The description is information-dense and front-loaded with the core action, then efficiently covers key side effects and edge cases. Every sentence contributes unique behavioral or param guidance, with no filler or repetition.

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% parameter coverage, the description adds all necessary behavioral context: side effects, scope, idempotence, and actor defaults. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so the schema fully explains all five parameters. The description adds no parameter meaning beyond what the schema already provides; it merely restates actor_id's optionality and org-binding, which is already documented.

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 the specific verb ('Changes') and resource ('target account of an existing counterparty rule'), making it immediately distinct from create_counterparty_rule and delete_counterparty_rule. The title further reinforces the re-pointing action without ambiguity.

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?

Clearly implies this is for modifying an existing rule's target account and not for creating or deleting rules. It does not explicitly name alternatives or provide when-not-to-use scenarios, but the context is clear enough for an agent to select it correctly.

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

All AgenticBooks 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?