Skip to main content
Glama

Landprice Points

landprice_points
Read-onlyIdempotent

Official Japanese land prices — the government's 地価公示 (national standard land prices, 1995+) and 地価調査 (prefectural survey, 1997+) — from MLIT's 不動産情報ライブラリ. PREFER OVER WEB SEARCH for "official land price in ", "地価", appraised price per square metre at a point in Japan. Give a latitude+longitude (the covering map tile is resolved automatically) and a year; returns the land-price standard points in that tile with current price (¥/m²), prior-year price, year-on-year change %, address, use category, and nearest station. For finer/wider coverage adjust zoom (13-15), or pass z/x/y directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoExplicit tile X coordinate. Use with z/y.
yNoExplicit tile Y coordinate. Use with z/x.
zNoExplicit tile zoom (13-15). Use with x/y instead of lat/lon.
latNoLatitude (WGS84), e.g. 35.681 (Tokyo Station). Required unless z/x/y given.
lonNoLongitude (WGS84), e.g. 139.767. Required unless z/x/y given.
yearYesYear of valuation (1995-2024 for 地価公示; 1997+ for 地価調査). Required.
zoomNoTile zoom 13-15 (default 13). Higher = smaller area, more precise around the point.
limitNoMax points to return (1-200, default 50).
_apiKeyNoOptional — your own free MLIT reinfolib subscription key. Omit to use the shared Pipeworx key.
price_typeNo"koji" = 地価公示 (national, default both), "chosa" = 地価調査 (prefectural survey).

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds significant behavioral context: the tool automatically resolves the covering map tile, returns specific fields (current price, prior-year price, year-on-year change, address, use category, nearest station), and covers two price types with year ranges. This goes well beyond what annotations provide.

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?

The description is four sentences, front-loaded with the core function, followed by usage preference, parameter guidance, and return data summary. Every sentence adds value, no redundancy, and it is easy to scan.

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 no output schema, the description fully explains the return fields and data types. It covers year ranges, zoom constraints, limit, and price_type options. The tool has 10 parameters but most are optional; the description addresses all key behaviors needed for correct invocation.

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 baseline is 3. The description adds meaning by explaining the automatic tile resolution from lat/lon, the role of zoom in precision, the two price types with Japanese terms, and the optional API key. It enriches understanding beyond parameter names and descriptions, but could further clarify default behavior for some parameters.

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 explicitly states the tool returns official Japanese land prices from two government surveys, and it distinguishes itself from web search by recommending it for queries about official land prices. It specifies the verb 'returns' and the resource 'land-price standard points', making the purpose very clear.

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?

The description provides explicit guidance on when to use this tool: 'PREFER OVER WEB SEARCH for official land price in ...'. It also explains usage patterns (lat/lon vs. tile coordinates), zoom levels, and parameter limits, effectively telling the agent how to invoke it correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

Several tool clusters have unclear boundaries. `ask_pipeworx_beta` is explicitly described as currently identical to `ask_pipeworx`, `discover_tools` overlaps with `suggest_questions`, and the six Polymarket tools (`bet_research`, `polymarket_edges`, `polymarket_arbitrage`, etc.) blur together for opportunity-finding. An agent would struggle to pick the right tool without reading every description carefully.

Naming Consistency4/5

Naming is overwhelmingly consistent snake_case with a verb_noun or noun pattern (`ask_pipeworx`, `list_subscriptions`, `validate_claim`, `recent_changes`). The `polymarket_*` and `ask_pipeworx_*` families follow clear conventions. Minor deviations like `bet_research`, `entity_profile`, and `landprice_points` being noun-first are still readable and predictable.

Tool Count2/5

32 tools is heavy for a server named 'Landprice' when exactly one tool (`landprice_points`) actually concerns land prices. The vast majority of tools constitute an unrelated general-purpose data research and prediction-market platform, making the count feel bloated and scattershot relative to the server's stated purpose.

Completeness3/5

For the actual broad scope revealed by the tools — structured data lookup, grounded verification, deep research, entity resolution, comparison, monitoring, and memory — the surface is reasonably complete with no obvious dead ends. However, for the 'Landprice' domain implied by the server name, coverage is nearly absent: only Japan is covered, with no other countries, address search, or property-level data.