Skip to main content
Glama

Geo Reconcile

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Reconcile Wikidata Osm

reconcile_wikidata_osm
Read-onlyIdempotent

Reconcile a set of Wikidata items against OpenStreetMap features of a given tag — the join Wikidata<->OSM community mapping efforts need before editing anything. Give either explicit Q-ids ("qids") or a SPARQL query that selects them ("sparql", must bind ?item to a wd:Q... URI — used to discover an arbitrary class, e.g. "every power station in country X"), plus an OSM tag filter ("osm_filter", e.g. "power=plant"). Fetches each item's coordinate (P625) and labels in the requested languages, searches OSM within radius_m of each, and scores candidates on THREE signals: an existing wikidata= tag (ground truth when present), cross-lingual name agreement, and distance. Returns one of four DISTINCT states per item: "matched" (confident link + evidence), "ambiguous" (2+ plausible candidates, ALL returned with scores — never auto-resolved), "unmatched" (the OSM search completed and found nothing plausible), or "error" (the search did NOT complete — no Wikidata coordinate, the item didn't resolve, or the Overpass call failed/timed out/was capped). "error" is never collapsed into "unmatched": a failed lookup is not evidence a thing is missing from OSM. Read-only — this does not write to Wikidata, Wikipedia or OpenStreetMap.

Input Schema

NameRequiredDescriptionDefault
qidsNoWikidata Q-ids to reconcile, up to 200 — an array of strings or a comma/pipe-joined string (e.g. ["Q162887","Q3650523"] or "Q162887,Q3650523"). Provide this OR "sparql".
sparqlNoA SPARQL SELECT that binds ?item to the Wikidata items to reconcile (up to 200 used) — e.g. "SELECT ?item WHERE { ?item wdt:P31/wdt:P279* wd:Q159719 . ?item wdt:P17 wd:Q230 . }" for every power station (Q159719) in Georgia (Q230). Labels and coordinates are fetched separately per item, so this query only needs to pick the set — it does not need to select labels or coordinates itself. Provide this OR "qids".
radius_mNoSearch radius in metres around each item's coordinate, 10-20000 (default 300). An OSM feature carrying a matching wikidata= tag is still recognised as "matched" even if it falls outside this radius — the tag is ground truth.
languagesNoComma/pipe-joined language codes to compare, e.g. "ka,ru,en" — the shape needed when the same real-world place has different names in different languages (his own example: a Georgian power station named differently in Georgian, Russian and English). Every requested language's label is fetched and compared against every OSM name tag (name, name:<lang>, alt_name, int_name, official_name); a match in ANY requested language counts as name agreement, and the response says which one. Default "en" — pass the full set you actually need, an English-only comparison both misses real matches and can manufacture false ones.
osm_filterYesOSM tag filter(s) candidates must carry, as key=value, e.g. "power=plant" — or several alternatives comma-joined, e.g. "power=plant,power=generator" (OR-ed together). Required.
overpass_timeout_sNoTimeout passed to the Overpass query itself, 5-180 seconds (default 25). Lower it to fail fast over a large area rather than wait.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, but the description adds substantial operational detail: it fetches coordinates and labels, searches OSM within radius, scores candidates on three signals, and returns four distinct states. Crucially, it explicitly separates "error" from "unmatched" and states that a failed lookup is not evidence of absence. This is rich transparency beyond structured metadata.

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 long but dense and front-loaded: purpose first, then input modes, process, and output states. Almost every sentence carries behavioral or operational information, though it could be tightened. It is appropriately sized for a complex reconciliation tool but not maximally concise.

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?

With no output schema, the description takes responsibility for explaining return behavior: four distinct states with clear meanings, candidate scores for ambiguous matches, and the error/unmatched distinction. Combined with rich schema coverage and annotations, an agent has enough to call and interpret this tool correctly. Nothing essential is missing for the stated complexity.

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%, and the schema already documents every parameter in detail, including defaults and formats. The description reinforces some usage (qids vs sparql, osm_filter, languages, radius_m) but adds little parameter-level meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource: reconcile a set of Wikidata items against OpenStreetMap features filtered by tag. It clearly distinguishes the tool from generic entity/research siblings by naming the Wikidata<->OSM join and the matching signals used. An agent can tell exactly what this tool does without opening the schema.

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?

It gives clear context for use — before editing anything in Wikidata/OSM mapping efforts — and explains the two ways to supply items (explicit qids or a SPARQL query). It does not explicitly name alternatives or when-not-to-use cases among siblings, so it falls short of a 5. But the intended situation is well framed.

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

All Geo Reconcile toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources