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.

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.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, so the read-only safety is already known. The description goes further by explaining return-row composition, newest-first ordering, capping with a `more` flag, and the exact meaning of an empty `attachments` list versus an unknown state. This is valuable behavioral context beyond the annotations.

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 every sentence carries operational meaning: search scope, return shape, attachment semantics, attachment retrieval, double-booking prevention, and sibling-tool distinction. Information is front-loaded and logically ordered, though it could be tightened slightly without losing value.

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 fully compensates by specifying the returned fields, ordering, cap behavior, and attachment representation. It also covers the key workflow context (check before create_expense_draft) and the relationship to get_attachment and search_documents. Nothing essential is missing for an agent to invoke the tool 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 schema already covers 75% of parameters with useful descriptions, including NOT-filter disclaimers for ref, memo, vendor, and similar aliases. The description adds the 'any combination' semantics and maps search concepts like reference, text, date range, amount range, and category account onto the intended use. It does not enumerate every parameter name, but the schema plus description together are clear.

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 action and resource: search expenses that are already posted/paid in the /expenses ledger. It lists the exact filter dimensions and explicitly distinguishes itself from search_documents, which does not cover paid expenses. This gives an agent a precise, non-ambiguous purpose.

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?

The description gives explicit when-to-use guidance: check this tool before creating an expense draft to avoid double-booking a receipt, and use get_attachment to read attachments. It also names search_documents as a non-alternative, making the usage boundary crystal clear.

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

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

Need Help?