geo mcp servers

Abstract

A curated, tracked list of Model Context Protocol (MCP) servers for geospatial, GIS, mapping, and earth-observation work — geocoding, routing, PostGIS, STAC/imagery, QGIS/ArcGIS, weather, and the commercial location platforms.

The Problem

Maintaining an up‑to‑date catalog of Model Context Protocol (MCP) servers is tedious when each entry lives in a separate repository or spreadsheet. Clients need a single source of truth that can be edited, validated, and automatically rendered into a consumable README without manual copy‑paste.

What This Does

This repository stores the catalog in servers.yaml and the server health states in health.json.

scripts/generate_readme.py reads both files, builds Markdown tables, and overwrites the tables in README.md.
scripts/check_health.py compares commit dates in the listed server repos to the current date, updates health.json, and tags each server as active, stale, hosted, pending, or archived.
The generated README is the single document that clients consume, and the skill in skill/ can query that document on demand.

How It Is Wired

Entry Point	File	Key Function	What It Touches	Notes
`scripts/generate_readme.py`	`generate_readme.py`	`main()` → `load_yaml()` → `load_json()` → `build_table()` → `write_markdown()`	Reads `servers.yaml`, `health.json`; writes to `README.md`	All logic resides in a single script; no external dependencies beyond stdlib + `PyYAML`.
`scripts/check_health.py`	`check_health.py`	`main()` → `load_yaml()` → `get_repo_last_push()` → `update_health()` → `write_json()`	Reads `servers.yaml`; updates `health.json`	Relies on `git` command line to fetch the last push date of each repo.
`skill/SKILL.md`	`SKILL.md`	N/A (skill manifest)	References the repository location via a symlink.	No runtime code here; the skill is a separate Claude Code package.
`.github/workflows/verify.yml`	`verify.yml`	`python scripts/check_health.py` → `python scripts/generate_readme.py`	Ensures health data and README are in sync on push.	Runs on every commit to `main`.

The wiring is linear: a script triggers the next script; both scripts operate on the same two data files. There are no cycles or shared mutable states beyond the files themselves.

How To Use It

Setup

git clone https://github.com/moses-y/geo-mcp-servers.git
cd geo-mcp-servers
python3 -m venv .venv && ./.venv/bin/pip install -r requirements.txt   # first time only

Health Check

./.venv/bin/python scripts/check_health.py

Generate Updated README

./.venv/bin/python scripts/generate_readme.py

Both scripts are idempotent; rerunning them keeps README.md current. No environment variables are required; all configuration lives in servers.yaml and health.json.

Real‑World Use

A GIS operations team can keep the catalog in sync by running the two scripts on a nightly cron. The resulting README.md can be embedded in a Confluence page, or the catalog can be exposed via the Claude skill:

User: "List all open‑source MCP servers for routing."
Claude: "Here are the open‑source servers: ... "

The skill reads the same servers.yaml file, ensuring the skill’s output never diverges from the catalog.

Code Health & Issues

Medium (High) – No tests – scripts/ directory – All code paths are exercised only by manual runs.
Low – No lockfile – requirements.txt – Builds are non‑reproducible if a package releases a breaking change.
Low – CI missing test stage – .github/workflows/verify.yml – The workflow only checks health and README generation, not syntax or linting.

No licensing or secret material is present. The workflow relies on git and python; no external services are required.

The Bottom Line

The repo provides a lightweight, self‑contained catalog of MCP servers with automated health checks and README generation. It is ideal for teams that need a single, editable source of truth and a quick way to present it. The lack of tests and lockfiles limits reliability for production‑grade automation, but for documentation and skill integration the current setup suffices.