opendata-atlas
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SOCRATA_APP_TOKEN | No | A Socrata application token. If a portal rejects the token, the server reports `app_token_rejected` rather than silently dropping it. A token may not be accepted by every portal. | |
| OPENDATA_ATLAS_PORTALS | No | Limits the server to the portals you list, by id or alias, separated by commas (for example, `seattle,chicago`). Any other portal fails with `portal_not_enabled`. Names that match no portal are ignored, so a list in which nothing matches blocks every portal. Unset or blank, every registered portal is served. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| atlas_find_portalsA | Find portals by place name; the portal id it returns goes in every other tool's Call this before any tool that takes |
| atlas_search_datasetsA | Find a portal's datasets by topic. Call when you lack a dataset id. Results are candidates: match_evidence lists the query words each one's metadata lacks. Only queryability "supported" can be described or queried; a tabular search also returns up to 3 external_matches, which cannot. Illustrative example: {"portal": "example-city", "query": "fire 911"}. Typically 1-3 s. |
| atlas_describe_datasetA | Decide whether and how to query a dataset: columns, live row count, data_coverage
(actual time range), place fields for "in " questions (with reliability),
and geo columns for Call before querying a dataset whose columns you do not know.
For area questions, use detail="full".
Filter a place field on its |
| atlas_query_datasetA | Run a bounded read or aggregate on one dataset; paging stops at 10,000 rows. For counts and breakdowns, use count() with group_by, not row paging. With cursor, send only portal, dataset_id, cursor, and optionally page_size or detail. For all rows, give the user download_url (detail="full") instead of paging. Illustrative example: {"portal": "example-city", "dataset_id": "abcd-1234", "select": ["type", "count() AS n"], "group_by": ["type"], "order_by": ["n DESC"]}. Typically 1-5 s; fails with query_timeout after 30 s. |
| atlas_get_referenceA | Read the server's reference: capability summary, portals, dataset guides, SoQL help, error catalog, and tier definitions. Call with no arguments for the index. Example: {"topic": "soql", "item_id": "dates"}. With cursor, repeat only topic and, for guides, portal. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| capabilities | What the server does and does not do, binding rules, and failure carriers. Read first. |
| contributing | What portal tiers and dataset knowledge levels mean, and how to contribute a portal's pack. |
| reference-index | Every reference topic except guides (see portals). |
| portals-index | Curated and profiled portals, each linking its summary. |
| soql-index | Sections on syntax, filtering, aggregation, dates, geography, and paging. |
| errors-index | The error envelope, codes by tool, and authentication repair. |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: finding portals, searching datasets, describing dataset structure, querying data, and reading reference material. There is no overlap in the actions or resources they target, making selection unambiguous.
All tool names follow a consistent atlas_verb_noun pattern in snake_case. The verbs (describe, find, get, query, search) are appropriate and predictable, with no mixing of conventions.
Five tools are well-scoped for the server's purpose of exploring and querying open data portals. Each tool covers a necessary step in the workflow (discover portal, find dataset, inspect schema, query, reference), and none feel redundant.
The tool set covers the core lifecycle from portal discovery to data querying, including metadata inspection and reference help. A minor gap is the absence of a direct way to list all datasets within a portal without a topic query, which could hinder broad exploration.