OpenStreetMap Tagging Schema MCP Server

Server Quality Checklist

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

Latest release: v3.9.5
Disambiguation5/5
Each tool has a clearly distinct purpose: compare, convert formats, get details, get values, search, suggest, and validate. Even overlapping areas like search vs. get are well-differentiated by scope and use case.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_tags, get_preset_details, validate_tag_collection), making them predictable and easy to understand.
Tool Count5/5
With 10 tools, the set is well-scoped for the server's purpose—comprehensive without being overwhelming. Each tool serves a necessary function in the OSM tagging workflow.
Completeness5/5
The tool set covers the full lifecycle of working with OSM tagging schema: searching, retrieving details, validating, suggesting improvements, comparing, and format conversion. No obvious gaps for the intended domain.
Average 4.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under GPL 3.0.
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 provided, and description does not disclose whether the tool is read-only or has side effects. For a validation tool it likely is safe, but lack of explicit behavioral context reduces transparency.
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?
Three sentences, front-loaded with core purpose. Concise but could be slightly tighter without losing clarity.
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 no output schema, description adequately hints at return value (validation results, deprecation warnings, collection-level issues) and covers the tool's complexity for its intended use.
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%, but description adds value by explaining the three input formats for tags and the effect of options (summary, verbose), providing context 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?
Description clearly states it validates a complete collection of OSM tags, performs batch validation, checks deprecated tags and conflicts, distinguishing it from single-tag validation (validate_tag) or comparison (compare_tags).
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?
Describes when to use (before uploading to OSM, data quality analysis) but does not explicitly state when not to use or mention alternative sibling tools like validate_tag for single tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 transparently discloses the analysis steps (identify feature type, match preset, compare tags, suggest missing fields) and implies a read-only operation. It does not mention side effects, permissions, or rate limits, but the context (analysis tool) makes destructive behavior unlikely. Slightly more explicit read-only confirmation would elevate the score.
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?
The description is a single dense paragraph that efficiently conveys the tool's functionality. It is front-loaded with the core action. While concise, it could benefit from bullet points or clearer separation of steps for even quicker scanning, but it is not overly verbose.
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?
There is no output schema, so the description must explain return values. It mentions 'prioritized improvement suggestions with explanations and example values', but lacks specifics about the output structure (e.g., whether it returns an array of objects, fields like 'tag', 'reason', 'example'). Given the tool's complexity, more detailed return format expectations would improve completeness.
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?
The input schema provides complete descriptions for both parameters (tags and options) with 100% coverage, so the description adds no additional parameter semantics. The baseline score of 3 is appropriate as the schema already explains parameter meaning and formats.
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 specific verbs ('analyze', 'provide suggestions', 'identifies', 'compares', 'suggests') and clearly defines the resource ('OpenStreetMap tag collection'). It distinguishes itself from siblings by describing a unique analysis workflow (finding matching OSM presets, comparing against requirements), which is not covered by other tools like validate_tag_collection or compare_tags.
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 states use cases: 'enhance incomplete features, learn best practices, or improve data quality'. This provides clear when-to-use guidance. However, it does not mention when NOT to use the tool or alternatives for specific scenarios, which would strengthen the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it performs a read-only comparison, provides human-readable names using OSM schema, and returns structured diff. It also explains options like diffFormat and showUnchanged, giving a clear picture of what the tool does and how its output can be controlled.
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?
The description is two sentences plus a list of use cases. It is front-loaded with the core purpose. While it could be slightly more concise, it efficiently conveys necessary information without 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?
The tool has 3 parameters, nested objects, no output schema, and no annotations. The description covers purpose, usage, behavior, and parameter options. It mentions 'returns structured diff' but does not detail the exact structure; however, the options help infer the output. Most aspects are adequately addressed.
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%, so the baseline is 3. The description adds context about accepted formats (JSON or flat text) and diff formats, but these are already covered in the schema descriptions. The description does not introduce new parameter meaning beyond what's in 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 compares two sets of OSM tags and identifies differences, additions, deletions, and modifications. It specifies the verb 'compare' and the resource 'OpenStreetMap tags', and it is distinct from sibling tools like flat_to_json or validate_tag.
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 lists use cases: reviewing tag changes, understanding feature modifications, analyzing tag history, and validating tag transformations. However, it does not mention when not to use this tool or suggest alternative tools for other tag operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: it returns matching presets with names, primary tags, geometry types, and match scores. No destructive actions are indicated, and the output fields are disclosed.
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?
The description is three sentences, front-loaded with the main purpose. It explains presets and usage efficiently without excessive wording. Minor redundancy could be tightened, but overall concise.
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?
No output schema exists, so the description compensates by listing returned fields (names, primary tags, geometry types, match scores). It covers filtering by keyword, tags, and geometry. Adequate for a search tool with nested parameter.
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?
All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds context like preset examples and use cases, but does not add significant new meaning beyond what the schema 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 clearly states the tool searches for presets by name, tags, or geometry type, and provides examples like 'Restaurant'. It distinguishes from sibling tools like search_tags and get_preset_details by focusing on finding complete preset templates.
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 advises using the tool to find correct presets, discover tagging, or explore templates. It does not explicitly state when not to use it or point to alternatives, but the context of siblings implies appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the output: one tag per line, sorted alphabetically, in key=value format. States all values must be strings. Without annotations, this provides adequate behavioral context, though edge cases (e.g., empty tags) are not addressed.
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?
The description is front-loaded with purpose and provides necessary context in a few sentences. Slight redundancy (e.g., 'human-readable' repeated) but overall efficient.
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 low complexity (1 parameter, no output schema), the description covers the transformation, output format, and compatibility, making it self-sufficient for an agent to invoke 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 coverage is 100% so baseline is 3. The main description does not add new parameter details beyond the schema; it focuses on usage. The schema description already covers the parameter meaning.
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 converts JSON tags to flat text (key=value per line) and identifies itself as an output converter. It distinguishes from siblings like flat_to_json by specifying it's for final presentation/export.
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?
Explicitly says to use it 'LAST' in workflows for human-readable or export purposes, and lists compatible OSM tools. However, it does not explicitly mention alternatives like flat_to_json or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: 'Handles various text formats including key=value pairs (one per line), whitespace variations, empty lines, and comments (lines starting with #). Returns a clean JSON object with all parsed tags.' It discloses input handling and output, but does not mention error handling or limits.
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?
The description is a single paragraph of 4 sentences, front-loaded with the core purpose. It is informative without unnecessary words, though slightly more structure (e.g., bullet points) could improve readability.
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 converter with one parameter and full schema coverage, the description provides sufficient context: input format, handling of various text artifacts, and output. It could mention the JSON structure (e.g., object with keys/values), but it's mostly complete.
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?
The description adds meaning beyond the schema by explaining the expected format (key=value per line) and noting that empty lines, comments, and whitespace are handled. Since schema coverage is 100%, the description complements it well.
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 'Convert OpenStreetMap tags from flat text format... to JSON object format.' It uses specific verb 'Convert', specifies resource 'OpenStreetMap tags', and distinguishes itself as an input converter for AI workflows, differentiating from sibling tools like 'json_to_flat'.
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 'use it FIRST when you receive tags in flat text format and need to work with them as a JSON object.' It provides clear context for when to use the tool, though it does not explicitly mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It lists all returned information categories (tags, fields, geometry types, parent/child), sufficiently disclosing what to expect. No contradictions.
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?
The description is front-loaded with the main purpose, then explains presets, then lists what is returned, then usage. It is slightly verbose but well-structured and informative without 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?
Given no output schema, the description adequately covers return values (tags, fields, geometry types, parent/child). It might miss mentioning any pagination or error conditions, but for a simple retrieval tool it is mostly complete.
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% (baseline 3). The description adds value by explaining the preset ID pattern (key/value) and giving examples (e.g., 'amenity/restaurant'), and referencing search_presets for finding IDs. This goes beyond simple 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 detailed information about an OpenStreetMap preset, explains what a preset is, and lists the comprehensive information returned. It distinguishes from siblings like search_presets (which finds IDs) by focusing on details retrieval.
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 provides clear use cases: understanding tagging, learning available fields, getting example values. It implicitly contrasts with search_presets for finding IDs but does not explicitly state when not to use or list alternatives beyond the sibling tools context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly describes the validation steps and what results include (localized names, actionable messages), implying a read-only, non-destructive operation. It does not explicitly state idempotency, but that is reasonable for a validation 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?
The description is two paragraphs with clear structure: purpose in first sentence, bullet-like list of validations, and use cases. Every sentence adds value, no redundant text.
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?
Given no output schema, the description sufficiently covers return value content (detailed results, localized names, messages). It addresses input parameters adequately and fits within the context of sibling tools. Could be more specific about output structure, but overall complete.
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%, but the description adds valuable context about OSM formatting (colons for namespaces), case sensitivity for keys and values, and value checking against options. This enhances understanding beyond the schema definitions.
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 it validates a single OSM tag key-value pair against the schema, listing specific validations (deprecation, schema existence, option validation, field type checking). It distinguishes from siblings like validate_tag_collection and compare_tags by focusing on individual tags.
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 recommends use for educational purposes, data quality checks, or before bulk operations, indicating when to use it. It implicitly contrasts with validate_tag_collection for multiple tags, but doesn't explicitly exclude other scenarios or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: it searches both predefined field options and preset definitions, supports simple and namespaced keys, is case-sensitive, and returns four specific pieces of information. This goes well beyond the basic operation, providing rich behavioral context.
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?
The description is information-dense and each sentence contributes value, starting with the primary action. It could be slightly shorter by removing redundant phrases like 'to find every documented value' after already stating the schema search, but overall it's well-structured and not excessively verbose.
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 the absence of an output schema, the description thoroughly explains the return format (four pieces of information). It covers all important aspects: search scope, key types, case-sensitivity, and parameter usage. The parameter count and high schema coverage are fully leveraged, making the description self-sufficient.
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. The description adds value beyond schema by giving examples for tagKey (e.g., 'amenity', 'addr:street'), explaining case-sensitivity, and for options.limit, it clarifies purpose and performance benefit. This extra guidance elevates the score.
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 specific verb 'Retrieve' and resource 'all possible values for a specific OpenStreetMap tag key'. It differentiates from sibling tools like search_tags (which searches across tags) and get_preset_details (which focuses on presets) by focusing on enumerating all documented values for a single key, making its unique purpose unmistakable.
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 lists three use cases: discovering available values, learning terminology, and building UI lists. It also implies when to use it (e.g., 'Essential for understanding OSM's controlled vocabularies'). However, it does not provide explicit when-not-to-use scenarios or compare alternatives, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: supports fuzzy matching, case-insensitive, partial matching, returns matching tags with keys, values, and names. It does not mention auth needs or rate limits, but overall transparent enough for a search tool.
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?
The description is a paragraph but front-loaded with core functionality. Every sentence adds value, though it could be slightly more concise. Still very good.
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 3 params, no output schema, the description covers search behavior, fuzzy matching, case-insensitivity, return fields, and references sibling tool. It is complete for a search tool.
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%, baseline 3. The description adds meaning beyond schema: keyword is described as single standalone keyword, case-insensitive, partial matching; limit described as max results with performance tip; options.limit described as default unlimited. This adds value.
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 searches for OpenStreetMap tags by keyword/pattern across keys, values, and localized names. It distinguishes from sibling search_presets by specifying that tag pair filtering should use search_presets instead.
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 explicitly tells when to use this tool: to discover tags, find correct tags, explore categories. It also tells when not to use it: for tag pair filtering, use search_presets. This provides clear usage guidance.
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-tagging-schema-mcp MCP server](https://glama.ai/mcp/servers/gander-tools/osm-tagging-schema-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gander-tools/osm-tagging-schema-mcp)

Score Badge

Copy to your README.md:

[![osm-tagging-schema-mcp MCP server](https://glama.ai/mcp/servers/gander-tools/osm-tagging-schema-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gander-tools/osm-tagging-schema-mcp)

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/gander-tools/osm-tagging-schema-mcp'

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