Skip to main content
Glama
seattle-open-data

seattle-open-data

Seattle Data Search Datasets

seattle_data_search_datasets
Read-only

Search Seattle open datasets by topic or keyword to identify queryable dataset IDs and candidates before running data queries. Filter by category, page results, and inspect match evidence.

Instructions

Find Seattle datasets by topic. Call first 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. Example: {"query": "fire 911"}. Typically 1-3 s.

Input Schema

NameRequiredDescriptionDefault
queryNoWords to match; omit to list the most-viewed.
cursorNonext_cursor from the previous page; omit for page one.
detailNosummary (default) or full: adds descriptions.
categoryNoExact category name, e.g. Public Safety; omit for all.
page_sizeNoDefault 10.
asset_scopeNotabular (default): queryable datasets and filter views. all: adds federated ArcGIS and external links, which cannot be queried.

Output Schema

NameRequiredDescriptionDefault
sourceYes
datasetsYes
has_moreYes
suggestionNo
next_cursorNo
match_evidenceNo
external_matchesNo
external_search_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.0
    • addedOutput schema / properties / external_matches
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "asset_type": {
      +        "type": "string"
      +      },
      +      "category": {
      +        "type": "string"
      +      },
      +      "dataset_id": {
      +        "type": "string"
      +      },
      +      "derived_from": {
      +        "type": "string"
      +      },
      +      "description": {
      +        "type": "string"
      +      },
      +      "external_url": {
      +        "type": "string"
      +      },
      +      "guide_uri": {
      +        "type": "string"
      +      },
      +      "portal_url": {
      +        "type": "string"
      +      },
      +      "queryability": {
      +        "enum": [
      +          "supported",
      +          "external",
      +          "unsupported",
      +          "unknown"
      +        ],
      +        "type": "string"
      +      },
      +      "title": {
      +        "type": "string"
      +      },
      +      "updated_at": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "dataset_id",
      +      "title",
      +      "asset_type",
      +      "queryability",
      +      "portal_url"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / external_search_status
      Added value: +{
      +  "enum": [
      +    "completed",
      +    "unavailable"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / match_evidence
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "description": "Which query words a result's catalog metadata visibly contains; never a relevance verdict.",
      +    "properties": {
      +      "dataset_id": {
      +        "type": "string"
      +      },
      +      "matched_fields": {
      +        "items": {
      +          "enum": [
      +            "title",
      +            "tags",
      +            "columns",
      +            "description"
      +          ],
      +          "type": "string"
      +        },
      +        "type": "array"
      +      },
      +      "matched_terms": {
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      },
      +      "matched_via": {
      +        "type": "string"
      +      },
      +      "unmatched_terms": {
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "dataset_id",
      +      "matched_terms",
      +      "unmatched_terms",
      +      "matched_fields"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / suggestion
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "alternative": {
      +      "type": "string"
      +    },
      +    "arguments": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "next_step": {
      +      "type": "string"
      +    },
      +    "tool": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "next_step",
      +    "tool",
      +    "arguments"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond readOnlyHint/openWorldHint: match_evidence semantics, the fact that only 1-3 external_matches come back for tabular searches and are unusable, candidate-vs-confirmed result status, and a latency expectation (1-3 s). This is the kind of information an agent cannot get from annotations.

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?

Front-loads purpose and the when-to-use rule, then layers result semantics, an example, and timing in short clauses. Dense but every sentence carries information; the match_evidence/queryability sentences are slightly heavy for a first read.

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?

An output schema exists and the description still supplies the key result semantics (candidates, match_evidence, external_matches), plus when to call, an example invocation, and expected latency. An agent has everything needed to call it correctly and interpret the payload.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns a bump by showing query usage ({"query": "fire 911"}) and clarifying the behavioral consequence of asset_scope=tabular (external_matches returned but not queryable). It does not cover cursor/page_size, which the schema already documents.

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?

Specific verb+resource ("Find Seattle datasets by topic") with an explicit role in the workflow: "Call first when you lack a dataset id." That sentence alone separates it from seattle_data_describe_dataset and seattle_data_query_dataset, which both require an id.

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?

Gives a clear entry condition (no dataset id yet) and a downstream constraint (only queryability "supported" can be described or queried; external_matches cannot). It does not name the sibling tools it hands off to, so the routing is implied rather than explicit.

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