Skip to main content
Glama

Taokeh MCP server

Pending draft: tick bank entries as cleared (human approves in Taokeh)

create_bank_clearing_draft

FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose the ticks for Banking → Clear transactions: which book entries have appeared on the bank statement, each paired with its statement line or given the date it cleared. An admin or bookkeeper reviews the list and approves; only that tap ticks them, exactly as the page's Save ticks does (a tick posts nothing to the books and the owner can un-tick it). Read bank_reconciliation_report first and take every id from it: bankAccountId, statementId (the statement you are reconciling to — or asOf, a date, when there is none), and per item entryId (from clearStep.uncleared) plus EITHER statementLineId (from clearStep.candidateLines — the entry then clears on the later of the line's date and its own) OR clearedDate (YYYY-MM-DD; omitted, it defaults to the reconciliation date, like the page). At most 300 items per draft. A cancelling pair from hints.cancellingPairs is filed as two items with no line and the pair's clearDate. REFUSED BY NAME when you file (Taokeh runs the real tick and rolls it back) and again at approval: an entry that is not uncleared on this account up to the date (posted from a statement line, the opening balance, already ticked, dated later), a line that is posted, fully paired or dated after the reconciliation date, a line without room left for the entry, a line moving money the other way, a cleared date before the entry was booked or after the reconciliation date, a date inside a locked period, a card, a foreign-currency account (Taokeh posts and reconciles only ringgit accounts for now; the refusal names the account), an entry already in another pending draft. If anything it was filed against changes before approval (a tick made, a line posted or paired, an entry edited), approval refuses and nothing is ticked — read the report again and file afresh. note: one short line for the owner saying why.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asOfNoReconcile to a date by hand (no statement). Give this OR statementId.
noteNoA SHORT note for the owner: why these are cleared.
itemsYesThe ticks. An unknown key in an item is refused by name.
notesNoNOT a filter on this tool. Pass the owner note as `note`.
ticksNoNOT a filter on this tool. Pass the ticks as `items`: [{entryId, statementLineId?, clearedDate?}].
bankIdNoNOT a filter on this tool. Pass the bank account as `bankAccountId`.
entriesNoNOT a filter on this tool. Pass the ticks as `items`: [{entryId, statementLineId?, clearedDate?}].
needsReviewNoSet true when something gave you pause.
statementIdNoThe statement you reconcile to, from bank_reconciliation_report `statement.id`. Give this OR asOf.
bankAccountIdYesREQUIRED — the bank account, from bank_reconciliation_report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations give only the generic readOnly=false/destructive=false/idempotent=false profile; the description adds substantial context beyond them: the draft-then-human-approval lifecycle, that a tick posts nothing to the books and is reversible ('the owner can un-tick it'), the exact refusal reasons at both filing and approval, and the invalidation rule ('If anything it was filed against changes before approval ... approval refuses and nothing is ticked'). This is far richer than the annotations.

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 critical constraint is front-loaded in caps, which is exactly right, and each sentence carries information. However, the prose is dense and run-on, packing the entire refusal taxonomy into a single sprawling sentence with nested parentheticals, which costs some scannability.

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 10-parameter, no-output-schema mutation tool, the description covers the full lifecycle: id sourcing, item construction, size limits, cancellation handling, refusal conditions, post-filing invalidation, and the owner note. Nothing an agent needs to file correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: entryId must come from clearStep.uncleared, statementLineId from clearStep.candidateLines, clearedDate defaults to the reconciliation date like the page, and statementId vs asOf are alternatives. It also clarifies that the decoy keys (notes, ticks, bankId, entries) are not filters and points to the correct parameter names.

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 precise verb+resource: it 'FILES A PENDING DRAFT' proposing ticks for Banking → Clear transactions, and immediately scopes the effect ('NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT'). It distinguishes itself from siblings by directing the agent to bank_reconciliation_report for ids and from update/revise tools by framing the output as a reviewable draft.

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?

It explicitly says to 'Read bank_reconciliation_report first and take every id from it' and specifies exactly which ids come from which sub-fields. It states when to use statementLineId versus clearedDate, the 300-item cap, and how cancelling pairs are filed. The refusal list names the conditions under which the tool will not accept a filing.

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