Skip to main content
Glama

askacharge.com — EV charging network

by com.askacharge
OverviewDiscussionsAdmin

Crear un grupo de tarifa

askacharge_crear_tarifa

Crea un grupo de tarifa y devuelve el grupo creado con su id. Rellena solo el precio del modo elegido: per_kwh usa price_per_kwh, per_hour usa price_per_hour, per_session usa price_per_session, combined suma los de kWh y hora, pvpc_margin suma pvpc_margin al PVPC (solo España), market_margin suma pvpc_margin al mercado diario de la zona de la marca (solo zonas con precio y marcas que cobran en EUR; si no, 400), tou cobra por franjas horarias que defines en periods (hora local de la marca; price_per_kwh es el precio de las horas sin franja), cost_plus suma pvpc_margin a lo que le cuesta la luz a la marca en cada momento (exige haberlo configurado) y free no cobra nada. Los modos que cambian con la hora cobran cada kWh a su precio. CUIDADO: con is_default en true, la que fuera tarifa por defecto deja de serlo. Para ver las que ya existen, askacharge_listar_tarifas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesNombre del grupo, el que se ve en el panel
periodsNoSolo tou: franjas {period_type: valley|flat|peak, price_per_kwh, hour_start 'HH:MM', hour_end 'HH:MM' (igual = todo el día), weekdays '12345' (1=lunes; vacío = todos)}
is_defaultNoSi es true, pasa a ser la tarifa por defecto de la marca y la anterior deja de serlo
pvpc_marginNoMargen por kWh sobre el PVPC (pvpc_margin), el mercado diario (market_margin) o el coste de la luz de la marca (cost_plus)
billing_modeYesCómo se cobra la sesión; decide cuál de los precios de abajo se usa
price_per_kwhNo€ por kWh entregado (modos per_kwh y combined)
price_per_hourNo€ por hora conectado (modos per_hour y combined)
price_per_sessionNo€ fijos por sesión (modo per_session)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / billing_mode / enum
      Previous value: -[
-  "per_kwh",
-  "per_hour",
-  "per_session",
-  "combined",
-  "pvpc_margin",
-  "market_margin",
-  "free"
-]New value: +[
+  "per_kwh",
+  "per_hour",
+  "per_session",
+  "combined",
+  "pvpc_margin",
+  "market_margin",
+  "tou",
+  "cost_plus",
+  "free"
+]
    • addedInput schema / properties / periods
      Added value: +{
+  "description": "Solo tou: franjas {period_type: valley|flat|peak, price_per_kwh, hour_start 'HH:MM', hour_end 'HH:MM' (igual = todo el día), weekdays '12345' (1=lunes; vacío = todos)}",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / pvpc_margin / description
      Previous value: -"Margen en €/kWh sobre el PVPC (pvpc_margin) o sobre el mercado diario (market_margin)"New value: +"Margen por kWh sobre el PVPC (pvpc_margin), el mercado diario (market_margin) o el coste de la luz de la marca (cost_plus)"
  2. Changed2 schema fields changed
    • changedInput schema / properties / billing_mode / enum
      Previous value: -[
-  "per_kwh",
-  "per_hour",
-  "per_session",
-  "combined",
-  "pvpc_margin",
-  "free"
-]New value: +[
+  "per_kwh",
+  "per_hour",
+  "per_session",
+  "combined",
+  "pvpc_margin",
+  "market_margin",
+  "free"
+]
    • changedInput schema / properties / pvpc_margin / description
      Previous value: -"Margen sobre el precio PVPC de cada hora"New value: +"Margen en €/kWh sobre el PVPC (pvpc_margin) o sobre el mercado diario (market_margin)"
  3. Changed6 schema fields changed
    • addedInput schema / properties / billing_mode / description
      Added value: +"Cómo se cobra la sesión; decide cuál de los precios de abajo se usa"
    • addedInput schema / properties / is_default / description
      Added value: +"Si es true, pasa a ser la tarifa por defecto de la marca y la anterior deja de serlo"
    • addedInput schema / properties / name / description
      Added value: +"Nombre del grupo, el que se ve en el panel"
    • addedInput schema / properties / price_per_hour / description
      Added value: +"€ por hora conectado (modos per_hour y combined)"
    • addedInput schema / properties / price_per_kwh / description
      Added value: +"€ por kWh entregado (modos per_kwh y combined)"
    • addedInput schema / properties / price_per_session / description
      Added value: +"€ fijos por sesión (modo per_session)"
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing a real side effect: 'con is_default en true, la que fuera tarifa por defecto deja de serlo'. It also documents a 400 error condition for market_margin in unsupported zones and states the return value (created group with id). Solid behavioral add despite annotations already marking it a non-destructive write.

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?

Front-loaded with the purpose and return value, then systematically walks the nine modes. It is a dense run-on paragraph, but nearly every clause earns its place given nine enum modes to disambiguate; only slight density hurts readability.

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

Completeness4/5

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

For an 8-param creation tool with nine billing modes, the description covers mode semantics, the is_default side effect, an error case, and the return shape. It doesn't mention auth requirements, but nothing essential for correct invocation is missing.

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 baseline is 3, but the description adds real meaning: it maps each billing_mode to the exact price field to fill (per_kwh uses price_per_kwh, combined sums kWh and hour, tou uses periods, etc.). This is genuine interpretation beyond the schema's per-field descriptions.

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 and resource ('Crea un grupo de tarifa y devuelve el grupo creado con su id') and distinguishes itself from the sibling by naming askacharge_listar_tarifas as the way to view existing tariffs. An agent can tell exactly what this does without opening the schema.

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

Usage Guidelines4/5

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

Gives clear context for when to use each billing_mode and routes the agent to askacharge_listar_tarifas for viewing existing ones. It does not explicitly state when not to use it, but the mode-by-mode guidance is substantial and actionable.

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

All askacharge.com — EV charging network toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources