An AI agent that watches and resets your chargers

What the agent will do

The typical case of an installer running several sites: a hotel in Madrid and another in Barcelona under the same brand. We want an agent that looks after Madrid only and, when a charger hangs, does what a technician would do over the phone:

1. See which chargers it has and what state they are in.
2. Reset the one that is failing.
3. Check that it really came back, not just that the charger said "OK".
4. If it doesn't come back, tell a person.

And nothing else: no touching Barcelona, no changing prices, no firmware updates.

1. The key: only what it needs

The agent signs in with one of the brand's API keys, created in the dashboard (API Keys menu) by choosing its permissions. This agent needs two:

Every OCPP command is a separate permission (commands:remote-start, commands:firmware…), and the @location suffix limits which chargers it reaches. Since 29 September it also limits what the key sees: charger, session and command listings only return its location, and anything that aggregates the whole brand (the dashboard summary, analytics) answers 403.

2. Connect it over MCP

The MCP server lives at https://askacharge.com/askacharge/api/mcp. It is plain HTTP (JSON-RPC over POST): nothing to install, and the key goes in the Authorization: Bearer ask_live_… header. In Claude Code, for example:

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

This is what the agent gets when it lists the tools with that key:

// tools/list — real response, 29 Sep 2026
askacharge_listar_cargadores
askacharge_ver_cargador
askacharge_estado_comando
askacharge_reiniciar_cargador
askacharge_llamar_api

Five of the server's 25. The ones its key cannot use (starting sessions, creating tariffs, the dashboard summary) are not listed, so the model cannot misuse a tool it doesn't know about. askacharge_llamar_api reaches the rest of the API, under the same permissions. Tool names are in Spanish; their descriptions tell the model when to use each.

3. See the network

askacharge_listar_cargadores returned the two Madrid chargers (DEMO-SIM-01 and DEMO-SIM-02), each with its OCPP status, the status of every connector and whether it is connected right now ("online": true). The Barcelona charger, in the same brand, was not listed.

4. Reset it and check that it came back

The agent resets 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 only means the charger received the order. What matters is whether it comes back, and that is what the job_id is for. The agent polls askacharge_estado_comando every few seconds:

// seconds since the reset → job status
 0 s  acked
 3 s  acked
 …
18 s  acked
21 s  confirmed

// the confirmed job
"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"
}

After 21 seconds the charger reconnected, and the job moved to confirmed with the event that proves it. Had it not come back in time, the job would have ended in timeout, which is the agent's cue to call a person instead of resetting again.

5. When it tries to step outside its patch

We asked it to reset the Barcelona charger:

// 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.

("This API key has no permission on location 'hotel-barcelona'. It can only act in: hotel-madrid.") The message says what happened and where the permission ends, so the model can explain it instead of retrying. And if it asks for the brand's dashboard through the back door (askacharge_llamar_api on /api/brand/dashboard/summary), that fails too: its key has no sessions permission.

6. Everything is logged

Every write by a key and every refused attempt is kept for 90 days in the activity log (dashboard → API Keys, or GET /api/brand/api-keys/audit). This test left two lines: the Madrid reset (200, 41 ms) and the Barcelona attempt (403). Successful reads are not logged: an agent makes hundreds.

Running it for real

• Get notified instead of asking. In the test the agent polled the job every few seconds. In production, the natural trigger is a webhook on charger.offline (sent when a charger disconnects or stops sending heartbeats) that wakes the agent up. Webhooks are signed with X-AskaCharge-Signature (HMAC-SHA256) so your receiver can check they come from us.
• Make retries safe. Agents retry when something is slow. Send every write with an Idempotency-Key header: if the same request arrives twice, the second one returns the first response instead of resetting again.
• Grant autonomy in steps. Start read-only (chargers:read) and let it propose; then resets in one location; later, starting and stopping sessions. What we would never give an unsupervised agent: commands:firmware, commands:configuration, tariffs:write, billing or keys:write, which would let it mint its own keys.
• Limits worth knowing. 300 requests per minute per key. The MCP server offers no streaming event channel: events arrive by webhook. The dashboard is in Spanish only. And a location-scoped key cannot see the brand's dashboard summary or analytics, because they aggregate every location.

The full reference (permissions, commands, events and the 468 API operations) is in the technical documentation.