Skip to main content
Glama

Public Data Catalog

by io.github.yhay81

Search Japanese public datasets

search_data
Read-onlyIdempotent

Search current metadata from e-Gov Data Portal and Statistics Dashboard, then return a short ranked list with publisher, formats, coverage, usage terms, and official links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoSearch all sources, downloadable datasets, or statistical seriesall
limitNo
queryYesWhat data to find, preferably in Japanese

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
queryYes
totalYes
statusYes
resultsYes
sourcesYes
availableYes
searched_atYes
interpreted_asYes

Schema Changelog

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

  1. Changed2 schema fields changed
    • addedOutput schema / properties / interpreted_as
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "status",
-  "query",
-  "searched_at",
-  "results",
-  "total",
-  "available",
-  "sources",
-  "note"
-]New value: +[
+  "status",
+  "query",
+  "interpreted_as",
+  "searched_at",
+  "results",
+  "total",
+  "available",
+  "sources",
+  "note"
+]
  2. Changed18 schema fields changed
    • removedInput schema / properties / domain
      Removed value: -{
-  "maxLength": 100,
-  "minLength": 1,
-  "type": "string"
-}
    • addedInput schema / properties / kind
      Added value: +{
+  "default": "all",
+  "description": "Search all sources, downloadable datasets, or statistical series",
+  "enum": [
+    "all",
+    "dataset",
+    "statistics"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / limit / maximum
      Previous value: -50New value: +20
    • changedInput schema / properties / query / description
      Previous value: -"Words in Japanese or English"New value: +"What data to find, preferably in Japanese"
    • changedInput schema / properties / query / maxLength
      Previous value: -200New value: +80
    • changedInput schema / properties / query / minLength
      Previous value: -1New value: +2
    • removedInput schema / properties / sourceId
      Removed value: -{
-  "maxLength": 100,
-  "minLength": 1,
-  "type": "string"
-}
    • addedInput schema / required
      Added value: +[
+  "query"
+]
    • addedOutput schema / properties / available
      Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • removedOutput schema / properties / catalog_version
      Removed value: -{
-  "type": "string"
-}
    • removedOutput schema / properties / matches
      Removed value: -{
-  "items": {},
-  "type": "array"
-}
    • addedOutput schema / properties / note
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / query
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / results
      Added value: +{
+  "items": {},
+  "type": "array"
+}
    • addedOutput schema / properties / searched_at
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / sources
      Added value: +{
+  "items": {},
+  "type": "array"
+}
    • addedOutput schema / properties / status
      Added value: +{
+  "const": "ok",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "matches",
-  "total",
-  "catalog_version"
-]New value: +[
+  "status",
+  "query",
+  "searched_at",
+  "results",
+  "total",
+  "available",
+  "sources",
+  "note"
+]
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare it read-only, open-world, and idempotent. The description adds value by specifying data sources ('current metadata from e-Gov Data Portal and Statistics Dashboard') and the output format ('short ranked list with publisher, formats, coverage, usage terms, and official links'), which goes beyond annotation hints.

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?

Single sentence, front-loaded with the primary action, and every phrase adds specific information (sources, output characteristics). No filler or redundancy.

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

Completeness4/5

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

With a read-only search tool and an existing output schema, the description adequately covers functionality and return fields. However, it omits any mention of result limitations, no-results behavior, or default ranking, which would make it more self-contained.

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 67% (query and kind described, limit missing). The description does not compensate by explaining parameter usage or the limit parameter, nor does it clarify search language preferences beyond what the schema already provides.

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 uses a specific verb ('Search') and identifies the exact resources (e-Gov Data Portal and Statistics Dashboard) and output structure (ranked list with publisher, formats, coverage, usage terms, links). This clearly distinguishes it from sibling tools like 'execute' and 'verify'.

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

Usage Guidelines2/5

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

No guidance is provided on when to choose this tool over others. The description does not mention alternatives, exclusions, or use-case context despite having sibling tools (execute, verify) in the same namespace.

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

All Public Data Catalog toolsInspect
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.0
Disambiguation5/5

Each tool targets a distinct concern: execute retrieves data via a contract, search_data queries metadata, and verify checks integrity receipts. No overlap or ambiguity between them.

Naming Consistency4/5

All tool names are lowercase snake_case with a verb-first style (execute, search_data, verify). While not strictly verb_noun, the naming is predictable and consistent, though a less uniform pattern than the calibration example.

Tool Count5/5

Three tools is a well-scoped set for a public data catalog: search, retrieve, and verify. Each tool serves a necessary role with no bloat or missing core functionality.

Completeness5/5

The domain covers discovering, accessing, and validating public data. search_data finds datasets, execute retrieves them, and verify ensures integrity—covering the full workflow without obvious gaps.

Resources