comparador-luz-gas

comparar_ofertas

Read-onlyIdempotent

Compare official CNMC electricity and gas offers by price, using invoice QR or postal code and annual consumption. Get multi-year cost analysis for choosing a cheaper tariff.

Instructions

Consulta el comparador oficial de la CNMC y devuelve las ofertas de luz y/o gas, de la más barata a la más cara, con un análisis a varios años (rotar de oferta, permanencias, fijo vs. tramos). Luz: qr, o cp + consumo; gas: suministro gas, cp + consumo_gas; ambas: lo de luz más consumo_gas. cp, consumo o potencia explícitos prevalecen sobre el qr; sin qr, 3,45 kW y reparto 2.0TD. Con el texto del QR no hace falta leer_factura_qr. Una petición HTTPS sin caché (segundos; límite 90 s); las ofertas cambian con el mercado. Euros, sin desglose de impuestos. Si falla, devuelve un error con texto JSON {"ok": false, "error": "ArgumentoInvalido", "message": "..."} (ArgumentoInvalido si falta cp o consumo; otro si falla la red).

Input Schema

Name	Required	Description
`cp`	No	código postal, p. ej. 28013
`qr`	No	contenido del QR de la factura de luz, ya decodificado: la URL de comparador.cnmc.gob.es que lleva impresa, p. ej. `https://comparador.cnmc.gob.es/comparador/QRE?cp=28013&pP1=4.6&caP1=740...`
`anios`	No	horizonte del análisis a largo plazo (por defecto 3)
`consumo`	No	consumo anual de luz en kWh
`empresa`	No	suministro que no es vivienda
`franjas`	No	consumo anual punta, llano y valle en kWh; por defecto se reparte con el perfil 2.0TD
`mensual`	No	con qr, coste de ese periodo de facturación en vez del anual
`potencia`	No	potencia contratada en kW (por defecto 3.45)
`suministro`	No	qué comparar (por defecto luz); ambas añade las ofertas conjuntas y la alternativa de contratar por separado
`consumo_gas`	No	consumo anual de gas en kWh
`max_ofertas`	No	ofertas a devolver, las más baratas (por defecto 20)
`sin_permanencia`	No	excluir ofertas con permanencia

Output Schema

Name	Required	Description	Default
`ofertas`	Yes
`analisis`	Yes
`consulta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.4Oct 15, 2026

changedInput schema / properties / qr / description

Previous value: -"contenido del QR de la factura de luz, ya decodificado (la URL de comparador.cnmc.gob.es que lleva impresa)"New value: +"contenido del QR de la factura de luz, ya decodificado: la URL de comparador.cnmc.gob.es que lleva impresa, p. ej. `https://comparador.cnmc.gob.es/comparador/QRE?cp=28013&pP1=4.6&caP1=740...`"

Changed2 schema fields changedv0.2.3Oct 15, 2026

addedInput schema / properties / suministro / description

Added value: +"qué comparar (por defecto luz); ambas añade las ofertas conjuntas y la alternativa de contratar por separado"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "analisis": {
+      "type": "object"
+    },
+    "consulta": {
+      "type": "object"
+    },
+    "ofertas": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "consulta",
+    "ofertas",
+    "analisis"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds material context beyond them: an uncached HTTPS call taking seconds with a 90s limit, offers that shift with the market, euro amounts excluding tax breakdown, and a concrete failure contract (`{"ok": false, "error": "ArgumentoInvalido", ...}` with the distinction between missing-argument and network failures).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by parameter routing and then behavioral/error notes. It is dense and semicolon-heavy rather than bloated, but the packed clauses make it slightly harder to scan than a cleanly separated structure would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, zero-required tool with an output schema, the description covers the selection matrix, defaults, precedence, cost model (euros, no tax breakdown), latency, and the failure format. An agent can call it correctly and interpret failures without opening anything else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter interaction logic the schema cannot express: explicit `cp`, `consumo` or `potencia` override the `qr`, and without a `qr` the defaults are 3.45 kW and a 2.0TD split. That precedence rule is genuinely additive, though per-parameter meaning largely lives in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (consulta/compara) and resource (ofertas de luz y gas del comparador oficial de la CNMC), plus the ordering (de la más barata a la más cara) and the multi-year analysis scope. It also explicitly distinguishes itself from the sibling `leer_factura_qr` by noting the QR text is unnecessary here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules: luz needs `qr` or `cp`+`consumo`; gas needs `suministro`=gas plus `cp`+`consumo_gas`; ambas combines them. It names the alternative tool (`leer_factura_qr`) and the condition under which it is not needed, which is exactly the when/when-not guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server