Skip to main content
Glama

Taokeh MCP server

Search journal entries

search_journal
Read-only

Search the general ledger's JOURNAL ENTRIES — every posting, whatever door created it (a manual journal, a scanned receipt, an invoice, a bank row, a paid expense, payroll, depreciation…). Returns each entry WITH its balanced lines (account code + name, debit, credit, line description), so you can see exactly HOW something was booked, not just that it exists. Filter by any combination of: date range, text (case-insensitive, matched against the entry memo AND its line descriptions), accountCode (entries touching that account), source (the door that created it), and an amount range on the entry's total debits. Give at least one filter — this never dumps the whole ledger. Newest first, capped, with a more flag. Pairs with search_expenses for reconciling: search_expenses shows what the /expenses register holds, search_journal shows every ledger entry including journal-era postings the register never covered. Read-only — it changes nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
refNoNOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`.
fromNo
memoNoNOT a filter on this tool. Pass memo text as `text` (it matches the entry memo AND every line description).
textNoPartial text matched against the entry memo AND its line descriptions (case-insensitive contains).
partyNoNOT a filter on this tool. The ledger has no party column — search the name as `text`, or find the document with search_documents.
refNoNoNOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`.
numberNoNOT a filter on this tool. A journal entry has no document number — search its memo and line descriptions with `text`, or find the document itself with search_documents.
sourceNoThe door that created the entry (exact, case-insensitive). One of: MANUAL, SALE, PURCHASE, ADJUSTMENT, BANK, CREDIT_NOTE, DEBIT_NOTE, PAYROLL, IMPORTED_SERVICE, FX_REVAL, DEPRECIATION, ASSET_DISPOSAL, EXPENSE, LOAN, REVENUE_RECOGNITION, ASSET_ACQUISITION, BANK_OPENING. Omit for all.
accountNoNOT a filter on this tool. Pass the chart-of-accounts code as `accountCode` (exact).
maxAmountNoMaximum entry size, measured on the entry's total debits (MYR).
minAmountNoMinimum entry size, measured on the entry's total debits (MYR).
referenceNoNOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`.
accountCodeNoRestrict to entries that have a line on this account code (exact).
descriptionNoNOT a filter on this tool. Pass the text as `text` (it matches the entry memo AND every line description).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / account
      Added value: +{
      +  "description": "NOT a filter on this tool. Pass the chart-of-accounts code as `accountCode` (exact)."
      +}
    • addedInput schema / properties / description
      Added value: +{
      +  "description": "NOT a filter on this tool. Pass the text as `text` (it matches the entry memo AND every line description)."
      +}
    • addedInput schema / properties / memo
      Added value: +{
      +  "description": "NOT a filter on this tool. Pass memo text as `text` (it matches the entry memo AND every line description)."
      +}
    • addedInput schema / properties / number
      Added value: +{
      +  "description": "NOT a filter on this tool. A journal entry has no document number — search its memo and line descriptions with `text`, or find the document itself with search_documents."
      +}
    • addedInput schema / properties / party
      Added value: +{
      +  "description": "NOT a filter on this tool. The ledger has no party column — search the name as `text`, or find the document with search_documents."
      +}
    • addedInput schema / properties / ref
      Added value: +{
      +  "description": "NOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`."
      +}
    • addedInput schema / properties / refNo
      Added value: +{
      +  "description": "NOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`."
      +}
    • addedInput schema / properties / reference
      Added value: +{
      +  "description": "NOT a filter on this tool. A journal entry has no reference field — search its memo and line descriptions with `text`."
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavior: results are 'Newest first, capped, with a more flag', and each entry comes with balanced debit/credit lines. The only redundancy is the closing 'Read-only — it changes nothing', which merely restates the annotation.

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 longer than average but front-loads the core purpose, then moves through return shape, filters, constraints, and sibling relationship. The enumeration of creation doors is slightly verbose but reinforces the 'every posting' scope; no wasted sentences overall.

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 15-parameter tool with no output schema, the description covers the return payload, ordering, cap indicator, filter semantics, required filter, and sibling distinction. An agent has enough to select and invoke this tool correctly without opening the schema.

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 87%, so the baseline is solid; the description still adds value by explaining the filter contract ('any combination of'), clarifying text matches 'the entry memo AND its line descriptions', and requiring at least one filter. It also orients the amount range to 'the entry's total debits', which matches the schema.

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?

Description opens with a specific verb-resource combination: 'Search the general ledger's JOURNAL ENTRIES — every posting, whatever door created it'. It further clarifies the output includes balanced lines, which differentiates it from a mere existence-check and from sibling search_expenses.

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?

Explicitly states 'Give at least one filter — this never dumps the whole ledger' and names the sibling alternative: 'Pairs with search_expenses for reconciling: search_expenses shows what the /expenses register holds, search_journal shows every ledger entry including journal-era postings the register never covered.' This gives clear selection criteria.

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