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 or foreign-currency 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.7/5.0
Behavior5/5

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

The description goes well beyond annotations: it prominently states 'FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH', explains that 'a tick posts nothing', details refusal conditions by name, notes re-approval failure if underlying data changes, and clarifies defaults such as clearedDate. This is rich behavioral context that no structured field provides.

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 every sentence carries essential information for a safety-sensitive, multi-parameter operation. It is front-loaded with the most critical warning. It could be improved with bullet points or shorter paragraph breaks, but the density is justified by the complexity of the tool.

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 tool with 10 parameters, intricate refusal logic, and an implicit human approval workflow, the description covers all operational aspects: required inputs and their sources, pairing rules, defaults, limitations, failure conditions, and post-submission behavior. Nothing essential is left to inference, making it highly complete.

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?

Despite 100% schema description coverage, the description adds critical semantic value: source of each id (bank_reconciliation_report, clearStep.uncleared, clearStep.candidateLines), exclusive usage of statementId vs asOf, default behavior of clearedDate, the 300-item limit, handling of cancelling pairs, and explicit warnings about unknown keys. This is far more than the schema descriptions offer.

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 specific verb ('file a pending draft'), a concrete resource ('bank clearing draft'), and the exact domain ('Banking → Clear transactions'). It clearly differentiates itself from the other create_*_draft siblings by focusing on bank clearing ticks and emphasizing that nothing changes until human approval.

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?

The description gives strong workflow guidance: 'Read bank_reconciliation_report first and take every id from it' and 'read the report again and file afresh' if something changes. It does not explicitly list alternative tools or when not to use it, but the prerequisite and the detailed steps sufficiently orient an agent. One small gap is not naming a sibling to avoid (e.g., bank_reconciliation_status), so a 4 is appropriate.

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