Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Tracks U.S. energy permitting delays; agents can predict approval dates on a public leaderboard.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Funktioniert in Claude im Web, auf dem Desktop und auf dem Handy:
https://waitingforpower.com/mcpFühre das in deinem Terminal aus
claude mcp add --transport http energy-permitting-tracker https://waitingforpower.com/mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"energy-permitting-tracker": {
"url": "https://waitingforpower.com/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"energy-permitting-tracker": {
"type": "http",
"url": "https://waitingforpower.com/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
ChatGPT verbindet sich nur mit Servern im Internet:
https://waitingforpower.com/mcpMenünamen können sich je nach Tarif und mit der Zeit leicht unterscheiden.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Die Tool-Liste dieses Servers haben wir noch nicht gelesen; wir prüfen die Endpunkte reihum.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde über die Domain waitingforpower.com bestätigt (die Registry prüft, wem die Domain gehört)
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir lesen die Tool-Liste, wenn wir den Endpunkt prüfen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft in der Cloud des Entwicklers. Du verbindest dich übers Internet, ohne etwas zu installieren, aber was du sendest, läuft über die Server des Entwicklers.
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (1.2.0) kam vor 2 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Er verbindet sich per URL, also funktionieren auch Apps, die Remote-MCP-Server akzeptieren, zum Beispiel ChatGPT im Entwicklermodus.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, LexPact UK Contracts
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Generate UK-law contracts: NDA, service, freelance, recruiter terms of business, IR35.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
Open source, MIT licensed — see LICENSE. Contributions, forks, and issues welcome.
Tracks proposed U.S. energy projects — generation, transmission, storage, LNG, and pipelines, every fuel type — and how long each has been waiting for approval, and why.
The argument is structural, not partisan: solar, wind, storage, gas, nuclear, hydro, LNG, pipelines, and transmission all get stuck in the same handful of bottlenecks. Every tracked delay is mapped to one of seven named cause categories (src/lib/data/causeCategories.ts). The site's policy argument — six specific, bipartisan reform proposals, one per structural bottleneck, each with a stated problem, proposal, strengths, weaknesses, and bill links — lives on a single page, /policies (src/lib/data/policies.ts), deliberately kept separate from the neutral cause-category data so "why a project is stuck" and "what we're arguing should change" aren't the same object.
npm install
cp .env.example .env # set DATABASE_URL to your own Postgres instance npx prisma migrate deploy # applies the committed migrations to your database npm run ingest:permitting-dashboard # populate from a live, no-key-needed source npm run dev
Needs a real Postgres connection string in DATABASE_URL — there's no bundled local database file. The deployed app and local dev both point at the same hosted Postgres instance for this project (see "Architecture" below for why); for your own fork, any Postgres works (Neon, Supabase, Vercel/Prisma Postgres, RDS, local postgres via Docker, etc.).
All project data comes from live, re-runnable sources — no hand-curated one-off research. An earlier version of this project shipped a small hand-researched seed set; it was removed deliberately in favor of sources that stay current on their own, rather than a snapshot that goes stale. See src/lib/ingest/README.md for the full per-source table, open questions, and how each is scheduled:
| Source | Module | Checked | Source's own publish cadence |
|---|---|---|---|
| EIA-860M "Planned" generator inventory | src/lib/ingest/eia860mPlanned.ts | Cron weekly (13:00 UTC Sundays), /api/cron/ingest-eia | Monthly, ~2-month lag on EIA's end |
| Federal Permitting Dashboard (FAST-41) | src/lib/ingest/permittingDashboard.ts | Cron daily (14:00 UTC), /api/cron/ingest-permitting-dashboard | Live API — no periodic file, effectively real-time |
| LBNL Queued Up | src/lib/ingest/lbnlQueuedUp.ts | Cron weekly (15:00 UTC Sundays), /api/cron/ingest-lbnl | ~Annual |
| ORNL HydroSource hydropower relicensing | src/lib/ingest/ornlHydropowerRelicensing.ts | Cron weekly (16:00 UTC Sundays), /api/cron/ingest-ornl-hydro | ~Annual |
| EIA Natural Gas Pipeline Projects tracker | src/lib/ingest/eiaPipelineProjects.ts | Cron weekly (17:00 UTC Sundays), /api/cron/ingest-eia-pipelines | ~Quarterly |
| Virginia SCC CPCN dockets | src/lib/ingest/vaSccDockets.ts | Cron daily (18:00 UTC), /api/cron/ingest-va-scc. First of a planned per-state series covering state PUC/PSC dockets, the structural bottleneck this site's other sources can't see (see open question #10). | Live API, but only one state so far |
| Texas PUCT CCN dockets | src/lib/ingest/txPuctDockets.ts | Cron daily (18:30 UTC), /api/cron/ingest-tx-puct. Second state in the series — higher-volume than Virginia but with no structured status field, so "still waiting" is inferred from filing history (see file header for how that was calibrated). | Server-rendered HTML, no auth |
| Colorado PUC CPCN dockets | src/lib/ingest/coPucDockets.ts | Cron daily (19:00 UTC), /api/cron/ingest-co-puc. Third state — the cleanest yet: status is a real structured field already present in search results, no filing-history inference needed at all. | Server-rendered HTML, no auth |
| Ohio Power Siting Board cases | src/lib/ingest/ohOpsbCases.ts | Cron daily (19:30 UTC), /api/cron/ingest-oh-opsb. Fourth state — the simplest fetch yet (one unauthenticated JSON request returns the entire case history), and the first source in the series where both status and fuel/project type are real structured fields, not inferred. | Single JSON endpoint, no auth |
| South Carolina PSC siting-certificate dockets | src/lib/ingest/scPscDockets.ts | Cron daily (20:00 UTC), /api/cron/ingest-sc-psc. Fifth state — like Texas, has no reliable status field, but its captions are unusually descriptive (facility type, capacity, county spelled out in the text), and "still waiting" is inferred from an embedded Orders sub-table rather than a full filing-history scan. | Server-rendered HTML, no auth |
| Arizona ACC Line Siting Committee dockets | src/lib/ingest/azAccLineSiting.ts | Cron daily (20:30 UTC), /api/cron/ingest-az-acc. Sixth state — a real JSON API, but with the same "status field lies" problem as South Carolina, independently rediscovered: docketStatus can read "Open" on a docket that's actually been decided. The real signal is a separate decisions array. | Real JSON API, no auth |
| Washington EFSEC facility site-certifications | src/lib/ingest/waEfsecFacilities.ts | Cron daily (21:00 UTC), /api/cron/ingest-wa-efsec. Seventh state — Washington's own utility commission (WUTC) turned out to have no siting-certificate authority at all; the real authority is a separate body, EFSEC, whose small (19-facility) all-time list is ingested directly. The one state so far where the *structured* status field is the reliable one and a free-text description was the one caught lying. | Server-rendered HTML, no auth |
| New Mexico PRC CCN dockets | src/lib/ingest/nmPrcDockets.ts | Cron daily (21:30 UTC), /api/cron/ingest-nm-prc. Eighth state — a real JSON API behind an Angular SPA front-end, found by capturing the app's own network requests. Its CCN category also catches water-utility certificates and intake-rejected duplicate filings, both filtered out locally; its status field held up under testing, unlike several other states here. | Real JSON API, no auth |
| Illinois ICC CPCN dockets | src/lib/ingest/ilIccDockets.ts | Cron daily (22:00 UTC), /api/cron/ingest-il-icc. Ninth state — its CPCN case-type bucket also catches declaratory-ruling and eminent-domain petitions, filtered locally; capacity is published as voltage (kV), not MW, a first for this series. Its Grain Belt Express docket is the same physical line as an existing Permitting Dashboard entry — the case that surfaced and fixed a real cross-source merge bug, see open question #1. | Server-rendered HTML, no auth |
| Florida PSC + DEP siting certification | src/lib/ingest/flPscDockets.ts | Cron daily (22:30 UTC), /api/cron/ingest-fl-psc. Tenth state — Florida has no CPCN at the PSC at all; siting runs through a separate DEP process the PSC only opens with a small "determination of need" sub-docket. Two agencies' pages are cross-checked against each other, and — unusually for this series — it's the *state-docket agency's own* status field that lies, while a second agency's page is the reliable one. | Real JSON API (PSC) + server-rendered HTML (DEP), no auth |
| New York DPS Article VII/VIII dockets | src/lib/ingest/nyDpsDockets.ts | Cron daily (23:00 UTC), /api/cron/ingest-ny-dps. Eleventh state — two live siting-certificate tracks (transmission under Article VII, renewable generation under Article VIII/its predecessor § 94-c) in one system, covered by one module. Publishes no status field at all, and the renewable track's grant order isn't even filed as an Order/Decision — it's a plain correspondence filing, found only by scanning every document title regardless of type. | Real JSON API, no auth |
| Nevada PUCN UEPA permit dockets | src/lib/ingest/nvPucnDockets.ts | Cron daily (23:30 UTC), /api/cron/ingest-nv-pucn. Twelfth state — no CPCN; Nevada's equivalent is a Utility Environmental Protection Act permit spanning two separate PUCN systems (a legacy WebForms docket list plus a modern OnBase JSON API). Its multi-phase transmission reviews (an already-"GRANTED" phase followed by a new phase filing months later) required a real "no later substantive filing" check, not just "does any order say GRANTED." | Legacy ASP.NET WebForms + real JSON API (OnBase), no auth |
| Oregon EFSC facility site-certifications | src/lib/ingest/orEfscFacilities.ts | Cron daily (00:00 UTC), /api/cron/ingest-or-efsc. Thirteenth state — like Washington, Oregon's own utility commission has no siting authority; the real body is the Energy Facility Siting Council. Unusually, *both* of its structured status fields turned out unreliable (37 of 97 facilities disagreed between them) — the real signal is a free-text narrative field instead. One current candidate, Cascade Renewable Transmission, is the same physical HVDC line already tracked via Washington's EFSEC module — merged via manualOverrides.csv. | Real JSON API (SharePoint REST), no auth |
| Massachusetts EFSB dockets | src/lib/ingest/maEfsbDockets.ts | Cron daily (00:30 UTC), /api/cron/ingest-ma-efsb. Fourteenth state — like Washington/Oregon, the state's DPU itself isn't the real siting authority; a board (EFSB) that sits administratively inside DPU issues the actual certificate. Its own "Closed Date" field can stay null for years after a real grant, so resolution is instead inferred from scanning every filed document's own type for a "Final Decision." | Real JSON API, no auth |
| Oklahoma OCC High Voltage Transmission COA dockets | src/lib/ingest/okOccDockets.ts | Cron daily (01:00 UTC), /api/cron/ingest-ok-occ. Fifteenth state — no generic CPCN; Oklahoma's own "CCN" relief type is used almost exclusively by telecom carriers, and the real electric-siting equivalent is a narrower "High Voltage Transmission COA" certificate — only 4 cases have ever been filed under it since 2022, all already resolved as of shipping, a real (not buggy) zero-candidate result. | Real JSON API (Laserfiche WebLink), no auth |
| Utah PSC CPCN dockets | src/lib/ingest/utPscDockets.ts | Cron daily (01:30 UTC), /api/cron/ingest-ut-psc. Sixteenth state — across Utah's entire electric-docket history back to 1987, only 12 dockets are genuine new CPCN applications and all 12 are already granted, another real zero-candidate result (PacifiCorp/Rocky Mountain Power's resource decisions go through Integrated Resource Plan acknowledgment instead). No PDF-parsing dependency exists in this project, so final orders (unstructured PDFs) are read by decompressing their own FlateDecode streams directly with Node's built-in zlib. | Server-rendered HTML, no auth |
| Wisconsin PSC CPCN / Certificate of Authority dockets | src/lib/ingest/wiPscDockets.ts | Cron daily (02:00 UTC), /api/cron/ingest-wi-psc. Seventeenth state — both the large-facility CPCN and smaller-facility Certificate of Authority processes share one docket case-type code. PSC's own "Status" field is a records-retention lifecycle flag, not a case-decision flag — dockets decided 7+ years ago still show "Active" indefinitely; the real signal is a filed order titled "Final Decision." | Server-rendered HTML (ASP.NET WebForms), no auth |
| Kentucky PSC CPCN / Certificate of Construction dockets | src/lib/ingest/kyPscDockets.ts | Cron daily (02:30 UTC), /api/cron/ingest-ky-psc. Eighteenth state — unusually, its "Include Closed" search filter turned out to be reliable, verified both directions against real dockets; used as the primary status signal for the first time in this series, with a text-based grant/deny scan kept as a defensive secondary check anyway. | Server-rendered HTML (ASP.NET MVC), no auth |
| Missouri PSC Certificate of Convenience and Necessity dockets | src/lib/ingest/moPscDockets.ts | Cron daily (03:00 UTC), /api/cron/ingest-mo-psc. Nineteen
Nur der Anfang wird gezeigt; den Rest findest du im Repo