@nexalware/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEXALWARE_API_KEY | Yes | The API key from the Nexalware dashboard, scoped with a DeviceGrant to only the device(s) this agent should touch. The server exits immediately with an error if this is missing. | |
| NEXALWARE_API_URL | No | Override for a self-hosted or staging deployment. Defaults to the production API. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesA | List the devices this API key can actually act on - only what its own DeviceGrant(s) cover, never the rest of the account. Call this first to discover valid deviceId values instead of guessing or asking the user to paste one in. |
| get_device_commandsA | List the commands a device accepts: name, label, and the params each one expects. |
| send_commandA | Send a command to a device. Check get_device_commands first for valid cmd names and expected params. Rejected if the calling key has no permission for this device/command. |
| turn_device_onB | Shorthand for sending the ON command to a device. |
| turn_device_offB | Shorthand for sending the OFF command to a device. |
| get_device_telemetryA | Read a device's telemetry history, newest first. |
| get_latest_telemetryB | Read a device's current state plus the most recent reading per telemetry metric. |
| list_sub_devicesA | List the physical sub-devices connected locally behind this device, if it's acting as a master. Empty until the master actually reports one, this never includes software agents. |
| get_sub_deviceC | Read one sub-device's current state and capabilities. |
| get_sub_device_telemetryA | Read one sub-device's telemetry history, newest first. |
| send_sub_device_commandA | Send a command to one specific sub-device behind a master, instead of the master itself. Not validated against a catalog, Nexalware relays it opaquely, the master and sub-device interpret it. |
| list_schedulesB | List a device's active (pending or currently running) schedules. |
| get_schedule_contextA | List the commands available to schedule for a device, same catalog as get_device_commands. |
| create_scheduleA | Create or replace one of a device's schedule slots (0-4), firing onCommand at onTs and offCommand at offTs. Rejected if the calling key has no permission for either command. |
| update_scheduleC | Update an existing schedule slot, only the fields provided are changed. |
| delete_scheduleC | Cancel a schedule slot. |
| get_schedule_historyA | List a device's completed or cancelled schedules, most recent first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Tools are largely distinct by resource (device vs sub-device) and action (telemetry, command, schedule). Minor overlap exists between turn_device_on/off and send_command, and between get_device_commands and get_schedule_context, but descriptions clarify the boundaries.
All tool names use a consistent snake_case verb_noun pattern (get_, list_, send_, turn_, create_, update_, delete_). The only slight deviation is turn_device_on/off, but it remains readable and consistent with the overall style.
17 tools is slightly above the ideal range but justified by the need to cover devices, sub-devices, telemetry, commands, and schedules. Each tool appears to serve a distinct purpose with no redundant operations.
The surface covers device discovery, command catalog, sending commands, telemetry (latest and history), sub-device operations, and full schedule lifecycle (create/update/delete/list/history/context). Minor gaps exist, such as no device metadata update or sub-device command catalog, but core workflows are complete.