Loading ToolBench
Self-hosted MCP server for Liquid — connect your agent to any HTTP API on the fly. Exposes a Liquid engine as MCP tools over stdio for API discovery, connection, and data fetching.
The Liquid MCP server exposes 8 tools with a focus on API discovery and data fetching. While tool names follow verb_noun conventions and descriptions are generally present, they vary significantly in quality and completeness. Most tools lack detailed parameter descriptions and output schema documentation. Four tools (liquid_query, liquid_estimate, liquid_sense, liquid_execute) have minimal descriptions (5-55 chars) that fail to explain their purpose, expected behavior, or when to use them. Input schemas are present for all tools but contain shallow documentation, parameters like 'endpoint' appear in 5 different tools with identical descriptions, but critical parameters like filters/queries for liquid_query are not specified in the visible schema. Error handling and recovery guidance are absent across all tools. The server does implement tool annotations (toolAnnotations=true), which is positive, but these are not visible in the provided code samples, so credit is limited.
One-time setup for an API. Discovers the API at `url`, uses an LLM to map its responses onto your `target_model`, and saves a reusable adapter; returns an `adapter_id` you then pass to liquid_fetch / liquid_query / liquid_estimate. Side effects: makes outbound HTTP(S) requests to `url`, calls the configured LLM (requires an API key), and persists the adapter + any credentials under ~/.liquid. Idempotent — re-connecting the same url+target_model reuses the existing adapter instead of duplicating it. Use this once per API. For a quick look without saving anything, use liquid_discover instead; to read data from an already-connected API, use liquid_fetch.
One-time discovery of an API without saving anything
Estimate the cost of a fetch before making it
Execute a write action through an adapter
Fetch records through a connected adapter, mapped to the target_model you set at connect time — deterministic, no LLM call. Side effects: makes a read-only outbound HTTP(S) request to the connected API using the stored credentials; it is subject to that API's rate limits (Liquid throttles proactively and surfaces 429s with retry hints). Returns {records, data: [up to 100 mapped records], _meta}. Requires an adapter_id from liquid_connect. Use this to pull whole records; to filter/aggregate server-side and get a smaller answer use liquid_query instead; to size a pull before making it, call liquid_estimate first.
Four tools have critically short descriptions (<35 chars) that fail to explain purpose, parameters, or when to use them: liquid_query (27 chars), liquid_estimate (29 chars), liquid_sense (35 chars), liquid_execute (34 chars). These violate the minimum of 10 - 1024 characters and provide zero LLM guidance.
Four tools (liquid_query, liquid_estimate, liquid_sense, liquid_execute) appear to have incomplete or inferred schema definitions visible in the code samples. Input parameters are shown but critical action/filter/subscription parameters are missing.
No tool documents its output schema or response structure. Descriptions mention results (e.g., 'up to 100 mapped records', 'adapter_id, service name, source url', 'live events') but schemas are not provided. LLMs cannot plan downstream calls or extract chaining IDs without documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2025-06-18+ | v2 |
List the adapters already connected on this machine (read from ~/.liquid) — read-only, no network call, no LLM. Each entry has its adapter_id, service name, source url and endpoint paths. Call this to find an adapter_id for liquid_fetch / liquid_query / liquid_estimate, or to check whether an API is already connected before calling liquid_connect.
Search or aggregate through an adapter
Subscribe to live events from an adapter
No error handling or recovery guidance in any tool description. Tools make outbound HTTP requests and call external LLMs (liquid_connect, liquid_discover) but provide no guidance on what happens on 429, 5xx, timeout, or LLM API key failures. No suggestion for retry, fallback, or user correction.
The 'endpoint' parameter is duplicated across liquid_fetch, liquid_query, liquid_estimate, liquid_sense, and liquid_execute with identical descriptions ('Optional endpoint path to act on'). This generic description does not explain how to discover valid endpoints, what the format is (leading slash? relative or absolute?), or what happens when omitted.
liquid_execute is marked Risk: WRITE but the description does not warn of irreversibility, suggest confirmation/dry-run patterns, or explain what 'write action' means. This violates the requirement that destructive tools explicitly state side effects.
liquid_connect and liquid_discover list example credential formats (api_key, token, username/password) in the description, which violates rubric guidance, LLMs tend to reuse example values literally. Should replace with enum constraints or validation rules.
liquid_sense uses non-standard verb 'sense'; conventional alternatives (subscribe, watch, stream, listen) would be clearer for LLMs. 'Sense' is domain jargon that may not map to agent tooling patterns.
liquid_query and liquid_fetch descriptions state they return 'up to 100 mapped records' but no pagination parameters (limit, offset, cursor, page) are documented in the schema. LLMs cannot fetch > 100 records or iterate through results.
liquid_estimate description does not explain what 'cost' means (tokens? API calls? financial cost? data volume?) or how to use the estimate for decision-making. An LLM has no way to interpret the result.