Taokeh MCP server

Import bank statement into the review queue (nothing posts)

import_bank_statement

Import a bank statement into Taokeh for reconciliation, from a statement you've read (PDF/CSV/image). This does NOT post to the books — every row lands in Banking → Review for the user to categorize and post line by line. A statement is the bank's own list of transactions for ONE account over a period: use intake_contract(doc_type:'statement') first to see the tenant's bank accounts + the arithmetic law. Give the account id, the printed opening + closing balances, the printed statement date (statementDate) and beginning-balance date (beginningBalanceDate) when the statement shows them, and every transaction row (signed amount: + money in, − money out). The server checks opening + the rows tie to the closing balance and rejects with the exact delta if they don't — never invent or omit rows to force it to balance. CREDIT CARDS: a card statement can be filed here too, but ONLY with signConvention declared, because a card prints the opposite convention (a purchase INCREASES what you owe). Pass 'PRINTED_CARD' when the figures are exactly as the card statement prints them (the usual case) or 'STORED' if you deliberately converted them to Taokeh's convention (− = a spend). Never guess: declaring the wrong one books the whole month backwards and the arithmetic check cannot catch it, because negating every figure still ties out — the server runs a separate directional check and refuses a declaration that reads as a card which never owed anything. signConvention is refused on a bank account. Each card line is then expensed on its OWN statement date against the card, and the "payment received" line that settles the card bill is excluded automatically (the bank statement's lump owns that movement). Single receipts, invoices or bills go through their own draft doors, not here. ARCHIVING THE ORIGINAL: this import archives the statement file WHEN you send one — call request_attachment_upload FIRST, PUT the statement's raw bytes to its uploadUrl, then pass the returned attachmentToken here; the original is then kept on the statement (s.82 record-keeping) and the user can download it from the statement page, exactly as the web upload at Banking → Import does. Without a token nothing is archived and the books carry rows with no source document behind them. Already filed one bare? Call this tool AGAIN with the IDENTICAL account, balances and rows plus attachmentToken — the identical reading matches the same statement, so the file is ADOPTED onto it and no rows are staged twice. Filed one before without statementDate / beginningBalanceDate? The same identical call with the two dates added records them on that statement, again staging nothing twice.

Input Schema

TableJSON Schema

Name	Required	Description
`rows`	Yes
`bankAccountId`	Yes
`statementDate`	No	The statement date printed on the statement (the ENDING BALANCE date), YYYY-MM-DD — it is the end of the period the statement covers, even when the last transaction is earlier. Omit it only if the statement prints none.
`closingBalance`	Yes
`confirmOverlap`	No	Set to true ONLY after the user has confirmed this is a genuinely new, separate statement whose period overlaps one already imported. It bypasses the overlap guard that stops the same transactions being counted twice. Never set it to push an overlap through — ask the user first.
`openingBalance`	Yes
`signConvention`	No	REQUIRED when bankAccountId is a CREDIT CARD, and refused on a bank account. Which convention you signed the rows AND the opening/closing balances in. 'PRINTED_CARD' = exactly as the card statement prints them: a purchase is POSITIVE (what you owe goes up), a payment or refund is NEGATIVE, and the balances are the printed balances owed — this is the right choice when you read the card's own statement. 'STORED' = already converted to Taokeh's stored convention: a spend is NEGATIVE, a payment or refund POSITIVE, and the balances negative while money is owed. Do not guess between them: the wrong declaration books the entire month backwards, and the arithmetic check cannot catch it because negating every figure still ties out. Ask the user if unsure.
`attachmentBytes`	No	The decoded byte size of the ORIGINAL file on disk — send it alongside attachmentBase64 and the server rejects a truncated paste instead of filing a corrupt file.
`attachmentToken`	No	The token from request_attachment_upload, AFTER you have PUT the statement bytes to its uploadUrl. This is the normal way to archive a statement PDF — it carries the file out-of-band (no base64 in this call). Mutually exclusive with attachmentBase64. The file is archived on the statement and the user downloads it from the statement page in Taokeh.
`attachmentBase64`	No	The ORIGINAL statement as base64 — SMALL files only (a few KB). A real bank statement PDF is never that small, so in practice use request_attachment_upload + attachmentToken instead. Mutually exclusive with attachmentToken. A bad type/oversize file is rejected and NOTHING is imported.
`attachmentSha256`	No	The SHA-256 of the ORIGINAL file as 64 hex chars — optional second check alongside attachmentBase64, so corrupted bytes are rejected instead of filed.
`attachmentFilename`	No	The original filename, for the user browsing their statements.
`attachmentMediaType`	No	The attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given.
`beginningBalanceDate`	No	The date on the BEGINNING (opening) BALANCE line, YYYY-MM-DD — the start of the period. Every row must fall between it and statementDate. Omit it only if the statement prints none.
`confirmSignConvention`	No	Set true ONLY after the user confirms that the card genuinely sat in CREDIT for the whole period. It bypasses the directional check that refuses a statement reading as a card which never owed anything — the usual cause of which is a printed statement declared 'STORED' (or the reverse). Never set it to push a refusal through: ask the user first.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 25, 2026

addedInput schema / properties / beginningBalanceDate

Added value: +{
+  "description": "The date on the BEGINNING (opening) BALANCE line, YYYY-MM-DD — the start of the period. Every row must fall between it and statementDate. Omit it only if the statement prints none.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / statementDate

Added value: +{
+  "description": "The statement date printed on the statement (the ENDING BALANCE date), YYYY-MM-DD — it is the end of the period the statement covers, even when the last transaction is earlier. Omit it only if the statement prints none.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

Changed2 schema fields changedAug 25, 2026

addedInput schema / properties / confirmSignConvention

Added value: +{
+  "description": "Set true ONLY after the user confirms that the card genuinely sat in CREDIT for the whole period. It bypasses the directional check that refuses a statement reading as a card which never owed anything — the usual cause of which is a printed statement declared 'STORED' (or the reverse). Never set it to push a refusal through: ask the user first.",
+  "type": "boolean"
+}

addedInput schema / properties / signConvention

Added value: +{
+  "description": "REQUIRED when bankAccountId is a CREDIT CARD, and refused on a bank account. Which convention you signed the rows AND the opening/closing balances in. 'PRINTED_CARD' = exactly as the card statement prints them: a purchase is POSITIVE (what you owe goes up), a payment or refund is NEGATIVE, and the balances are the printed balances owed — this is the right choice when you read the card's own statement. 'STORED' = already converted to Taokeh's stored convention: a spend is NEGATIVE, a payment or refund POSITIVE, and the balances negative while money is owed. Do not guess between them: the wrong declaration books the entire month backwards, and the arithmetic check cannot catch it because negating every figure still ties out. Ask the user if unsure.",
+  "enum": [
+    "PRINTED_CARD",
+    "STORED"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedAug 25, 2026

addedInput schema / properties / attachmentBytes

Added value: +{
+  "description": "The decoded byte size of the ORIGINAL file on disk — send it alongside attachmentBase64 and the server rejects a truncated paste instead of filing a corrupt file.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / attachmentSha256

Added value: +{
+  "description": "The SHA-256 of the ORIGINAL file as 64 hex chars — optional second check alongside attachmentBase64, so corrupted bytes are rejected instead of filed.",
+  "type": "string"
+}

Changed4 schema fields changedAug 18, 2026

addedInput schema / properties / attachmentBase64

Added value: +{
+  "description": "The ORIGINAL statement as base64 — SMALL files only (a few KB). A real bank statement PDF is never that small, so in practice use request_attachment_upload + attachmentToken instead. Mutually exclusive with attachmentToken. A bad type/oversize file is rejected and NOTHING is imported.",
+  "type": "string"
+}

addedInput schema / properties / attachmentFilename

Added value: +{
+  "description": "The original filename, for the user browsing their statements.",
+  "type": "string"
+}

addedInput schema / properties / attachmentMediaType

Added value: +{
+  "description": "The attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given.",
+  "type": "string"
+}

addedInput schema / properties / attachmentToken

Added value: +{
+  "description": "The token from request_attachment_upload, AFTER you have PUT the statement bytes to its uploadUrl. This is the normal way to archive a statement PDF — it carries the file out-of-band (no base64 in this call). Mutually exclusive with attachmentBase64. The file is archived on the statement and the user downloads it from the statement page in Taokeh.",
+  "type": "string"
+}

First observedAug 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations are all neutral false values (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), so the description carries the full disclosure burden and discharges it thoroughly: the non-posting review-queue landing, the server's balance check that 'rejects with the exact delta,' the card directional check, automatic exclusion of the payment-settlement line, and the archiving/adoption behavior of repeated calls. It even discloses consequences ('declaring the wrong one books the whole month backwards') and what happens without a token ('nothing is archived').

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?

Long, but front-loaded: the first sentence states the purpose and the second the non-posting guarantee, with subsequent paragraphs organized topically (core rules, credit cards, archiving, re-calls) and no filler. Some repetition with the schema's own parameter descriptions (e.g., signConvention) exists, but the density is justified by the tool's complexity and hazard profile.

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

Completeness4/5

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

For a 15-parameter, 4-required import tool with no output schema, the description covers prerequisites, sequencing, edge cases (cards, overlap), failure modes (balance delta, directional refusal), and idempotent re-call behavior. The only notable gap is that it never describes the response/return value, which matters more given the absence of an output schema.

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 description coverage is 73%, above the high bar, so the baseline is 3; the description still adds meaning the schema lacks: the signed-amount convention (+ money in, − money out), the invariant that opening + rows must tie to closing, and the effect of signConvention on the directional check. It also explains that attachmentToken must come from request_attachment_upload and that identical re-calls adopt the file, enriching several parameters at once.

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 a specific verb and resource — 'Import a bank statement into Taokeh for reconciliation' — and immediately scopes what it is not: 'This does NOT post to the books — every row lands in Banking → Review.' It differentiates from siblings by routing single receipts/invoices/bills to 'their own draft doors,' and the title's '(nothing posts)' qualifier is reinforced throughout.

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?

Gives explicit sequential prerequisites: 'use intake_contract(doc_type:'statement') first' to see the tenant's bank accounts and the arithmetic law, and 'call request_attachment_upload FIRST' before archiving. It names exclusions with alternatives ('Single receipts, invoices or bills go through their own draft doors, not here') and specifies exact re-call conditions where identical parameters adopt a file without double-staging.

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

All Taokeh MCP server 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?