Skip to main content
Glama

Taokeh MCP server

Expense accounts

expense_accounts
Read-only

The expense accounts you can post to in this company — pick a category (what the money was for) and a paid-from account (where it came from) by code, for shaping a paid-expense draft. expenseCategories is a CURATED list: expense and asset accounts only, with cash/bank, the A/R and Inventory controls and contra accounts left out, because a cost never lands in one of those — and without the accounts only Taokeh's own engines book to (depreciation, foreign-exchange losses, loss on disposal, cash rounding, and salaries/employer statutory once the company runs payroll in Taokeh). It is the everyday set, not the whole rule. When the draft is filed, a CATEGORY code is rejected only if it is not an expense or asset account, or is a cash/bank, control or contra account; an engine account left off the list (e.g. depreciation) is still accepted by code, so use one only when the receipt really is that cost. The paid-from code has its own rule: any asset, liability or equity account except the A/R and A/P control accounts, Taokeh's own zero-balance clearing accounts (Contra Clearing, Refund Clearing — left out of paidFromAccounts and refused) and a foreign-currency bank or card (Taokeh posts only ringgit accounts for now, so paidFromAccounts leaves those out and a draft naming one is refused). MONEY THE OWNER PAID PERSONALLY ("I paid with my own money"): use ownerPocketCode as the paid-from — Capital Contribution for a sole proprietor or partnership, the Shareholder's Loan otherwise. A sole proprietor or partnership has no Shareholder's Loan: paidFromAccounts leaves it out and a draft naming it is refused. When ownerPocketCode is null, ownerPaidRefusal says what the owner must fix first — file no owner-paid draft until then.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint=false; the description goes far beyond by disclosing the curation rule for expenseCategories and paidFromAccounts, the exact conditions under which a code is rejected, the rationale for omitted engine/clearing/foreign-currency accounts, and the owner-paid refusal semantics via ownerPocketCode/ownerPaidRefusal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense multi-clause run-on with heavy parentheticals and some restatement (clearing/refused accounts are explained in more than one place). Most content is rule-relevant, yet a sentence or two could be cut without losing correctness.

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 no parameters and no output schema, the description carries the full burden and does so: it explains what the tool yields, which accounts are included/excluded and why, how codes are validated, and how owner-paid drafts are handled. An agent needs nothing else to call it correctly.

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?

The input schema is empty (0 params), so the baseline is 4. The description does not add input-parameter meaning, but it compensates by explaining the semantics of the returned members (expenseCategories, paidFromAccounts, ownerPocketCode, ownerPaidRefusal), which is useful context rather than parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource — 'the expense accounts you can post to in this company' — and its use: picking a category and paid-from account by code for shaping a paid-expense draft. An agent can tell it apart from the draft/creation siblings, but it never states explicitly that this is a read-only lookup returning lists, leaving the action slightly inferred.

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?

Gives clear context (use for shaping a paid-expense draft; use an engine account only when the receipt really is that cost) and strong when-not guidance on excluded accounts and refused codes. It does not explicitly name a sibling tool or say 'call this before create_expense_draft', so routing is implied rather than spelled out.

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