Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DLI Power Switch MCP Server Show me the status of all connected power switches"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project implements a Model Context Protocol (MCP) server that allows an AI agent to control Digital Loggers (DLI) Web Power Switches. The system provides tools for discovering hardware, querying outlet status, and performing power operations (On/Off/Cycle).
Crucial Constraint: This system interacts with physical hardware. Strict safety protocols are enforced to prevent accidental power loss to critical infrastructure.
Related MCP server: Redfish MCP Server
server.py: The main entry point. Contains the FastMCP server implementation, tool definitions, and hardware interaction logic using the power-switch-pro library.
switches_config.json: The source of truth for device configuration. Defines IP addresses, authentication, outlet aliases, and safety types (standard, critical, prohibited).
requirements.txt: Python dependencies (power-switch-pro).
tests/: Unit tests for the server logic.
This server is designed for responsiveness and safety:
Asynchronous Core: Built on Python's asyncio to handle multiple operations efficiently.
Non-Blocking I/O: Interactions with physical hardware (which can be slow) are offloaded to background threads, ensuring the main server loop remains responsive.
Parallel Discovery: The get_inventory tool fetches status from all configured switches concurrently, significantly reducing latency in systems with multiple devices.
Install this server from PyPI using pip:
pip install dli-mcp-serverOnce installed, register the server with the Gemini CLI (or Antigravity) using the mcp add command. This ensures the server starts automatically.
gemini mcp add dli-mcp-server dli-mcp-server -e DLI_MCP_CONFIG="/path/to/your/config.json"Parameters:
The first dli-mcp-server is the name you assign to this server instance.
The second dli-mcp-server is the command that runs the server (made available by pip install).
-e DLI_MCP_CONFIG="...": (Optional) Sets the environment variable for the configuration file path. If omitted, it defaults to switches_config.json in the current directory.
-s user or -s project: (Optional) Sets the configuration scope. Defaults to project.
The server.py script can be used directly from the command line to control the power switches.
inventoryLists all switches and their outlet statuses.
python server.py inventorypower_actionPerforms a power action (on, off, cycle) on a specific outlet.
python server.py power_action <switch_id> <outlet_id> <action> [--confirmation YES]switch_id: Alias or IP address of the switch.
outlet_id: Index or name of the outlet.
action: on, off, or cycle.
--confirmation: Required for critical outlets.
group_power_actionPerforms a power action on a group of outlets.
python server.py group_power_action <group_id> <action>sync_config_from_hardwareSynchronizes outlet names from the hardware.
python server.py sync_config_from_hardware <switch_id>list_outletsLists all outlets on a given switch.
python server.py list_outlets <switch_id>add_switchAdds a new DLI power switch to the configuration. If the configuration file does not exist, it will be automatically created.
python server.py add_switch <ip_address> <username> <password>ip_address: IP address of the new switch.
username: Username for the new switch.
password: Password for the new switch.
remove_switchRemoves a DLI power switch from the configuration.
python server.py remove_switch <switch_id>switch_id: Alias or IP address of the switch to remove.
update_outletUpdates the definition of an outlet.
python server.py update_outlet <switch_id> <outlet_id> [--name <new_name>] [--description <new_description>] [--type <new_type>]switch_id: Alias or IP address of the switch.
outlet_id: Index or name of the outlet (e.g., "Modem" or "1").
--name: New name for the outlet.
--description: New description for the outlet.
--type: New type for the outlet (standard, critical, or prohibited).
Type | Agent Permission | Behavior |
| Full Access | Can be turned On, Off, or Cycled immediately. |
| Restricted | "Off" or "Cycle" actions require explicit user confirmation ( |
| No Access | NEVER modify this outlet. The server will raise a |
get_inventory()Purpose: The "eyes" of the agent. Call this first to see what switches and outlets are available and their current state (ON/OFF).
Returns: A JSON object containing all switches, outlets, groups, and their descriptions.
power_action(switch_id, outlet_id, action, confirmation="NO")Purpose: Controls a specific physical outlet.
Inputs:
switch_id: The Alias (e.g., "garage_rack") or IP.
outlet_id: The Name (e.g., "Modem") or Index (e.g., "1").
action: "on", "off", or "cycle".
confirmation: Must be set to "YES" only if the user has explicitly approved a dangerous action on a critical outlet.
group_power_action(target, action)Purpose: Controls a logical group of outlets (e.g., "Restart the Network Stack").
Behavior: Executes sequentially. If any member of the group is prohibited, the entire operation aborts immediately.
sync_config_from_hardware(switch_id)Purpose: Updates the switches_config.json file with the actual outlet names found on the device.
Note: This does not overwrite safety types (critical/prohibited) or descriptions.
add_switch(ip_address, username, password)Purpose: Adds a new DLI power switch to the configuration.
Inputs:
ip_address: IP address of the new switch.
username: Username for the new switch.
password: Password for the new switch.
remove_switch(switch_id)Purpose: Removes a DLI power switch from the configuration.
Inputs:
switch_id: Alias or IP address of the switch to remove.
list_outlets(switch_id)Purpose: Lists all outlets and their status for a given switch.
Inputs:
switch_id: The Alias or IP address of the switch.
Returns: A JSON array of outlet information.
update_outlet(switch_id, outlet_id, new_name=None, new_description=None, new_type=None)Purpose: Updates the definition of an outlet in the configuration file and writes the new name to the hardware.
Inputs:
switch_id: The Alias or IP address of the switch.
outlet_id: The Name or Index (e.g., "Modem" or "1").
new_name (optional): The new name for the outlet. This is written to both the config file and the hardware.
new_description (optional): The new description for the outlet. This is only written to the config file.
new_type (optional): The new type for the outlet (standard, critical, or prohibited). This is only written to the config file.
Returns: A success message.
Always Check Inventory First: Before assuming an outlet exists or knowing its status, run get_inventory.
Respect "Prohibited" Outlets: If a user asks to turn off a prohibited device (e.g., "Security DVR"), explain that you cannot do so because it is restricted in the configuration.
Handle "Critical" Warnings: If power_action returns a "SAFETY LOCK" message, stop and ask the user: "This is a critical device. Are you sure you want to turn it off?". Only proceed if they say "Yes".
Use Aliases: Prefer using the friendly alias and name (e.g., "garage_rack", "Modem") over IP addresses and indices when communicating with the user.
The project includes a suite of unit tests to ensure the server logic is correct. The tests are located in the tests/ directory.
To run the tests, first install the testing dependencies:
pip install -r tests/requirements.txtThen, use the following command to run the tests:
python tests/test_server.pyThe tests are designed to run without a physical DLI power switch. They use mocking to simulate the hardware and its behavior.
The project uses GitHub Actions for continuous integration. Tests are automatically executed on every push and pull request to the main branch. The workflow runs on:
Operating Systems: Windows, Linux (Ubuntu), and macOS.
Python Versions: 3.10, 3.11, and 3.12.
This ensures cross-platform compatibility and stability across supported Python versions.
To check the test coverage, you can use the coverage package (which is included in tests/requirements.txt).
Run the tests with coverage and generate a report:
coverage run tests/test_server.py
coverage report -mThe project aims for a high test coverage to ensure reliability.
You can easily register this MCP server with the Gemini CLI (or Antigravity) using the mcp add command. This ensures the server starts automatically.
Windows:
gemini mcp add dli-mcp-server python "C:\Path\To\dli-mcp-server\server.py" -e DLI_MCP_CONFIG="C:\Path\To\your\config.json" -s userLinux / macOS:
gemini mcp add dli-mcp-server python "/path/to/dli-mcp-server/server.py" -e DLI_MCP_CONFIG="/path/to/your/config.json" -s userParameters:
dli-mcp-server: The name you assign to the server.
python "...": The command to start the server. Ensure you provide the full absolute path to server.py.
-e DLI_MCP_CONFIG="...": (Optional) Sets the environment variable for the configuration file path. If omitted, it defaults to switches_config.json in the server's directory.
-s user: Saves the configuration to your user settings (global), making it available across all projects.
-s project (Default): Saves the configuration to the current project's .gemini/settings.json. Use this if you want the server configuration to be specific to the current workspace.
By default, the server uses the switches_config.json file in the same directory. You can override this by setting the DLI_MCP_CONFIG environment variable to the path of your configuration file.
Example:
export DLI_MCP_CONFIG=/path/to/your/custom_config.json
python server.py inventoryThis is particularly useful for testing with different configurations without modifying the main switches_config.json file.
User: "Turn off the Router."
Agent Action:
Calls get_inventory (internal) -> sees Router is critical.
Calls power_action("garage_rack", "Router", "off").
Result: Returns "SAFETY LOCK...".
Agent Response: "The Router is marked as a critical device. Are you sure you want to turn it off?"
User: "Yes, do it."
Agent Action:
Calls power_action("garage_rack", "Router", "off", confirmation="YES").
Result: "Success..."
Agent Response: "The Router has been turned off."
This MCP server was developed using Gemini CLI and Gemini 3.0 models.
Adds a new DLI power switch to the configuration. Connects to the switch, syncs its configuration, and saves it.
| Name | Required | Description | Default |
|---|---|---|---|
| ip_address | Yes | ||
| username | Yes | ||
| password | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool connects, syncs, and saves, but without annotations, it lacks details on error handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff, but could benefit from more structured presentation of steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain the return values or parameter details, and given no annotations, the tool is inadequately specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and the description not mentioning 'ip_address', 'username', or 'password', it adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a new DLI power switch and mentions the connecting, syncing, and saving steps, distinguishing it from siblings like 'remove_switch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| action | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all outlets and their status for a given switch.
| Name | Required | Description | Default |
|---|---|---|---|
| switch_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action, failing to mention read-only nature, potential side effects, required permissions, or error handling. This is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the key information. Every word is necessary and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. The description is sufficient for a simple list operation with one required parameter, though it could mention validation of the switch_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description implies the parameter's role ('for a given switch'), adding some context. However, it does not elaborate on format or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lists), resource (outlets and their status), and context (for a given switch), making it distinct from sibling tools like add_switch or power_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The agent must infer usage from the name and parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| switch_id | Yes | ||
| outlet_id | Yes | ||
| action | Yes | ||
| confirmation | No | NO |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes a DLI power switch from the configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| switch_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a destructive action but doesn't disclose consequences, reversibility, or required permissions. No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys core action with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description lacks output details, safety warnings, or guidance relative to siblings. Leaves agent guessing about removal implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for 'switch_id'. Description adds no explanation of what constitutes a valid switch_id (e.g., ID vs name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Removes' and specific resource 'DLI power switch from the configuration', distinguishing it from siblings like add_switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| switch_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the definition of an outlet.
| Name | Required | Description | Default |
|---|---|---|---|
| switch_id | Yes | ||
| outlet_id | Yes | ||
| new_name | No | ||
| new_description | No | ||
| new_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Updates the definition' without disclosing behavioral traits like side effects, required permissions, or what happens if the outlet does not exist. The presence of an output schema is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but lacks structure. It is not front-loaded with key information beyond the basic purpose. While brevity is valued, it omits important details that could fit in a similar space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required, 1 enum) and an output schema, the description is insufficient. It does not explain the return value, any constraints, or the context of when this update is applicable. Without annotations, more completeness is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameters. It fails to explain the purpose of switch_id, outlet_id, new_name, new_description, or new_type beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an outlet definition, using a specific verb and resource. It distinguishes from siblings like list_outlets (read-only) and power_action (operational). However, it does not specify which aspects of the definition are updated, though the schema provides details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like add_switch or group_power_action. Lacks context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Several tools have overlapping or unclear purposes, especially 'power_action' and 'group_power_action', and 'get_inventory' vs 'list_outlets'. Lack of descriptions for half the tools increases ambiguity.
Most tools use snake_case with verb_noun pattern, but 'get_inventory' uses 'get_' instead of 'list_', and 'sync_config_from_hardware' breaks the short pattern. Inconsistent verb choice for similar actions.
8 tools is reasonable for a power switch management domain, covering core operations like add/remove switches, list/update outlets, and power actions. Not excessive or too sparse.
The set seems to cover basic lifecycle (add, remove, configure, list, update) and power actions, but missing explicit individual control steps (e.g., turn on/off a specific outlet) and status monitoring beyond list, making it somewhat incomplete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hharte/dli-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
