Skip to main content
Glama
Luissalet

Laplace's Hoard MCP Server

by Luissalet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

data_query

Read-onlyIdempotent

Run a read-only SQL query over registered datasets to filter, group, sum, or count data. Get cited results with row counts and truncation for large outputs.

Instructions

Run one read-only SQL query (DuckDB dialect) over the registered datasets.

Allowed: SELECT / WITH / DESCRIBE / SUMMARIZE / EXPLAIN / PIVOT, one statement; anything that writes or reads files directly is rejected. Refer to datasets by name: SELECT region, SUM(amount) AS total FROM sales GROUP BY region ORDER BY total DESC. Let SQL do the counting and summing - do not add up returned rows yourself. Returns {id, cite, columns, rows (at most limit, default 50, max 1000), row_count (rows returned), total_rows (rows the query produced), truncated}. Long text cells are cut at 500 characters. Call data_describe first if you have not seen the schema.

Keywords: query the data, SQL, filter rows, group by, total of, sum of, average of, count, top 10, consultar los datos, filtrar, agrupar por, total de, suma de, media de, contar, los 10 primeros.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only and non-destructive, and the description adds substantial behavioral detail: accepted statements, rejected operations, return shape with id/cite/columns/rows/row_count/total_rows/truncated, the 50-default/1000-max limit, truncation at 500 characters, and the instruction to let SQL do aggregation.

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 dense and well-structured, moving from purpose to constraints to example to return semantics and prerequisite. The keyword list at the end is slightly repetitive but aids retrieval; no sentence is wasted.

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 only two parameters and no output schema, the description supplies everything needed: allowed SQL constructs, example syntax, return field semantics, row limits, truncation behavior, and a clear prerequisite. Nothing material is missing for a correct call.

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%, but the description fully compensates. The sql parameter's syntax and constraints are explained with an allowed-statement list and an example, while the limit parameter's default and maximum are stated in the return-format note. This is more than enough semantic meaning for an agent to invoke the tool correctly.

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 and resource: 'Run one read-only SQL query (DuckDB dialect) over the registered datasets.' It enumerates allowed statement types and gives a concrete query example, making it clearly distinct from sibling tools like data_list, data_describe, and data_chart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage context: must be a single statement, writes and direct file reads are rejected, and data_describe should be called first when the schema is unknown. It does not explicitly enumerate when to prefer siblings like data_list or data_chart, but the guidance is clear enough for correct routing.

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

Deploy Server

Other Tools