seattle-open-data
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SOCRATA_APP_TOKEN | No | Optional Socrata application token. A rejected token is reported as `app_token_rejected`, never silently dropped. |
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
} |
| logging | {} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| seattle_data_search_datasetsA | Find Seattle datasets by topic. Call first when you lack a dataset id. Only results with queryability "supported" can be described or queried. Example: {"query": "fire 911"}. Typically 1-3 s. |
| seattle_data_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 |
| seattle_data_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 dataset_id, cursor, and optionally page_size or detail. For all rows, give the user download_url (detail="full") instead of paging. Example: {"dataset_id": "kzjm-xkqj", "select": ["type", "count() AS n"], "group_by": ["type"], "order_by": ["n DESC"]}. Typically 1-5 s; fails with query_timeout after 30 s. |
| seattle_data_get_referenceA | Read the server's reference: capability summary, SoQL help, dataset guides, and the full error catalog. Call with no arguments for the index. Example: {"topic": "soql", "item_id": "dates"}. |
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. |
| reference-index | Every reference topic: capabilities, guides, soql, errors. |
| soql-index | Sections on syntax, filtering, aggregation, dates, geography, and paging. |
| errors-index | The error envelope, codes by tool, and authentication repair. |
| guides-index | Curated guides for flagship Seattle datasets. |
TDQS
Scored across 4 tools
Each tool targets a distinct phase of the workflow: search_datasets (discovery), describe_dataset (schema inspection), query_dataset (execution), and get_reference (documentation). There is no overlap between their purposes, and descriptions explicitly guide sequencing (call search first, call describe before querying).
All four tools share the seattle_data_ prefix and follow a consistent verb_noun pattern (search_datasets, describe_dataset, query_dataset, get_reference). The convention is entirely predictable.
Four tools is a well-scoped, minimal surface for a read-only data portal: discover, inspect, query, and reference are exactly the operations needed. Each tool clearly earns its place with no redundancy.
The set covers the full read lifecycle of open-data access (search, describe, bounded query/aggregate, and reference/help) for a read-only public data domain where create/update/delete are not applicable. No dead ends are apparent.