Skip to main content
Glama
jdzhrch

OpenCivicQuery

by jdzhrch

query_dataset

Run read-only SoQL queries on Socrata open-data portals to return auditable figures with row limits, completeness warnings, reproducible query links, and evidence snapshots.

Instructions

Run a read-only SoQL query with a mandatory row ceiling. The response on success states completeness, warnings, methodology, source update time, the public dataset page, the exact query, a public live-result query_url when the source supports one, and the URI of an immutable evidence snapshot. If completeness is truncated, revise the query or report the limitation. The response also carries presentation_rules, which govern how you must state its figures to the user; obey every rule listed there before you write your reply. Failures return isError=true and an error object with the failure code, message, argument, and http_status. A failed query has no data result or snapshot.

Input Schema

NameRequiredDescriptionDefault
whereNo
domainYesThe portal's hostname, for example data.cityofnewyork.us. Use the domain that search_datasets or list_source_packs returned.
selectYes
group_byNo
max_rowsNo
order_byNo
dataset_idYesThe Socrata dataset ID, four characters, a hyphen, and four characters.
reporter_questionYesThe reporter's own question, quoted as they asked it, not a rewrite and not a restatement of the query you built. This is recorded so maintainers can see what reporters actually needed. If the request arrived over several turns, give the question this call is meant to answer.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses read-only behavior, row limits, success metadata, completeness/truncation semantics, presentation_rules, and failure behavior including isError=true and the error object fields. It also clarifies that failed queries produce no data result or snapshot.

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 front-loaded with the core purpose and then provides behaviorally important details about success, truncation, presentation rules, and failure. It is slightly dense, especially the long list of success response fields, but every sentence contributes operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and the description explains result and failure behavior well, but the tool has 8 parameters, no annotations, and low schema description coverage. The description is therefore complete on post-query behavior but thin on how to construct the query correctly.

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

Parameters2/5

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

Schema description coverage is only 38% across 8 parameters, so the description needed to compensate by explaining where, select, group_by, order_by, and max_rows. It only indirectly alludes to SoQL and a row ceiling; most parameter meanings remain undocumented beyond their names.

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?

The description states a specific verb and resource: run a read-only SoQL query against a dataset, with a mandatory row ceiling. It clearly distinguishes this from sibling tools like search_datasets, describe_dataset, and get_snapshot, which handle discovery, metadata, and snapshots rather than row queries.

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

Usage Guidelines3/5

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

Usage is implied by the query purpose and the note about handling truncated completeness, but the description does not explicitly say when to choose query_dataset over describe_dataset, get_snapshot, or search_datasets. It gives post-result guidance rather than tool-selection guidance.

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