Spanish grid access capacity (CNMC maps): nearby substations with capacity for demand or generation.
Scored across 3 tools
The three tools target distinct access patterns: spatial search around a location (buscar_capacidad), a per-node ficha via barra_id (detalle_nudo), and a top-N ranking by capacity for a region/gestor (ranking_nudos). The only mild overlap is that buscar_capacidad and ranking_nudos both return lists of nodes with MW, but the descriptions clearly separate 'near this parcel' from 'where is there room in this province/Spain'.
All names are Spanish snake_case, which is coherent, but the patterns are mixed: buscar_capacidad is verb_noun while detalle_nudo and ranking_nudos are noun_noun. A consistent scheme (e.g. buscar_nudos / detalle_nudo / ranking_nudos) would be more predictable.
Three tools for a narrow, read-only data domain (CNMC access-capacity maps) is lean but each has a clear job: location search, node detail, and regional ranking. It is slightly on the thin side but nothing feels redundant or missing at the surface level.
Coverage is solid for the stated purpose: discovery by place, drill-down per node including monthly evolution, and reverse lookup by capacity ranking, all with clear data caveats. Minor gaps exist — no direct lookup of a node by substation name, no filtering by technology/demand-vs-generation as an explicit parameter, and no cross-node comparison/export — but agents can work around these via the ranking and detail tools.
Capacidad eléctrica disponible cerca de un lugar de España: nudos de la red (subestaciones) más cercanos a una dirección, municipio, parcela o referencia catastral, ordenados por distancia, con los MW disponibles para conectar nueva demanda (consumo) o nueva generación según el último mapa de capacidad de acceso publicado por la CNMC.
Úsala cuando pregunten si hay capacidad eléctrica, potencia disponible o punto de conexión para
una parcela, nave, vivienda, cargadores, planta fotovoltaica, baterías o centro de datos. Si se
conoce la potencia del proyecto, pásala siempre en potencia_kw (la de la pregunta: 15 kW, 2 MW).
Devuelve por nudo: subestación, tensión (kV), gestor de red, distancia (km), capacidad disponible
de cada barra y máximo por barra (MW), y en generación el nudo de transporte del que depende
(nudo_afeccion_rdt). 'en_radio' cuenta cuántos nudos del radio tienen capacidad y cuántos no:
al responder, da las dos cifras, no solo los nudos favorables. Usa 'barra_id' con detalle_nudo
para ver la ficha y su evolución mensual.
Límites del dato: capacidades informativas y NO sumables entre nudos; no incluye centros de
transformación ni baja tensión, así que para potencias pequeñas no confirma el suministro; las
solicitudes se tramitan con el gestor de red de cada nudo.| Name | Required | Description | Default |
|---|---|---|---|
| red | No | Red de distribución (≤ 132 kV, distribuidoras), de transporte (220/400 kV, Red Eléctrica) o ambas. | ambas |
| uso | No | 'demanda' para consumir (nave, cargadores, electrolizador, centro de datos, bomba de calor); 'generacion' para inyectar (fotovoltaica, eólica, almacenamiento vertiendo). | demanda |
| limite | No | Máximo de nudos devueltos. | |
| radio_km | No | Radio de búsqueda en km. | |
| ubicacion | Yes | Dónde: dirección ('Calle Castilla 10, Santander'), población o municipio ('Reinosa'; si el nombre existe en varias provincias añade ', Provincia'), referencia catastral de 14 o 20 caracteres, o coordenadas 'lat, lon' en grados decimales. | |
| potencia_kw | No | Potencia del proyecto en kW, si se conoce (15 para una vivienda o un taller, 2000 para 2 MW). Con ella cada nudo indica si alguna de sus barras la cubre, y para potencias pequeñas se avisa de que el mapa no decide. | |
| tension_min_kv | No | Tensión mínima de la barra en kV. Útil para descartar barras que no sirven a la potencia del proyecto. | |
| solo_con_capacidad | No | Si es true, omite los nudos sin capacidad disponible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/open-world; the description goes much further by disclosing that capacities are informational and NOT additive across nodes, that transformation centres and low voltage are excluded so small loads are not confirmed, and that applications are handled by each node's network operator. It even instructs how to report results ('da las dos cifras, no solo los nudos favorables'), which prevents a misleading answer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage triggers, then return shape, then data limits — a logical order where every paragraph earns its place. It is dense and long for a tool description, but the density is informational rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description carries the full burden of explaining returns, and it does so field by field (subestación, tensión, gestor, distancia, capacidad por barra, nudo_afeccion_rdt) plus the meaning of en_radio. Combined with the stated data limits, an agent has everything needed to call it and to interpret results responsibly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3; the description adds real guidance beyond it by insisting potencia_kw be supplied whenever the project's power is known ('pásala siempre en potencia_kw') and by naming the units to use (15 kW, 2 MW). It also links the output field barra_id to detalle_nudo, which the schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: nearest grid nodes (subestaciones) to a Spanish location, ordered by distance, with available MW for demand or generation per the CNMC map. It distinguishes scope from the sibling detalle_nudo by naming it explicitly for per-node drill-down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions ('Úsala cuando pregunten si hay capacidad eléctrica, potencia disponible o punto de conexión') and lists concrete project types (parcela, nave, cargadores, fotovoltaica, baterías, centro de datos). It routes to detalle_nudo for follow-up but never mentions the sibling ranking_nudos, so the alternative-selection picture is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ficha completa de un nudo: capacidad por barra para demanda y para generación (si el nudo figura en ambos mapas), ocupada, comprometida y pendiente de evaluar, posiciones libres, nudo de transporte del que depende, y la evolución mes a mes desde que hay histórico.
Datos de los mapas de capacidad de acceso de la CNMC. Límites del dato: capacidades informativas
y NO sumables entre nudos; no incluye centros de transformación ni baja tensión; las solicitudes
se tramitan con el gestor de red del nudo.| Name | Required | Description | Default |
|---|---|---|---|
| barra_id | Yes | Identificador del nudo tal como lo devuelven buscar_capacidad o ranking_nudos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, and the description adds substantive domain constraints the agent could not otherwise know: capacities are informative and not summable across nodes, transformation centres and low voltage are excluded, and requests go through the node's grid operator. Those caveats materially affect how results should be reported, though nothing is said about response size or truncation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, the first front-loading what the record contains and the second carrying the data caveats. Dense enumeration but nothing that reads as filler; the only mild drag is the long comma-separated field list in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return shape, and it does by listing the fields and noting the monthly historical series plus the conditional case where a node appears in both demand and generation maps. The sourcing from CNMC access-capacity maps is stated. Remaining gaps are minor, such as units and the historical range start.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 100% schema coverage, the schema already documents the format, the hex pattern, and where the identifier comes from. The description body adds no further meaning about barra_id, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and enumerates its contents: capacity per busbar for demand and generation, occupied/committed/pending states, free positions, dependent transport node, and monthly evolution. That is far more specific than the name alone. It stops short of naming its siblings, though the barra_id schema text ties it to buscar_capacidad and ranking_nudos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the reader infers this is the follow-up call once an identifier is known, reinforced by the parameter description pointing at buscar_capacidad and ranking_nudos. There is no explicit statement of when to use this versus those siblings, nor any exclusion such as what to do when a node is in only one capacity map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nudos con mayor capacidad disponible (máximo por barra) en una provincia, de un gestor, o en toda España, según los mapas de capacidad de acceso de la CNMC. Sirve para localizar dónde hay hueco en la red eléctrica (para demanda o para generación) antes de buscar emplazamiento.
Límites del dato: capacidades informativas y NO sumables entre nudos; no incluye centros de
transformación ni baja tensión; las solicitudes se tramitan con el gestor de red de cada nudo.| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Número de nudos. | |
| red | No | Red. | distribucion |
| uso | No | Demanda o generación. | demanda |
| gestor | No | Gestor de red por nombre parcial ('Viesgo', 'i-DE') o código ('R1-005'). | |
| provincia | No | Provincia (coincidencia parcial: 'Cantabria', 'Valencia'). Vacío para toda España. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful domain caveats beyond that: capacities are informative and NOT summable across nodes, transformation centres and low voltage are excluded, and permitting goes through each node's operator. It stops short of describing result ordering or pagination behaviour.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs: the first front-loads what the tool returns and why, the second carries the data limitations. No filler, and the caveats are separated so they are easy to retain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does enough by naming the returned entity (nodes with highest available capacity, max per bar) and the filters. It does not spell out the returned fields or ordering, which would help an agent interpret the ranking, but nothing essential for calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five parameters are already documented, including that an empty provincia means all of Spain. The description reinforces the filter framing (province / operator / all Spain) and the 'máximo por barra' notion but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (rank nodes by highest available capacity), the scope (a province, a grid operator, or all of Spain) and the data source (CNMC access-capacity maps). An agent immediately knows this is a ranking/locator tool rather than a detail lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear use case: locate where there is headroom in the grid (for demand or generation) before searching for a site. It does not explicitly name the sibling tools (buscar_capacidad, detalle_nudo) or state when not to use it, so routing between siblings is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buscar_capacidaddetalle_nudoranking_nudosDated European data-centre markets, grid connection restrictions, country rules and the live grid.
NESO MCP — Great Britain electricity grid open data (api.neso.energy)
Electricity Maps MCP — real-time electricity-grid carbon intensity + power generation mix for 200+…
European power-market data: day-ahead & balancing prices, load, generation, flows, outages. 47 zones
Add one secure layer between your agents and this server.