genieacs-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ACS_URL | Yes | GenieACS NBI endpoint URL | http://localhost:7557 |
| ACS_PASS | No | GenieACS admin password | admin |
| ACS_USER | No | GenieACS admin username | admin |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connection_requestA | Send a TR-069 connection request so a CPE device contacts GenieACS now instead of at its next periodic inform. Use it to run tasks that are already queued, or to apply a preset change without waiting. It queues nothing itself. Succeeds when the device answered; fails with ACS error 504 when the device is unreachable (offline, or behind NAT without STUN). Example: connection_request(device_id="202BC1-BM632w-000001"). |
| delete_taskA | Remove a task from the GenieACS queue before the device runs it, for example a firmware download or reboot queued by mistake, or a faulted task you do not want retried. GenieACS already deletes a task once the device has run it, so every task you can see in genieacs://tasks/{device_id} is either waiting or faulted. Fails with ACS error 503 while the device is in a session with GenieACS; try again a few seconds later. Use retry_task instead to run a faulted task again. Example: delete_task(task_id="67abc123def4560012345678"). |
| download_firmwareA | Tell a CPE device to download and apply a file stored on GenieACS: a firmware image, a configuration file or another file the device accepts. A wrong image can leave a device unusable, so check the file's metadata (genieacs://file/{name}: OUI, product class, version) against the device first. GenieACS queues a download task and sends a connection request at once; the transfer itself can take minutes after the tool returns. Check genieacs://tasks/{device_id} and genieacs://faults/{device_id} afterwards. Example: download_firmware(device_id="202BC1-BM632w-000001", file_id="firmware-v2.0.bin"). |
| get_parameterA | Read TR-069 parameter values GenieACS has cached for a device, without contacting the device: firmware version, serial number, uptime, WiFi SSID, IP addresses and so on. Values are what the device reported at its last inform or refresh, with a timestamp each; call refresh_parameter first when you need a value from the device now. Give one path or a comma-separated list; an object path such as "Device.WiFi" returns every cached leaf under it. Returns found=false for an unknown device id, and lists paths with no cached value under missing. |
| manage_presetA | Create, replace or delete a GenieACS preset. A preset is a fleet-wide rule: at their next inform, every device matching its precondition gets its configurations applied, so a broad precondition (or an empty one) reconfigures the whole fleet. Confirm the precondition and the devices it matches (search_devices with the same filter) before a put. action="put" creates or overwrites the preset with body; action="delete" removes it. body is a JSON object: weight (integer, higher wins), precondition (a MongoDB-style filter as a JSON string, e.g. "{"_tags":"office"}"), and configurations (an array of {type: "value" | "provision" | "add_object" | "delete_object", ...}). Example body: {"weight":0,"precondition":"{"_tags":"pilot"}","configurations":[{"type":"provision","name":"myScript"}]}. Read genieacs://presets/list first. |
| manage_provisionA | Create, replace or delete a GenieACS provision script. A provision is JavaScript that GenieACS runs during the inform session of every device a preset applies it to, so replacing one changes how those devices are configured. Scripts use the GenieACS sandbox API (declare, commit, clear, ext, log); ext() calls extension scripts that run on the ACS host with full privileges, so treat a provision as code running on your ACS. action="put" uploads or overwrites the script (raw JavaScript, not JSON; GenieACS answers 400 on a syntax error); action="delete" removes it. Presets reference provisions by name. Read genieacs://provisions/list first. Example script: log("Device " + DeviceID.ID + " informed"); |
| reboot_deviceA | 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"). |
| refresh_parameterA | Ask a CPE device for the current value of a TR-069 parameter, or of every parameter under an object path, and store it in GenieACS. Use it when get_parameter's cached value may be stale. It changes nothing on the device. GenieACS queues a getParameterValues task and sends a connection request at once: status "done" means the fresh value is already stored, so read it with get_parameter; "queued" means it arrives at the device's next inform. Example: refresh_parameter(device_id="202BC1-BM632w-000001", parameter="Device.DeviceInfo.SoftwareVersion"). |
| retry_taskA | Run a faulted task again: GenieACS clears the task's fault, and the device runs the task at its next session. Read genieacs://faults/{device_id} first to see why it failed; retrying a task whose cause is unchanged faults again. A task that has not faulted is left as it is. Example: retry_task(task_id="67abc123def4560012345678"). |
| search_devicesA | Find CPE devices in GenieACS with a MongoDB-style filter: by tag, manufacturer, model, firmware version, last inform time or any TR-069 parameter. It only reads. Examples: {"_tags":"office"}; {"InternetGatewayDevice.DeviceInfo.Manufacturer":"Huawei"} (GenieACS adds ._value to parameter paths); {"_lastInform":{"$lt":"2026-01-01T00:00:00Z"}} for devices silent since that date; {"_id":{"$regex":"^202BC1-"}}. Query operators such as $eq, $ne, $gt, $lt, $in, $nin, $exists, $regex, $and and $or work; $where, $function, $accumulator and $expr are refused, and a $regex pattern may be at most 256 characters. By default each device comes back as a summary (id, last inform, tags, manufacturer, product class, serial); ask for other fields with projection. Results come in pages of limit (default 50, at most 200); page with skip. |
| set_parameterA | Write one or more TR-069 parameter values on a CPE device, overwriting the current values: WiFi SSID or key, periodic inform interval, management server URL, or any writable parameter. A wrong value can cut the device off (a wrong WAN or ACS URL setting, for example). parameter_values is a JSON array of [path, value] or [path, value, xsdType] tuples; xsd types include xsd:string, xsd:boolean, xsd:unsignedInt, xsd:int and xsd:dateTime, and GenieACS infers the type when it is omitted. Example: [["InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.SSID","Lab-2","xsd:string"]]. GenieACS queues the task and sends a connection request at once: status "done" means the device applied it, "queued" means it runs at the next inform. A read-only or unknown parameter makes the device fault the task; see genieacs://faults/{device_id}. Read the current value with get_parameter first. |
| tag_deviceA | Add a tag to a CPE device or remove one. Tags group devices: presets match on them (precondition {"tags":"office"}) and search_devices finds by them. Adding or removing a tag can therefore make a preset apply to the device, or stop applying, at its next inform. Tags are case-sensitive. Use letters, digits, "-" and "": GenieACS rejects a tag with other characters (a "." for example) with a 404. Fails with ACS error 404 when the device id does not exist. Example: tag_device(device_id="202BC1-BM632w-000001", tag="office", action="add"). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Device summary list | Returns a lightweight JSON array of the CPE devices known to GenieACS (up to the configured DEVICE_LIMIT, default 500). Each entry has the device _id, _lastInform, _tags and _deviceId (_Manufacturer, _ProductClass, _SerialNumber). Use this resource as the starting point to discover device IDs before calling tools or fetching individual device details with genieacs://device/{id}. For more targeted queries, use the search_devices tool with MongoDB-style filters. The response is an array of JSON objects. Returns an empty array if no devices are registered. |
| Preset configuration list | Returns a JSON array of all presets configured in GenieACS. Each preset contains a name, weight (priority), precondition (a MongoDB-style filter that determines which devices the preset applies to), and configurations (an array of value assignments, provision script references, or object add/delete operations). Use this resource to inspect existing automation rules before creating or modifying presets with the manage_preset tool. Returns an empty array if no presets are configured. |
| Provision script list | Returns a JSON array of all provision scripts stored in GenieACS. Each entry contains the script name and its JavaScript source code. Provision scripts run server-side during CPE inform sessions and use the GenieACS sandbox API (declare, commit, ext, log) to dynamically configure devices. Use this resource to review existing scripts before creating or modifying provisions with the manage_provision tool, or to check which scripts are referenced by presets (via genieacs://presets/list). Returns an empty array if no provision scripts exist. |
TDQS
Scored across 12 tools
Each tool targets a distinct resource+action, and subtle pairs are explicitly separated: get_parameter (cached) vs refresh_parameter (fresh from device), delete_task vs retry_task, manage_preset vs manage_provision. Several tools queue tasks, but their purposes (reboot, download firmware, set/refresh parameters) are clearly different, and connection_request is explicitly documented as queueing nothing.
Eleven of twelve tools follow a clean verb_noun snake_case pattern (get_parameter, set_parameter, delete_task, reboot_device, tag_device, search_devices, etc.). The outlier is connection_request, which drops the leading verb; manage_preset/manage_provision also fold create/update/delete into an action parameter rather than separate names, a minor inconsistency.
Twelve tools is well within the ideal range and each earns its place: device discovery, parameter read/write/refresh, task lifecycle, firmware, presets, provisions, tagging, and connection requests. Nothing feels redundant or missing for the apparent ACS-management scope.
The surface covers the core TR-069 lifecycle: discover/tag devices, read/write/refresh parameters, reboot, download firmware, manage tasks (delete/retry), and CRUD presets/provisions. Minor gaps remain—no tool to list or upload the files that download_firmware references, and no dedicated task/fault listing tool (deferred to resource URIs), which agents can partly work around.