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. Dates show when Glama detected each change.

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.8/5.0

Behavior5/5

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

Annotations only supply shallow signals (readOnlyHint=false, destructiveHint=false, etc.), and the description adds rich behavioral truth far beyond them: the draft does NOT post to the books, an unbalanced entry is refused with the difference named, an unknown account ref is refused, and 'THIS TOOL NEVER CREATES AN ACCOUNT'. It also discloses the deliberate never-edit/never-delete posted history policy and the approval restriction for flagged control accounts - exactly the behavioral context an agent needs and annotations cannot 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 structured into clearly distinct concerns - non-posting behavior, balance rule, account matching, reversing workflow, control accounts, exclusions, attachments - with the core purpose front-loaded in the first sentence. Every paragraph addresses a failure mode or policy constraint an agent would otherwise encounter; only the ledger-integrity philosophy explanation runs slightly long.

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 13-parameter accounting tool with no output schema, the description covers the full decision surface: what it files, what it refuses, how approval works, integration with intake_contract/search_journal/revise_draft/request_attachment_upload, and edge cases (truncated attachments, ambiguous account names, unreachable host). Nothing an agent needs to invoke it 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 85%, so the baseline is 3 and the schema already documents each parameter thoroughly. The description adds decision heuristics beyond the schema: the attachmentToken-vs-attachmentBase64 choice ('Prefer request_attachment_upload... if your shell cannot reach taokeh.my'), the rule that attachmentBytes must always accompany base64 to reject truncated pastes, and guidance on what `notes` should contain for control lines and doubts.

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: 'File an ADJUSTING JOURNAL ENTRY as a draft', and immediately carves out the core differentiator: 'the accountant's entry, not a document'. It also enumerates the exact use cases (accruals, prepayments, depreciation, corrections, reclassifications, year-end, reversing entries), leaving no ambiguity about what this tool is for.

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?

Provides an explicit 'WHAT NOT TO USE THIS FOR' section that names the exact sibling to pick instead: create_bill_draft, create_invoice_draft, create_expense_draft, create_receipt_draft. It also chains the workflow instruction - use intake_contract for the chart of accounts, search_journal to locate a posted error, revise_draft to fix a wrongly filed draft - so the agent knows exactly when this tool is and is not the right call.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?