Skip to main content
Glama
kkawailab

MLIT Data Platform MCP Server

by kkawailab

get_data

Retrieve detailed metadata and related fields for specific data entries from Japan's MLIT Data Platform using dataset and data IDs.

Instructions

データセットIDとデータIDを用いて、データの詳細情報を取得する。

            使い方:
            - 検索API(search)で拾った id を使って、対象データの詳細(title 以外の各種メタ情報や関連フィールド)を取得。
            - すでに対象が確定している場合、検索よりも効率的に必要情報へアクセスできます。

            例:
            - 既知IDで詳細取得:
            dataset_id="cals_construction", data_id="<searchで取得したid>"

            - データセット内の特定データを直接参照:
            dataset_id="mlit-001", data_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

            注意:
            - 引数は GraphQL の data(dataSetID:, dataID:) に対応しています。
            - data_id は search の結果(DataClass.id)を使用してください。
            - 存在しないIDを指定した場合、totalNumber=0 となり結果は返りません。
            - 詳細項目は MLIT DPF のスキーマに依存します(必要な項目はクライアント側でフィールド選択推奨)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataset_idYesデータセットID
data_idYesデータID

Implementation Reference

  • The implementation of the get_data tool, which queries the MLIT Data Platform for specific data details given a dataset_id and data_id.
    async def get_data(self, dataset_id: str, data_id: str) -> Dict[str, Any]:
        q = f"""
        query {{
        data(dataSetID: "{dataset_id}", dataID: "{data_id}") {{
            totalNumber
            getDataResults {{
            id
            title
            metadata
            files {{ id original_path }}
            hasThumbnail
            tileset {{
                url
                altitude_offset_meters
            }}
            }}
        }}
        }}
        """.strip()
        return await self.post_query(q)
  • Handler in src/server.py that invokes the MLITClient's get_data method.
    elif name == "get_data":
        p = GetDataParams.model_validate(arguments)
        data = await client.get_data(p.dataset_id, p.data_id)
  • Input parameter validation for the get_data tool.
    class GetDataParams(BaseModel):
        dataset_id: str = Field(..., alias="dataset_id")
        data_id: str = Field(..., alias="data_id")
Behavior4/5

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

With no annotations provided, the description carries the full burden and discloses several behavioral traits: GraphQL API correspondence (data(dataSetID:, dataID:)), error handling for non-existent IDs (totalNumber=0), and schema dependency (MLIT DPF). Deducting one point because it doesn't explicitly confirm read-only/safety status or mention rate limits, though 'get' implies safe read semantics.

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?

Perfectly structured with four distinct, front-loaded sections: purpose statement, usage guidelines, concrete examples, and technical notes. Every sentence earns its place without redundancy. The length is appropriate for the tool's complexity and the lack of output schema annotations.

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?

Given 2 simple parameters with full schema coverage and no output schema, the description is comprehensive. It explains what is returned (title以外の各種メタ情報), error conditions, schema dependencies, and client-side recommendations (フィールド選択推奨). No critical gaps remain for an AI agent to invoke this tool correctly.

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% (both parameters have descriptions), establishing a baseline of 3. The description adds value by specifying data_id provenance (must come from search results DataClass.id), providing concrete examples (dataset_id='cals_construction', data_id UUID format), and mapping to GraphQL parameter names.

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?

Description opens with a specific verb+resource combination (データの詳細情報を取得する/retrieve detailed data information) and explicitly defines the required inputs (dataset_id and data_id). It clearly distinguishes this from siblings by contrasting with the search API (検索APIで拾ったidを使って), establishing this as a direct retrieval tool versus a discovery tool.

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?

Contains an explicit '使い方' (Usage) section stating exactly when to use this tool versus alternatives: 'すでに対象が確定している場合、検索よりも効率的' (When the target is already determined, more efficient than search). It explicitly names the sibling tool 'search' as the prerequisite source for IDs, creating a clear workflow distinction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kkawailab/kklab-mlit-dpf-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server