Spec Driven Development
de formulahendry
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Se ejecuta en tu computadora★ 440MITActualizado hace 14 meses
Instalar
WaitingForPower
Resumen
Descripción del creador (original en inglés)
Tracks U.S. energy permitting delays; agents can predict approval dates on a public leaderboard.
Los tres pilares de PopNx MCP
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
- Opinión de usuariosiAún no hay reseñasLas reseñas se abrirán junto con las cuentas en una etapa posterior
- Nuestras revisiones básicasi1 de 1 superadasRevisado con información pública; el código aún no se ha escaneado
- UsoiAún sin medir★ –
Qué puedes hacer con él
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
- Conexión: Se ejecuta en la nube
- Transporte: Streamable HTTP
- Categoría: Otros
Instalación
Elige la app de IA que usas y copia la configuración.
Antes de instalar
- Revisiones básicas: 1 de 1 superadas
- Se ejecuta en el servidor del creador: lo que le pidas pasa por su servidor.
- El registro no indica ninguna clave que completar.
Necesitas
- Se ejecuta en la nubeNo hay nada que instalar; se conecta por internet
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Funciona en Claude para web, escritorio y móvil:
- Abre Settings → Connectors
- Presiona Add custom connector
- Pega la dirección de abajo y presiona Add
- Si te pide iniciar sesión, inicia sesión en el servicio del creador
https://waitingforpower.com/mcpEjecuta esto en tu terminal
claude mcp add --transport http energy-permitting-tracker https://waitingforpower.com/mcpO copia la configuración tú
Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"energy-permitting-tracker": {
"url": "https://waitingforpower.com/mcp"
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
O copia la configuración tú
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"energy-permitting-tracker": {
"type": "http",
"url": "https://waitingforpower.com/mcp"
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
ChatGPT solo se conecta a servidores en internet:
- Abre ChatGPT en la web → Settings → Connectors (Apps)
- Presiona Create o Add (en algunos planes primero hay que activar Developer mode en Advanced)
- Pega la dirección de abajo, ponle un nombre y guarda
- Si te pide iniciar sesión, inicia sesión en el servicio del creador
https://waitingforpower.com/mcpLos nombres de los menús pueden variar un poco según el plan y con el tiempo.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Qué puede hacer
Todavía no hemos leído la lista de herramientas de este servidor; revisamos los endpoints por turnos.
Revisiones básicasi
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 7 nov 2026
- ✓ Superada
El creador coincide con el repo
El nombre en el registro se verificó con el dominio waitingforpower.com (el registro comprueba quién es dueño del dominio)
- … Aún sin revisar
Sigue en mantenimiento
Todavía no hemos leído este repo en GitHub
- … Aún sin revisar
Tiene licencia
Todavía no hemos leído este repo en GitHub
- … Aún sin revisar
El endpoint responde
Aún sin revisar; revisamos los endpoints por turnos
- … Aún sin revisar
Inicio de sesión con OAuth
Aún sin revisar; revisamos los endpoints por turnos
- … Aún sin revisar
Sin instrucciones ocultas en las descripciones de herramientas
Aún sin revisar; leemos la lista de herramientas cuando revisamos el endpoint
Comparado con otros en Otrosi
- Más estrellas que el 0% de los otros 32725 servidores de esta categoría
- Publicado en el registro más recientemente que el 43% de los otros 32725 servidores de esta categoría
- Revisiones básicas iguales o mejores que el 100% de los otros 32725 servidores de esta categoría
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Preguntas frecuentes
¿Es seguro WaitingForPower?
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
¿Qué claves o códigos necesita?
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
¿Se ejecuta en mi computadora o en la nube?
Se ejecuta en la nube del creador. Te conectas por internet sin instalar nada, pero lo que envías pasa por los servidores del creador.
¿Sigue en mantenimiento?
El repo de GitHub cambió por última vez –, y la última versión (1.2.0) llegó al registro hace 2 meses.
¿Qué apps pueden usarlo?
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. Se conecta por URL, así que también funcionan las apps que aceptan servidores MCP remotos, como ChatGPT en modo desarrollador.
¿Qué puedo usar en su lugar?
En la misma categoría: Spec Driven Development, Remote Desktop Commander, Signoff
Alternativas
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
Remote Desktop Commander
de desktop-commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Se ejecuta en la nube★ 211Actualizado anteayer
Instalar
Signoff
de ayuanxx-max
Five gates that make an agent's 'done' provable: run them, read the verdict, audit the record.
Se ejecuta en tu computadoraActualizado hoy
Instalar
README del creador
Abrir el README
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
WaitingForPower — an Energy Project Tracker
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.
Quick start
npm installcp .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.).
Data & sourcing
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
Solo se muestra el principio; lee el resto en el repo