Taokeh MCP server

Search paid expenses

search_expenses

Read-only

Search PAID EXPENSES already posted to the books (the /expenses ledger) by any combination of: reference (partial), text in the memo/description (partial), date range, amount range, and category account. Returns compact rows (expenseId, date, amount, category account code + name, memo, reference), newest first, capped — with a more flag. Every row also says whether the ORIGINAL RECEIPT is on file: hasAttachment plus an attachments list (filename, media type, size) — an empty list means genuinely no receipt is attached, not "unknown". To read one, pass the row's expenseId and attachmentId to get_attachment. ALWAYS check here BEFORE filing an expense draft (create_expense_draft): if the same receipt is already booked, filing again would double-book it. search_documents does NOT cover paid expenses — this tool is the only way to see them.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No
`ref`	No	NOT a filter on this tool. Pass the supplier/receipt reference as `reference`.
`from`	No
`memo`	No	NOT a filter on this tool. Pass memo text as `text`.
`text`	No	Partial text to match in the expense memo/description (case-insensitive contains).
`refNo`	No	NOT a filter on this tool. Pass the supplier/receipt reference as `reference`.
`number`	No	NOT a filter on this tool. Pass the supplier/receipt reference as `reference` — a posted expense has no document number of its own.
`vendor`	No	NOT a filter on this tool. A posted expense carries no party field here — search the supplier name as `text` (it matches the memo/description) or as `reference`.
`account`	No	NOT a filter on this tool. Pass the chart-of-accounts code as `accountCode` (exact).
`category`	No	NOT a filter on this tool. Pass the category by its chart-of-accounts code as `accountCode` (exact) — get codes from expense_accounts.
`supplier`	No	NOT a filter on this tool. A posted expense carries no party field here — search the supplier name as `text` (it matches the memo/description) or as `reference`.
`maxAmount`	No
`minAmount`	No
`reference`	No	Partial supplier/receipt reference (case-insensitive contains).
`accountCode`	No	Restrict to one expense category by its account code (exact).
`description`	No	NOT a filter on this tool. Pass memo text as `text`.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed9 schema fields changedSep 3, 2026

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 / category

Added value: +{
+  "description": "NOT a filter on this tool. Pass the category by its chart-of-accounts code as `accountCode` (exact) — get codes from expense_accounts."
+}

addedInput schema / properties / description

Added value: +{
+  "description": "NOT a filter on this tool. Pass memo text as `text`."
+}

addedInput schema / properties / memo

Added value: +{
+  "description": "NOT a filter on this tool. Pass memo text as `text`."
+}

addedInput schema / properties / number

Added value: +{
+  "description": "NOT a filter on this tool. Pass the supplier/receipt reference as `reference` — a posted expense has no document number of its own."
+}

addedInput schema / properties / ref

Added value: +{
+  "description": "NOT a filter on this tool. Pass the supplier/receipt reference as `reference`."
+}

addedInput schema / properties / refNo

Added value: +{
+  "description": "NOT a filter on this tool. Pass the supplier/receipt reference as `reference`."
+}

addedInput schema / properties / supplier

Added value: +{
+  "description": "NOT a filter on this tool. A posted expense carries no party field here — search the supplier name as `text` (it matches the memo/description) or as `reference`."
+}

addedInput schema / properties / vendor

Added value: +{
+  "description": "NOT a filter on this tool. A posted expense carries no party field here — search the supplier name as `text` (it matches the memo/description) or as `reference`."
+}

First observedAug 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnlyHint annotation: returns are capped with a 'more' flag, rows are newest first, attachment semantics are clarified ('an empty list means genuinely no receipt is attached, not "unknown"'), and it explains how to read an attachment via get_attachment. This is rich context an agent cannot infer from the schema alone.

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 dense but every sentence earns its place: scoping, filter semantics, return shape, attachment behavior, linking to get_attachment, and usage guidance are all present. It is front-loaded with the core purpose, though the single-paragraph format makes it slightly less scannable than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 16 parameters, sparse annotations, and no output schema, the description does a strong job of covering return rows, attachment semantics, the recurrence of the double-booking risk, and the relationship to get_attachment. Minor gaps remain: it discloses that results are 'capped' with a 'more' flag but does not explain how the agent would retrieve the next page, and it leaves pagination behavior partially implicit.

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 description communicates the intended filter combination: 'by any combination of: reference (partial), text in the memo/description (partial), date range, amount range, and category account.' It also, through the many 'NOT a filter' schema descriptions and the phrase 'Pass memo text as text', actively steers the agent away from plausible but wrong parameters. It does not enumerate every accepted parameter, but the schema already documents most of them well.

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?

The description states a specific verb and resource: 'Search PAID EXPENSES already posted to the books' and goes on to list the exact filter dimensions. It also differentiates itself from sibling tools by noting that 'search_documents does NOT cover paid expenses — this tool is the only way to see them.'

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?

It gives explicit when-to-use guidance: 'ALWAYS check here BEFORE filing an expense draft (create_expense_draft): if the same receipt is already booked, filing again would double-book it.' It also names the alternative it is not and states this tool is the only way to see paid expenses.

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?