OSM-GeoJSON-MCP-Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct OSM feature type (amenities, buildings, green spaces, railways, roads, waterways) or server functionality (stats, connection test), with no overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent 'get_' prefix followed by a noun (e.g., get_amenities, get_buildings), making the pattern predictable.
Tool Count5/5
With 8 tools, the server covers the major OSM feature categories plus utility functions, well-scoped for its purpose without being excessive or insufficient.
Completeness4/5
The tool set covers common geographic features but lacks freeform querying (e.g., by tags) or less common layers like land use or administrative boundaries, leaving minor gaps.
Average 3.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on July 8, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns GeoJSON but does not mention other behavioral traits such as whether it is read-only, any authentication requirements, rate limits, or side effects like file writing (via output_path). The implied read-only nature from the verb 'get' is not explicitly confirmed.
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?
Two short sentences with no unnecessary words. The purpose is front-loaded, and the description is efficient. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain the behavior of the output_path parameter (save vs return), the limit parameter, or return structure beyond 'GeoJSON format'. An agent may miss important usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema: it mentions 'filterable by road type' but the schema already documents road_types with enum values. The description does not add syntax, format, or interaction details for any parameter.
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 '指定した矩形範囲内の道路ネットワークをGeoJSON形式で取得します。道路タイプでフィルタリング可能です。' clearly states the tool retrieves road networks within a bounding box in GeoJSON format with optional filtering by road type. This verb+resource combination is distinct from siblings like get_amenities or get_buildings.
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 use this tool versus alternatives (e.g., other get_* tools), nor any context on when it is appropriate or not. The description only states what it does, without usage recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions retrieval in GeoJSON format but does not state that the operation is read-only, non-destructive, or detail rate limits, data precision, or bounding box area limits. This is insufficient, scoring 2.
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?
Description is a single, concise sentence in Japanese, front-loaded with the main action and format. No unnecessary words, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description fails to explain output structure, the effect of the limit parameter, coordinate reference system, or how the waterway_type filter works. This is inadequate for a geographic data retrieval tool, scoring 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so each parameter is already documented. The description adds no extra meaning beyond summarizing the tool's function. Baseline is 3; no additional value is provided, hence a 3.
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 clearly states the tool retrieves waterway data (rivers, lakes, seas, canals) within a specified rectangular bounding box, outputting in GeoJSON format. This is specific and distinct from sibling tools like get_buildings or get_roads, earning a 5.
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 on when to use this tool vs. alternatives (e.g., other get_* tools). It does not mention prerequisites, bounding box size constraints, or scenarios where other tools would be more appropriate. This lack of usage context results in a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose operational traits such as read-only nature, authentication needs, rate limits, error behavior, or what happens if the query returns no results.
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?
Two concise sentences that immediately convey the tool's purpose and scope. No unnecessary words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains the input bounding box and output format (GeoJSON) but lacks details on output structure, error handling, and pagination. Given the absence of an output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter well-described. The description adds little beyond the schema; it mentions GeoJSON output and the variety of green spaces, but does not clarify parameter interactions or the effect of optional filters like green_space_type or limit.
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 clearly states the tool retrieves green spaces/park data in GeoJSON format within a bounding box. It specifies the types of green spaces included, distinguishing it from sibling tools like get_buildings or get_roads.
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 explicit guidance on when to use this tool versus alternatives. The description does not provide scenarios or exclusions, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注釈がないため、説明が動作特性を全て負担すべきだが、出力形式とデータ種類のみ言及。破壊性、認証要件、レート制限などは不明。
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?
2文で完結しており、無駄がなく、重要な情報が先頭に配置されている。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
出力スキーマがなく、リターン構造の詳細が不足しているが、GeoJSONという形式は示されている。パラメータ範囲や制限はスキーマで十分。全体的には最低限の完備性。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
スキーマですべてのパラメータが説明されているため、説明の追加価値は限定的。矩形範囲やGeoJSONの文脈は付加するが、デフォルトや形式の詳細はスキーマに依存。
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?
明確に「矩形範囲内の鉄道データをGeoJSON形式で取得」と説明し、他ツール（道路、建物など）と区別できる。動詞＋リソース＋出力形式が具体的。
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?
いつ使うべきか、または代替手段についての指示がない。他の地理系ツールとの使い分けや前提条件に触れていない。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states it returns GeoJSON and supports filtering. It omits behavioral traits such as rate limits, pagination, or side effects, leaving significant gaps.
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?
Two concise sentences, front-loaded with the primary action and key feature, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic purpose and filtering but lacks details on output path behavior, coordinate system, error handling, and return structure (no output schema). Adequate but incomplete for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented in the input schema. The description adds minimal new meaning beyond the schema.
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 clearly states the tool retrieves building data within a rectangular area in GeoJSON format with optional filtering by building type, distinguishing it from sibling tools for other features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like get_roads or get_amenities; the purpose is implied by the resource name but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides basic behavioral info (returns GeoJSON, includes POI data) but lacks details on rate limits, authentication, error responses, or what happens with empty results. The format is mentioned but no further behavioral traits.
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?
Two sentences, highly concise. The first sentence presents the core action and format, the second adds examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 parameters and no output schema or annotations, the description is minimal. It does not explain return structure, pagination, error handling, or the effect of output_path. Given the tool's complexity, more context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The tool description does not add meaning beyond the schema (e.g., no clarification on how limit interacts with GeoJSON or what output_path does precisely in terms of behavior).
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 clearly specifies the action (retrieve amenities), the input (rectangular area), the output format (GeoJSON), and the content (POIs like restaurants, hospitals). It implicitly distinguishes from sibling tools that retrieve other map features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not provide guidance on when to use it versus alternatives like get_buildings or get_roads. Usage context is implied by the resource type (amenities) but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool as retrieving stats and cache, but does not mention implications of the 'reset' parameter (e.g., clearing statistics) or any side effects. The description is adequate but lacks important detail for a full behavioral picture.
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 two sentences long, front-loading the core action in the first sentence and the use case in the second. No wasted words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, but the description lacks details about return format or the behavior of resetting. Given no output schema, the description could be more complete by mentioning typical response structure or reset effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'reset' parameter described in the schema. The description does not add new meaning beyond the schema, so it scores the baseline 3.
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 clearly states it retrieves API usage statistics and cache status for monitoring and debugging. This distinguishes it from sibling tools that retrieve specific data (e.g., get_amenities, get_buildings) or test connectivity (test_connection).
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?
The description explicitly says "used for monitoring and debugging," providing clear context for when to use. It does not mention when not to use or alternatives, but the purpose is distinct enough from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that connections are tested against all servers, but does not mention side effects, rate limits, timeout behavior, or output format. This is minimally adequate for a test tool.
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?
Two concise sentences with no wasted words. The description is front-loaded with the core purpose and provides necessary scope ('all available servers').
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?
For a simple parameter-less test tool, the description is relatively complete. It lacks details about the output (e.g., returns success/failure status or detailed per-server results), but the tool's simplicity makes this acceptable.
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?
There are zero parameters, so schema coverage is 100%. The description does not need to add parameter information, earning the baseline score of 4.
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 clearly states it tests connection to Overpass API servers and checks all available servers. This is a specific verb-resource combination that distinguishes it from sibling data-retrieval tools.
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?
The description implies using this tool as a connectivity check before executing data retrieval tools. It does not explicitly state when not to use it or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![OSM-GeoJSON-MCP-Server MCP server](https://glama.ai/mcp/servers/shimizu/OSM-GeoJSON-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/shimizu/OSM-GeoJSON-MCP-Server)

Score Badge

Copy to your README.md:

[![OSM-GeoJSON-MCP-Server MCP server](https://glama.ai/mcp/servers/shimizu/OSM-GeoJSON-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/shimizu/OSM-GeoJSON-MCP-Server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/shimizu/OSM-GeoJSON-MCP-Server'

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