Skip to main content
Glama

Taokeh MCP server

Cash position

cash_position
Read-only

How much cash you have right now: every bank account and cash pocket with its current GL balance, plus a grand total. total is LIQUID money only — physical cash + bank accounts + the payment-gateway clearing float — and accounts lists exactly those accounts. Money the OWNER has advanced to the business (the Shareholder Loan) is returned SEPARATELY as ownerFunding: it is a LIABILITY the business owes back, not cash it holds, so it is never inside total and must never be added to it or described as cash. ⚠ A SOLE PROPRIETOR OR PARTNERSHIP owes its owner nothing (its owner money is Capital Contribution): there ownerFunding appears only for a balance still on the Shareholder Loan from before the business type was set, flagged fromBeforeBusinessType: true — relay its note, and never say the business owes the owner. CREDIT CARDS are returned separately for exactly the same reason, as cards (one entry per card, with cardsOwing for the total): what sits on a card is money OWED to the issuer, not cash the business holds, so it is never inside total — report it as card debt beside the cash figure, never as cash and never as a negative bank balance. Each card carries its own direction ('owed_to_issuer', or 'in_credit' when the card is overpaid) — follow it rather than assuming a debt. Balances are MYR-booked (the books are kept in ringgit); a foreign bank account shows its currency label for context, but the balance figure is still the MYR-booked GL balance.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover the read-only, closed-world safety profile, so the description carries the real burden — and it delivers: what is inside `total` vs excluded, how ownerFunding and cards are surfaced separately, business-type caveats (sole proprietor/partnership, `fromBeforeBusinessType` flag), card `direction` semantics, and MYR booking of foreign balances. This is far beyond what the annotations provide.

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 total definition are front-loaded, then edge cases follow in a logical order. The single dense paragraph with heavy emphasis ('never', '⚠') is long, but nearly every sentence carries distinct accounting semantics rather than filler.

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 output schema, the description assumes full responsibility for explaining return values, and it does so comprehensively — total composition, ownerFunding, cards/cardsOwing, direction, and currency booking. Nothing essential for correct reporting 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?

There are zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter meaning because none exist; the field-level explanation it does give concerns outputs, not inputs.

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 statement — 'How much cash you have right now' — and immediately enumerates the returned shape (every bank account and cash pocket with its current GL balance, plus a grand total). An agent can tell this apart from forward-looking siblings like cash_forecast or aggregate reports like balance_sheet. Purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is rich on how to interpret and relay results, but it never states when to choose this tool over alternatives such as cash_forecast or balance_sheet, nor any prerequisites. Usage is implied by the resource rather than routed explicitly, so 3 is appropriate.

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