The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Geo Reconcile listing page.
Reconciles Wikidata items against OpenStreetMap features — the join a
community mapping effort needs before linking or adding anything. Give a set
of Wikidata Q-ids (or a SPARQL selector that picks out an arbitrary class,
e.g. "every power station in country X") and an OSM tag filter; get back one
of four DISTINCT verdicts per item — matched, ambiguous, unmatched, or
error — scored on an existing wikidata= tag, cross-lingual name agreement,
and distance. Built generic; Georgian power stations are the first proving
case, not the scope.
Part of Pipeworx — an MCP gateway connecting AI agents to 1683+ live data sources.
reconcile_wikidata_osm({qids | sparql, osm_filter, languages, radius_m, overpass_timeout_s}) —
resolves each Wikidata item's coordinate (P625) and labels in the requested
languages, runs one Overpass bbox search for osm_filter covering every
item, and classifies each item:
matched — a confident link, with the evidence: an existing wikidata=
tag (ground truth) or name agreement + distance.ambiguous — 2+ plausible OSM candidates (or 2+ OSM features already
tagged with the SAME Wikidata item, a data conflict) — ALL returned with
scores, never auto-resolved.unmatched — the OSM search completed and nothing plausible was there.error — the search did NOT complete for this item: it didn't resolve
on Wikidata, carries no coordinate, or the Overpass call
failed/timed-out/was capped. Never collapsed into unmatched — a failed
lookup is not evidence of absence.Keyless. All three upstreams (Wikidata API, Wikidata Query Service, OpenStreetMap Overpass API) are free and require no key.
Overpass calls are relayed through Pipeworx's egress proxy when the gateway
provides one — overpass-api.de answers 429 then 521 to direct Cloudflare
Worker egress while returning 200 to the same request from elsewhere
(observed against this same host, fleet #1246; also true of the standalone
overpass pack). A standalone (non-gateway) deployment of this pack calls
Overpass directly and works from any non-Cloudflare-Worker environment
without relay configuration.
The OSM leg fails over across public Overpass instances — overpass.kumi.systems,
then maps.mail.ru, then overpass-api.de — via the helper shared with the
overpass pack (shared/src/overpass.ts). kumi went dark ~2026-09-19 and
overpass-api.de 406s our egress (fleet #2036), so with only those two the OSM
leg was dead from then until fleet #2451 added mail.ru.
action=wbgetentities) — labels and
the P625 coordinate claim for each resolved item.sparql is given instead of qids.Notes for the next person:
wikidata= tag that points at a DIFFERENT item than the one being
reconciled is treated as negative evidence, not ignored. OSM sometimes
models several Wikidata-listed units as one combined feature (e.g. Georgia's
Vartsikhe I–IV are four separate Wikidata items but the OSM ways for I, II
and IV nearby are already tagged for Vartsikhe's aggregate Wikidata item,
Q4104053) — silently letting name+distance "match" a unit to that already-
claimed feature would tell a mapper to re-tag something that is correctly
tagged for something else. Any such conflict forces the candidate's score to
0 (excluding it from matched/ambiguous) and is surfaced separately in
nearby_conflicting_tags so a human can see the granularity mismatch rather
than have it silently disappear.remark field and partial (sometimes
empty) elements — read naively, that is byte-for-byte indistinguishable
from "genuinely found nothing". This pack checks remark for
timeout/rate-limit/runtime-error language and treats a match there as a
failed call (every affected item becomes error), never as a real empty
result.out center tags <N>; is capped (currently 4000 elements) rather than
left unbounded, because an unbounded query over a large area can itself be
the thing that times out. If Overpass returns exactly the cap, cap_hit is
set on the response and any item that would otherwise have come back
unmatched is reported as error instead — completeness for that area is
not guaranteed under a capped result, so "nothing found" is not a claim this
pack is willing to make.sparql selector only needs to bind ?item. Labels and coordinates
are always fetched separately via wbgetentities, so the SPARQL does not
need to select them itself — this keeps the selection query simple and
reuses one consistent label/coordinate path regardless of how the item set
was chosen.wikidata= tag matching
one of them — all 23 were recovered as matched, zero false positives. 87
items had no P625 coordinate yet (a real, current gap in the Wikidata data,
not a bug here) and correctly came back error, not unmatched.nwr["power"="plant"]["wikidata"] Overpass query returns 27
features carrying 24 distinct wikidata= values. Twenty-three of those 24
items are in the class selection above (wdt:P31/wdt:P279* wd:Q159719,
wdt:P17 wd:Q230) and all 23 come back matched, every one justified by
the existing tag rather than by name+distance. The 24th is Q4104053, the
aggregate Vartsikhe plant — the same granularity mismatch described two
bullets up. It is absent because the selector never asked about it, not
because the pack lost it. Compare against the reconciled item set, not
against a bare Overpass count, or you will chase a phantom.Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):
tools/list at https://gateway.pipeworx.io/geo-reconcile/mcp returns the tools in the table
above plus the shared Pipeworx meta-tools — ask_pipeworx,
discover_tools, search_within, remember/recall and the rest of the
gateway-wide set. So the tool count you see is larger than this table: a
single-pack endpoint currently lists roughly 30 shared tools alongside the
pack's own. The connection's initialize response states its exact scope, and
is the authoritative answer for a given day.
This is deliberate, not multiplexing by accident. The meta-tools are what let a
scoped connection answer a question this pack does not cover — via
ask_pipeworx, which routes across the whole catalog — without you adding a
second MCP server. There is currently no way to mount a pack endpoint without
them; if the extra schemas cost you more context than the routing is worth,
connect to the full gateway once rather than to several pack endpoints.
Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:
Both URLs reach the same gateway and the same 1683+ data sources. The
only difference is which pack's tools are listed directly; ask_pipeworx
reaches all of them from either one.
No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/reconcile_wikidata_osm. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.
This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:
Or run it directly to confirm it starts:
It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call
for only this pack's tools — none of the shared meta-tools the gateway
connection above adds. Same source, same tools, no ask_pipeworx routing.
Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:
The gateway picks the right tool and fills the arguments automatically.
MIT