Taokeh MCP server

File adjusting journal draft

create_journal_draft

File an ADJUSTING JOURNAL ENTRY as a draft in Taokeh — the accountant's entry, not a document: accruals, prepayments, depreciation, corrections, reclassifications, year-end adjustments, and REVERSING entries. This does NOT post to the books: it creates a pending draft with the debits and the credits laid out for the user to see, and only their approval writes it to the ledger. Shape the fields with intake_contract(doc_type:'journal') first — it returns this company's REAL chart of accounts, which is what every accountRef must match. IT MUST BALANCE TO THE SEN: debits equal credits or the draft is refused, with the difference named. Each line carries exactly one side (debit OR credit), and at least two lines are required. Accounts are matched by CODE (best) or by their exact name; an unknown ref is refused and an ambiguous name reports the candidates rather than picking. THIS TOOL NEVER CREATES AN ACCOUNT — if the adjustment needs one that does not exist, tell the user to add it in Taokeh and file again. FIXING A WRONG ENTRY THAT IS ALREADY POSTED: file a REVERSING entry here. Taokeh's connector never edits and never deletes posted history — that is deliberate and it is the point: a ledger you can rewrite is not a ledger, and every entry must stay auditable. So find the wrong entry with search_journal, file a reversing journal dated today (its debits become credits and its credits become debits, same accounts, same amounts), then file the correct entry. Tell the user plainly that this is what you are doing and why, rather than reporting that you 'cannot' fix it. CONTROL ACCOUNTS ARE ALLOWED BUT NEVER SILENT: a line on accounts receivable, accounts payable, inventory, the SST control or opening-balance equity is reconciled to a subledger, so a journal there moves the control with no document behind it and the aging-vs-control tie-out will show the difference. Such a draft is filed and flagged — it can be approved ONLY on its full review page in Taokeh, never by a one-tap email approval or a deck swipe. Say in notes why the control line is right. WHAT NOT TO USE THIS FOR: anything that has a real document. A supplier bill is create_bill_draft, a sale is create_invoice_draft, a paid expense is create_expense_draft, a customer payment is create_receipt_draft. Those carry party, SST and stock consequences a raw journal silently skips. Attach the WORKING PAPER you read the adjustment off — the depreciation schedule, the accrual computation, the bank letter. It rides the draft and the approver sees it beside your figures. Prefer request_attachment_upload → attachmentToken; if your shell cannot reach taokeh.my (a sandboxed client behind a network allowlist) send attachmentBase64 + attachmentMediaType inline instead — correct even for a full PDF — always with attachmentBytes, the file’s decoded size on disk, so a truncated paste is rejected instead of filed. Never both. Set needsReview and add a SHORT reviewer note in notes for any doubt. Filed it wrong? Use revise_draft (kind: 'journal') rather than filing a second one.

Input Schema

TableJSON Schema

Name	Required	Description
`memo`	No	What the entry is FOR, in one line — "accrue December electricity", "reverse the duplicated August rent". It prints on the entry and is the first thing the approver reads.
`lines`	Yes	At least two lines. The debits must equal the credits TO THE SEN — an unbalanced entry is refused with the difference named. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed.
`notes`	No	A SHORT reviewer note: one or two plain sentences, in the reviewer's language, naming what the human should double-check before approving — which schedule the figure came from, which entry this reverses, why a control-account line is right. Not lengthy reasoning.
`entryDate`	Yes
`reference`	No	Your own reference for the adjustment, if there is one (a schedule number, a working-paper ref).
`clientTotal`	No	Your own arithmetic for the entry total — carried onto the review screen for the human to compare against, never used to compute anything.
`needsReview`	No
`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 file bytes to its uploadUrl. Mutually exclusive with attachmentBase64.
`attachmentBase64`	No	The supporting WORKING PAPER as base64 — SMALL files only. For a real schedule or a multi-page PDF use request_attachment_upload instead (attachmentToken). A bad type/oversize file is rejected and NOTHING is filed.
`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 reviewer.
`attachmentMediaType`	No	The attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 9, 2026

changedInput schema / properties / lines / description

Previous value: -"At least two lines. The debits must equal the credits TO THE SEN — an unbalanced entry is refused with the difference named."New value: +"At least two lines. The debits must equal the credits TO THE SEN — an unbalanced entry is refused with the difference named. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."

addedInput schema / properties / lines / items / additionalProperties
```
Added value: +false
```

Changed1 schema field changedSep 4, 2026

changedInput schema / properties / lines / items / properties / accountRef / description

Previous value: -"The account CODE from this workspace's chart (best), or its EXACT name. Never a description and never a guess — an unknown ref is refused, and this tool never creates an account."New value: +"The account CODE from this company's chart (best), or its EXACT name. Never a description and never a guess — an unknown ref is refused, and this tool never creates an account."

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"
+}

AddedAug 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations are sparse (all false), so the description carries the full burden — and it delivers richly. It discloses that the tool does NOT post to the books, that drafts must balance to the sen or be refused, that accounts are matched by code/exact name, that unknown refs are refused, that ambiguous names are reported rather than picked, that the tool never creates an account, and that posted history is never edited or deleted by design. This goes far beyond what annotations express.

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 it is organized into clearly scoped sections and every sentence carries operational meaning for a complex, high-stakes financial action. The core semantics are front-loaded in the first sentence, and the rest is structured around balancing rules, control accounts, exclusions, attachment handling, and correction workflow. It is dense rather than padded, though a slightly tighter organization would improve 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 tool with 13 parameters, no output schema, and zero clue-giving annotations, the description is unusually complete. It covers entry behavior, balancing constraints, account matching rules, control-account approval consequences, attachment handling with fallbacks, revision via revise_draft, and explicit alternatives. An agent has enough context to invoke the tool correctly in both normal and edge-case scenarios.

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 high at 85%, but the description adds significant meaning beyond the schema: accountRef should be a chart-of-accounts code or exact name, never a guess; lines must carry exactly one side and at least two lines are required; attachmentToken and attachmentBase64 paths are mutually exclusive with conditions on reachability of taokeh.my; attachmentBytes should be the decoded on-disk size to reject truncated uploads; notes should be a short reviewer note, not lengthy reasoning. This is exactly the kind of parameter-level context an agent needs.

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 specific verb and resource: 'File an ADJUSTING JOURNAL ENTRY as a draft in Taokeh — the accountant's entry, not a document.' It immediately distinguishes the tool from document-based entry tools and lists the exact use cases (accruals, prepayments, depreciation, corrections, reclassifications, year-end adjustments, reversing entries). An agent cannot mistake this for create_bill_draft or create_invoice_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?

The description gives explicit when-to-use guidance and names sibling alternatives with conditions: 'WHAT NOT TO USE THIS FOR: anything that has a real document. A supplier bill is create_bill_draft, a sale is create_invoice_draft...' It also prescribes the reversing-entry workflow with search_journal, and tells the agent to say plainly what it is doing rather than reporting it 'cannot' fix an entry.

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?