Skip to main content
Glama

Search or aggregate through an adapter

liquid_query
Read-onlyIdempotent

Query a connected API adapter to retrieve filtered records, counts, or aggregated summaries, returning only the answer instead of the full payload.

Instructions

Run a server-side search or aggregation through an adapter and get just the answer instead of the full payload — deterministic, no LLM call, read-only. Two modes: set group_by/agg to aggregate (counts, sums, …), or where/fields/limit to filter and project. Side effects: a read-only outbound HTTP(S) request to the connected API, rate-limited like liquid_fetch. Returns search results {records, data, _meta} or an aggregation {result, _meta}. Prefer this over liquid_fetch whenever you only need a filtered slice, a count, or a summary — it returns far fewer tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
adapter_idYesAn adapter id returned by liquid_connect (or listed by liquid_list_adapters).
endpointNoOptional endpoint path to act on (e.g. "/users"); defaults to the adapter's primary endpoint. Use a path shown by liquid_connect / liquid_list_adapters.
whereNoSearch-mode filter as field -> value (or field -> {op: value}), e.g. {"status": "active", "price": {"gt": 100}}. Keys are target_model fields.
fieldsNoSearch-mode projection: target_model field names to return, e.g. ["name", "price"]. Omit for all fields.
limitNoSearch-mode max records to return (default 100).
group_byNoAggregate-mode: target_model field to group by, e.g. "category".
aggNoAggregate-mode: aggregations per group as field -> op, e.g. {"price": "sum", "id": "count"}. Provide together with group_by.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
recordsNoSearch mode: number of records.
dataNoSearch mode: matching records (capped at 100).
resultNoAggregate mode: the grouped/aggregated result.
_metaNoCall metadata: adapter_id, service, endpoint, latency_ms (and records when applicable).
errorNo
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it is 'deterministic, no LLM call' and mentions a read-only outbound HTTP request with rate-limiting, providing helpful behavioral context beyond the structured annotations. No contradictions.

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?

Description is fairly concise and well-structured, leading with key characteristics (deterministic, read-only) and following with mode details and comparison. While slightly long, every sentence contributes value; no redundancy.

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?

Given the presence of output schema (not shown but indicated), annotations, and 7 parameters with full schema coverage, the description sufficiently covers purpose, usage modes, side effects, return types, and sibling differentiation. It is complete for a query tool with this complexity.

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 100% with descriptions for each parameter. The description adds context by explaining the two modes and which parameters belong to each (e.g., group_by/agg for aggregate, where/fields/limit for search), helping the agent understand parameter relationships beyond 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 clearly states the tool performs server-side search or aggregation through an adapter, is deterministic and read-only. It distinguishes two modes (search with where/fields/limit, aggregate with group_by/agg) and explicitly contrasts with sibling tool liquid_fetch, making its purpose unambiguous and well-differentiated.

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 explicit guidance on when to use this tool over liquid_fetch ('whenever you only need a filtered slice, a count, or a summary'), lists side effects (rate-limited like liquid_fetch), and describes the two operational modes. This equips the agent with clear decision-making criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ertad-family/liquid'

If you have feedback or need assistance with the MCP directory API, please join our Discord server