Georgia Civic Data

list_datasets

Enumerate every approved Georgia dataset (topic) and the shared dimensions. Each topic entry is a LEAN summary — name/keys, year coverage (year_min/year_max + year_gaps), detail levels + default detail, a has_demographic flag (false = no demographic axis, so there is no all-students demographic row to filter), tags, contract version, and a one-line description — enough to pick a topic; call describe_dataset for its full schema (columns, filters, grain, source, example queries). Each dimension entry carries its primary key, attribute columns, and (for districts) cross-dataset link keys. Call this first to learn what exists — but for a NAMED task (you already know roughly the topic), prefer search_datasets, which returns far fewer bytes than this full catalog.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses substantial output behavior: LEAN summaries, year coverage fields, the has_demographic flag semantics, dimension keys, and the fact that this is a large full catalog. It does not mention pagination or rate limits, but for a read-only enumeration tool the disclosed detail is strong.

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 long but every sentence earns its place: it front-loads the purpose, details the exact content of each entry, and closes with routing guidance. The structure is organized around what an agent needs to know before invoking the tool.

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?

For a zero-parameter discovery tool, the description is remarkably complete: it specifies output contents for both topics and dimensions, explains the meaning of key flags, and gives clear alternative routes. The presence of an output schema reduces the need to explain return values, yet the description still provides useful semantic context.

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?

The tool has zero parameters and 100% schema coverage, so the schema already makes it clear no arguments are needed. The description adds value by explaining what the no-argument call returns, which is beyond the empty schema, but there are no parameter semantics to clarify.

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: 'Enumerate every approved Georgia dataset (topic) and the shared dimensions.' It clearly distinguishes this catalog-listing tool from siblings by naming search_datasets and describe_dataset as alternatives for different needs.

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?

The description gives explicit when-to-use guidance: 'Call this first to learn what exists' and explicitly warns against using it for named tasks, directing the agent to search_datasets instead because it returns fewer bytes. It also routes to describe_dataset for full schema details.

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

All Georgia Civic Data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool maps to a distinct capability: discovery, schema, values, entity resolution, row query, aggregation, cross-dataset joins, and dimension reads. Even the pairs that sound closest (list_datasets vs search_datasets, describe_dataset vs get_contract) are explicitly differentiated by behavior and use case.

Naming Consistency4/5

Names are uniformly lowercase snake_case and mostly follow a clear verb_noun pattern (describe_dataset, query_dataset, resolve_entity, link_tables). Only aggregate (bare verb) and distinct_values (noun phrase without a verb) deviate slightly from that pattern.

Tool Count5/5

Twelve tools is a well-scoped size for a data-access MCP server. Each tool adds a non-redundant capability, supporting the full workflow from discovery and schema inspection to querying, aggregation, and cross-dataset joins.

Completeness5/5

The surface covers the complete read-only lifecycle: catalog discovery, schema/dimension inspection, value and entity lookup, row-level queries, grouped aggregation, cross-dataset analysis, and dimension table reads. Bulk data access is handled via pointers in query results rather than a dedicated tool, which is a deliberate non-gap for this query-focused server.

Resources

Need Help?