rigid-pipeline-mcp

Overview Schema Source Related Servers Discussions Admin

Query database

db_query

Read-onlyIdempotent

Execute read-only SELECT queries on SQLite databases with safe parameter binding. Use positional or named placeholders to pass values without formatting them into SQL.

Instructions

Runs a single read-only SELECT query. Use params instead of formatting values into the sql string — a list for '?' positional placeholders, or a dict for ':name' named placeholders. The dict form is what makes for_each useful here: a for_each step with item_arg='params' over a list of row-dicts (e.g. from get_metadata) binds each dict directly — extra keys not referenced by the sql are simply ignored.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sql`	Yes
`params`	No
`db_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's emphasis on read-only is consistent. The description adds valuable behavioral context by explaining placeholder binding behavior (ignoring extra keys in dicts), which is not inferable from schema or annotations. This enriches the agent's understanding without contradiction.

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 concise yet information-dense, front-loading the core purpose and safety constraint (read-only) before diving into usage details. Every sentence contributes to either clarifying purpose or guiding usage, with no fluff or 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 tool's moderate complexity (3 params, read-only query) and the rich output schema, the description covers all necessary aspects: purpose, parameter binding, and integration with for_each. The annotation covers idempotency, and the output schema likely describes result structure, so nothing critical is missing. The description is complete for effective invocation.

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 description coverage is 0%, so the description must compensate, and it does excellently. It explains the semantics of the 'params' parameter in detail (list for positional, dict for named placeholders, behavior with extra keys), which is vital for correct usage. It also implies the purpose of sql and db_path through context.

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?

States a specific verb (runs), resource (a single read-only SELECT query), and clearly distinguishes itself from siblings like db_execute by emphasizing read-only. The purpose is unambiguous and contextually 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?

Explicitly instructs to use params instead of formatting values into the SQL string, which is critical for safe query construction. It also describes a specific pattern (for_each with item_arg='params') and how to use dicts from get_metadata, giving concrete guidance on when and how to use this tool effectively.

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

Deploy Server