Un agente de IA que vigila y reinicia tus cargadores

Qué va a hacer el agente

El caso típico de un instalador que lleva varios sitios: un hotel en Madrid y otro en Barcelona bajo la misma marca. Queremos un agente que se ocupe solo del de Madrid y que, cuando un cargador se quede colgado, haga lo que haría un técnico por teléfono:

1. Ver qué cargadores tiene y en qué estado están.
2. Reiniciar el que falla.
3. Comprobar que ha vuelto de verdad, no solo que el cargador dijo "vale".
4. Si no vuelve, avisar a una persona.

Y que no pueda hacer nada más: ni tocar Barcelona, ni cambiar precios, ni actualizar firmware.

1. La key: solo lo que necesita

El agente entra con una API key de la marca. Se crea en el panel (menú API Keys) eligiendo los permisos. Para este agente bastan dos:

Cada comando OCPP es un permiso aparte (commands:remote-start, commands:firmware…), y el sufijo @ubicacion limita a qué cargadores alcanza. Desde el 29 de septiembre también limita lo que ve: los listados de cargadores, sesiones y comandos solo devuelven su ubicación, y lo que junta toda la marca (el panel resumen, la analítica) le responde 403.

2. Conectarlo por MCP

El servidor MCP está en https://askacharge.com/askacharge/api/mcp. Es HTTP normal (JSON-RPC sobre POST): no hay nada que instalar, y la key va en la cabecera Authorization: Bearer ask_live_…. En Claude Code, por ejemplo:

claude mcp add --transport http askacharge https://askacharge.com/askacharge/api/mcp \
  --header "Authorization: Bearer ask_live_…"

Esto es lo que recibe el agente al pedir la lista de herramientas con esa key:

// tools/list — respuesta real, 29-sep-2026
askacharge_listar_cargadores
askacharge_ver_cargador
askacharge_estado_comando
askacharge_reiniciar_cargador
askacharge_llamar_api

Cinco de las 25 que tiene el servidor. Las que su key no puede usar (arrancar cargas, crear tarifas, el panel resumen) no aparecen: el modelo no puede equivocarse con una herramienta que no conoce. askacharge_llamar_api da acceso al resto de la API, con los mismos permisos.

3. Ver la red

askacharge_listar_cargadores devolvió los dos cargadores de Madrid (DEMO-SIM-01 y DEMO-SIM-02), cada uno con su estado OCPP, el de cada conector y si está conectado ahora mismo ("online": true). El de Barcelona, que estaba en la misma marca, no salió.

4. Reiniciar y comprobar que ha vuelto

El agente reinicia DEMO-SIM-01:

// askacharge_reiniciar_cargador {"charge_point_id": "DEMO-SIM-01", "reset_type": "Soft"}
{
  "status": "Accepted",
  "job_id": "8b58ec4c-1347-42b1-b7d1-579d9fc8d237"
}

Accepted solo significa que el cargador ha recibido la orden. Lo que importa es si vuelve, y para eso está el job_id. El agente pregunta con askacharge_estado_comando cada pocos segundos:

// segundos desde el reinicio → estado del job
 0 s  acked
 3 s  acked
 …
18 s  acked
21 s  confirmed

// el job confirmado
"status": "confirmed",
"expected_event": "charger.online",
"event": {
  "event": "charger.online",
  "charge_point_id": "DEMO-SIM-01",
  "location_name": "Hotel Madrid",
  "status": "Available",
  "previous_status": "Unavailable"
}

A los 21 segundos el cargador se volvió a conectar, y el job pasó a confirmed con el evento que lo demuestra. Si no hubiera vuelto en su plazo, el job habría quedado en timeout, y esa es la señal para que el agente avise a una persona en vez de reiniciar otra vez.

5. Cuando intenta salirse de lo suyo

Le pedimos que reinicie el cargador de Barcelona:

// askacharge_reiniciar_cargador {"charge_point_id": "DEMO-SIM-03"}  →  isError: true
Esta API key no tiene permiso sobre la ubicación 'hotel-barcelona'.
Solo puede actuar en: hotel-madrid.

El mensaje dice qué ha pasado y hasta dónde llega el permiso, así que el modelo puede explicárselo al usuario en vez de insistir. Y si le pide el panel general de la marca por la puerta de atrás (askacharge_llamar_api a /api/brand/dashboard/summary), tampoco: su key no tiene permiso de sesiones.

6. Todo queda apuntado

Cada escritura de una key y cada intento rechazado se guardan 90 días en la traza de actividad (panel → API keys, o GET /api/brand/api-keys/audit). De esta prueba quedaron dos líneas: el reinicio de Madrid (200, 41 ms) y el intento sobre Barcelona (403). Las lecturas correctas no se apuntan: un agente hace cientos.

Para ponerlo en marcha de verdad

• Que le avisen, en vez de preguntar. En la prueba el agente consultaba el estado del job cada pocos segundos. En producción, lo natural es suscribir un webhook a charger.offline (sale cuando un cargador se desconecta o deja de mandar latido) y despertar al agente con él. Los webhooks van firmados con X-AskaCharge-Signature (HMAC-SHA256) para que tu receptor compruebe que vienen de nosotros.
• Que reintentar no repita. Un agente reintenta cuando algo tarda. Manda cada escritura con una cabecera Idempotency-Key: si la misma petición llega dos veces, la segunda devuelve la respuesta de la primera en vez de reiniciar otra vez.
• Dale autonomía por escalones. Empieza con solo lectura (chargers:read) y que proponga; después, reinicio en una ubicación; más tarde, arrancar y parar cargas. Lo que no le daríamos nunca a un agente sin supervisión: commands:firmware, commands:configuration, tariffs:write, billing ni keys:write, que le permitiría crearse sus propias keys.
• Límites que conviene saber. 300 peticiones por minuto por key. El servidor MCP no ofrece un canal de eventos en streaming: los eventos llegan por webhook. Y una key limitada a una ubicación no puede ver el panel resumen ni la analítica de la marca, porque juntan todas las ubicaciones.

La referencia completa (permisos, comandos, eventos y las 468 operaciones de la API) está en la documentación técnica.