genieacs-mcp

Overview Schema Source Related Servers Discussions Admin

Reboot device

reboot_device

Destructive

Restart a CPE device through GenieACS after a config change or to recover an unresponsive unit. Queues the task and sends a connection request; verify the device returned by reading its UpTime.

Instructions

Reboot a CPE device through GenieACS. Use it when a device needs a restart, for example after a configuration change or to recover an unresponsive device. The device drops its service while it restarts. GenieACS queues the task and sends a connection request at once: status "done" means the device ran it in that session, "queued" means it runs at the device's next inform. A reboot does not confirm the device came back; read Device.DeviceInfo.UpTime (or InternetGatewayDevice.DeviceInfo.UpTime) with refresh_parameter afterwards. Example: reboot_device(device_id="202BC1-BM632w-000001").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "device_id": "<device_id>"
    },
    "name": "reboot_device"
  }
}

Input Schema

Name	Required	Description	Default
`device_id`	Yes	The GenieACS device id (the _id field), exactly as GenieACS stores it, usually OUI-ProductClass-SerialNumber, e.g. "202BC1-BM632w-000001". GenieACS escapes characters other than letters and digits inside the product class and serial as %XX (a "-" there becomes "%2D"), so copy ids from genieacs://devices/list or search_devices rather than typing them.

Output Schema

Name	Required	Description
`task`	No	The task document GenieACS returned.
`status`	Yes	done: the device ran the task in the session GenieACS opened at once. queued: the device did not answer within 3 seconds, so the task runs at its next inform or connection request.
`message`	Yes	What happened, in one sentence.
`task_id`	No	The GenieACS task id; use it with delete_task or retry_task, or look for it in genieacs://tasks/{device_id}.
`device_id`	Yes	The device the task was queued on.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.4.1Oct 29, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / device_id / description

Previous value: -"The exact GenieACS device identifier (_id field). Typically in the format OUI-ProductClass-SerialNumber (e.g. \"00236A-SmartRG585-SMRT00236a42\"). Obtain valid IDs from the genieacs://devices/list resource."New value: +"The GenieACS device id (the _id field), exactly as GenieACS stores it, usually OUI-ProductClass-SerialNumber, e.g. \"202BC1-BM632w-000001\". GenieACS escapes characters other than letters and digits inside the product class and serial as %XX (a \"-\" there becomes \"%2D\"), so copy ids from genieacs://devices/list or search_devices rather than typing them."

addedInput schema / properties / device_id / minLength
```
Added value: +1
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "device_id": {
+      "description": "The device the task was queued on.",
+      "type": "string"
+    },
+    "message": {
+      "description": "What happened, in one sentence.",
+      "type": "string"
+    },
+    "status": {
+      "description": "done: the device ran the task in the session GenieACS opened at once. queued: the device did not answer within 3 seconds, so the task runs at its next inform or connection request.",
+      "enum": [
+        "done",
+        "queued"
+      ],
+      "type": "string"
+    },
+    "task": {
+      "description": "The task document GenieACS returned."
+    },
+    "task_id": {
+      "description": "The GenieACS task id; use it with delete_task or retry_task, or look for it in genieacs://tasks/{device_id}.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "device_id",
+    "status",
+    "message"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.3.3Jun 19, 2026

changedInput schema / properties / device_id / description

Previous value: -"Exact device ID (_id) as known by GenieACS"New value: +"The exact GenieACS device identifier (_id field). Typically in the format OUI-ProductClass-SerialNumber (e.g. \"00236A-SmartRG585-SMRT00236a42\"). Obtain valid IDs from the genieacs://devices/list resource."

First observedv0.0.10Mar 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the destructive/non-idempotent annotations by disclosing that the device loses service during restart, that GenieACS queues the task and issues a connection request immediately, and what 'done' vs 'queued' actually mean. It also explicitly warns that success does not confirm the device came back, which is precisely the kind of trap an agent needs flagged.

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-loads purpose, then triggers, then behavior, then verification guidance — a sensible order with little waste. The trailing example call is slightly redundant given the schema's own example id, a minor trim opportunity.

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?

An output schema exists so return shape needn't be restated, yet the description still explains the status values an agent will encounter and the required follow-up verification step. For a single-parameter destructive tool, nothing needed to invoke or interpret it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and the device_id description already covers format, escaping rules, and sourcing ids from genieacs://devices/list. The description only repeats this via an example call, adding no syntax or constraint beyond the schema, so baseline 3 applies.

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 ('Reboot a CPE device through GenieACS'), which is unambiguous against siblings like connection_request, refresh_parameter, or retry_task. The scope (a full device restart) is clear 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 concrete triggering conditions ('after a configuration change or to recover an unresponsive device') and routes the agent to refresh_parameter to verify recovery. It stops short of naming when not to use it or contrasting with sibling tools such as connection_request for lighter-touch recovery.

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

Deploy Server