AgenticBooks

Confirm a suggested inter-bank transfer

confirm_transfer

Books a suggested match as ONE inter-bank transfer between the org's own accounts: debits the destination bank's cash account and credits the source bank's, with NO income or expense (+ a 6400 fee line when the received amount is short by a wire fee). Both legs leave the review queue and a ledger sync is re-queued. CROSS-CURRENCY and foreign-same-currency matches ARE supported: each leg is home-stamped at its own date's rate and the home residual (provider spread / timing) books to realized FX 6700. REFUSED pairs: same-currency with received > sent (cannot balance — reject it and classify the legs separately), and a cross-currency pair whose home amounts diverge past the plausibility bound (the residual would book as a phantom FX gain/loss) — that refusal opens an OOB APPROVAL REQUEST: your human gets an email and approves on the dashboard, at which point the transfer books automatically. accept_large_fx_residual NO LONGER bypasses the bound for agents — do not retry a refused confirm; watch the pending approval in your status tool. GUARDS (no bypass): the link must be one of YOUR org's suggested matches, and both legs are re-verified to belong to your org. actor_id is optional — it defaults to the organisation entity.

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
`link_id`	Yes	The suggested transfer link to confirm (from list_suggested_transfers).
`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.
`accept_large_fx_residual`	No	DEPRECATED (kept for wire-compat): agents can no longer bypass the FX-residual bound. Above it the tool opens an OOB approval request for your human regardless of this flag.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`link_id`	Yes
`confirmed`	Yes
`dest_cash`	Yes
`source_cash`	Yes
`ledger_sync_queued`	Yes
`booked_classified_event_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only state readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description goes far beyond this: it details the exact ledger effects, fee handling, cross-currency FX residual booking, the OOB approval flow, the deprecation of accept_large_fx_residual for agents, and the org-verification guards. This is rich behavioral disclosure that the annotations do not convey.

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 long but tightly packed with essential operational details, structured into clear thematic blocks (REFUSED pairs, GUARDS). Every sentence carries behavioral significance given the tool's complexity. It is front-loaded with the core action and then layers edge cases, so an agent can quickly grasp the primary use before diving into exceptions.

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 4 parameters, an output schema, and minimal annotations, the description covers all necessary invocation aspects: success behavior, fee handling, cross-currency logic, refusal paths, OOB approval, guardrails, and parameter defaults. The existence of an output schema covers return-value details, so nothing an agent needs to call the tool correctly is missing.

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% and each parameter already has a description. The tool description adds meaningful nuance for accept_large_fx_residual by explaining it is deprecated and no longer bypasses the bound, and it reinforces the defaults for org_id and actor_id. While not exhaustive per-parameter, it enriches the schema without redundancy.

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 opens with a precise verb-resource pair: 'Books a suggested match as ONE inter-bank transfer', and elaborates with concrete mechanics (debits destination, credits source, fee line, queue removal). It clearly distinguishes the confirm action from siblings like reject_transfer by describing the booking behavior, not just restating the name.

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 provides strong contextual guidance on when to use the tool (confirm a suggested match) and when not to ('REFUSED pairs... do not retry a refused confirm'), and it points to the status tool for pending approvals. However, it does not explicitly name the alternative reject_transfer for refused cases, leaving 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.

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?