Skip to main content
Glama

Search combined

search_combined
Read-only

The unified search over business data — combine free text and/or an amount range in one call. Set 'kind' to: all, expenses, income, transactions, clients, suppliers, products, or invoices (use 'all' to search the whole business). Set 'query' for text search (case-insensitive substring match across names, descriptions, notes, references, supplier/client names, categories) and/or 'min'/'max' for an amount range on the kind's primary amount field — both are optional, so omit the amount range for a pure text search (e.g. over clients or suppliers) or omit 'query' for a pure amount search. Optionally filter by date range with 'from' and 'to' in YYYY-MM-DD format. Set 'sort' to 'amount' (default — descending by amount) or 'date' (descending by date; best for clients/suppliers, which have no amount, or when recency matters more than size). Returns ALL matches, paginated — use limit/cursor to page through the full result set; narrow query/range/date if there are more than you need.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoUpper bound of the date range to match (ISO 8601, YYYY-MM-DD).
maxNoUpper bound of the amount range to match (matched on the kind's primary amount field, absolute value).
minNoLower bound of the amount range to match (matched on the kind's primary amount field, absolute value).
fromNoLower bound of the date range to match (ISO 8601, YYYY-MM-DD).
kindYesWhich collection to search. One of: "all" (every collection), "expenses", "income", "transactions", "clients", "suppliers", "products", "invoices".
sortNoResult ordering. "amount" (default) sorts by the kind's primary amount field descending; "date" sorts by date descending — use "date" for clients/suppliers (which have no amount) or whenever recency matters more than size.
limitNoMax rows to return in this page (default 50). Responses include next_cursor / truncated / total; pass next_cursor back as `cursor` to fetch the next page. Never silently truncated.
queryNoFree-text search query (case-insensitive substring match across all text fields).
cursorNoOpaque pagination cursor. Omit for the first page; pass the next_cursor from a previous response verbatim to fetch the next page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Result ordering. \"amount\" (default) sorts by the kind's primary amount field descending; \"date\" sorts by date descending — use \"date\" for clients/suppliers (which have no amount) or whenever recency matters more than size.",
      +  "enum": [
      +    "amount",
      +    "date"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

The readOnlyHint annotation is consistent. The description transparently discloses search behavior: case-insensitive substring matching, absolute value for amount, default sort, pagination mechanics, and the response fields (next_cursor / truncated / total). No hidden side effects.

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

Conciseness5/5

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

The description is detailed but every sentence serves a purpose, covering all parameters and behaviors without redundancy. It is well-structured with clear explanations of filters, sorting, and pagination.

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?

Even without an output schema, the description explains what the response includes (next_cursor / truncated / total) and how to page. Combined with the exhaustive parameter coverage, it is fully self-contained for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already has 100% description coverage, and the description adds extra semantic detail: absolute value for amount bounds, case-insensitive substring, default limit 50, and how to use the cursor. This goes well beyond the schema's baseline.

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?

Clearly states it is a unified search over business data, listing the supported kinds and the ability to combine free text, amount, and date filters. This differentiates it from the many list_* sibling tools that target specific collections, making its purpose unmistakable.

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?

Provides thorough usage guidance: explains how to use kind, query, min/max, from/to, sort, limit, and cursor, including pagination with next_cursor and the note that results are never silently truncated. This is more than enough to know when and how to invoke it compared to alternatives.

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