Skip to main content
Glama

Taokeh MCP server

by my.taokeh
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
memoNoWhat 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.
linesYesAt 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.
notesNoA 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.
entryDateYes
referenceNoYour own reference for the adjustment, if there is one (a schedule number, a working-paper ref).
clientTotalNoYour own arithmetic for the entry total — carried onto the review screen for the human to compare against, never used to compute anything.
needsReviewNo
attachmentBytesNoThe 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.
attachmentTokenNoThe token from request_attachment_upload, AFTER you have PUT the file bytes to its uploadUrl. Mutually exclusive with attachmentBase64.
attachmentBase64NoThe 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.
attachmentSha256NoThe SHA-256 of the ORIGINAL file as 64 hex chars — optional second check alongside attachmentBase64, so corrupted bytes are rejected instead of filed.
attachmentFilenameNoThe original filename, for the reviewer.
attachmentMediaTypeNoThe attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given. It must match the file's bytes — a mismatch is refused and nothing is filed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / attachmentMediaType / description
      Previous value: -"The attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given."New value: +"The attachment's MIME type, e.g. 'application/pdf'. Required when attachmentBase64 is given. It must match the file's bytes — a mismatch is refused and nothing is filed."
  2. Changed2 schema fields changed
    • 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
  3. Changed1 schema field changed
    • 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."
  4. Changed2 schema fields changed
    • 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"
+}
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a non-destructive write, but the description carries far more: it never posts to the ledger, only approval writes it, unbalanced entries are refused with the difference named, unknown account refs are refused and ambiguous ones report candidates, accounts are never auto-created, and control-account lines are flagged and require full in-app review. It also explains the no-edit/no-delete policy as deliberate, which is exactly the kind of context annotations cannot convey.

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?

Purpose and the negative scoping are front-loaded, and nearly every sentence carries operational content. It is long and heavy on all-caps emphasis, but for a 13-parameter tool with several hard failure modes the density is largely justified rather than padding.

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?

With 13 parameters, no output schema, and a non-trivial balancing and attachment workflow, the description covers everything an agent needs to call it correctly: the intake_contract prerequisite, the balance rule, the one-side-per-line rule, control-account review escalation, attachment transport fallbacks, and the correction path.

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; the description still adds real meaning by specifying that accountRef must come from the chart returned by intake_contract, that codes beat exact names, and that ambiguous names produce candidates. It also spells out the attachment exclusivity rule (token XOR base64, with attachmentBytes as a truncation check) beyond what the schema states.

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?

Opens with a specific verb+resource ('File an ADJUSTING JOURNAL ENTRY as a draft') and immediately scopes it to accountant's entries (accruals, depreciation, reclassifications, reversals). It explicitly distinguishes itself from the document-based siblings by naming create_bill_draft, create_invoice_draft, create_expense_draft and create_receipt_draft as the correct tools for anything with a real document.

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 when-to-use (accruals, prepayments, corrections), explicit when-NOT-to-use with the four alternative tools named, and a full alternative workflow for correcting posted entries (search_journal → reversing entry → correct entry). It also routes misfiled drafts to revise_draft rather than a duplicate file.

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 toolsInspect
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