hpe-networking-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_PORT | No | Port for the streamable HTTP server (e.g., 8010). | |
| HPE_MCP_PRODUCTS | No | Comma-separated optional products to enable (e.g., clearpass,mist,apstra,aos8,edgeconnect,uxi,axis,design). | |
| HPE_MCP_TOOLSETS | No | Comma-separated toolsets to enable; default is central,glp,rag. | central,glp,rag |
| MCP_ALLOWED_HOSTS | No | Allowed hosts for non-loopback binds. | |
| HPE_MCP_ROUTER_MODE | No | Router mode; default is minimal. | minimal |
| MCP_ALLOWED_ORIGINS | No | Allowed origins for non-loopback binds. | |
| MCP_HTTP_BEARER_TOKEN | No | Bearer token to protect the HTTP server. | |
| HPE_MCP_PRODUCT_ACCESS | No | Product access level; default is read-only. | read-only |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_toolA | Find tools by query. Combines semantic search + tool-name keyword match. Call this first when you need an action. The returned Args: query: What you want to do. e.g. "create a VLAN", "disconnect a client". top_k: 1-10 results (default 5). include_schema: Include full JSON schemas in results. Defaults to False to keep MCP responses compact. platform: Filter by normalized platform, such as central, glp, mist, clearpass, or apstra. server: Filter by exact backend server name, such as central-monitoring. capability: Filter by read, diagnostic, write, or destructive. origin: Filter by curated or generated implementation. operation_id: Filter by an exact generated OpenAPI operationId. |
| invoke_read_toolA | Call a read-only Aruba tool by name (from find_tool). This refuses tools that are not annotated read-only. Use invoke_tool only for write/destructive tools after explicit user intent. Args:
cursor: Opaque |
| invoke_toolA | Call an Aruba tool by name (from find_tool). Arguments is a kwargs dict. Example: invoke_tool("create_vlan", {"vlan_id": 200, "vlan_name": "Guest"}) Dispatches through the owning backend's MCPServer tool manager, so arguments
get MCPServer validation/coercion and the router's request Context is forwarded
— this is what lets the async, ctx-requiring destructive ops tools
(reboot_device/port_bounce/poe_bounce/disconnect_client) reach their
confirmation elicitation. (MCPServer injects |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| network_health_overview | Summarize tenant/site health, active alerts, and worst affected scopes. |
| troubleshoot_site | Investigate health, alerts, devices, and likely causes for one site. |
| client_connectivity_check | Investigate one client by MAC/name/IP and correlate AP/site symptoms. |
| investigate_device_events | Investigate one device's recent events and related health indicators. |
| device_troubleshooting_plan | Build a bounded read-only troubleshooting plan for one device serial. |
| site_troubleshooting_plan | Build a bounded read-only troubleshooting plan for one site. |
| compare_site_health | Compare multiple sites and rank them by health/risk. |
| critical_alerts_review | Review active critical/high alerts and group them by category and scope. |
| failed_clients_investigation | Investigate failed clients at a site and correlate to infrastructure. |
| explain_how_it_works | Answer how-to / concept questions via RAG first (ask_docs, lookup_api), never from model memory alone. |
| morning_report | Last-24h ops digest across enabled platforms (engineer detail or executive summary). |
| central_scope_resolve | Resolve a Central site/group/global name to scope_id metadata. |
| central_scope_audit | Bounded Central config hygiene audit for scopes, WLANs, roles, auth. |
| wlan_sync_check | Compare Central and Mist WLAN/SSID inventories for drift (read-only). |
| cross_platform_rf_check | Site RF/channel health using Central and optional Mist assurance tools. |
| mist_scope_audit | Bounded Mist site/WLAN/assurance audit. Requires mist backend. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool occupies a distinct role in the workflow: find_tool discovers available operations, invoke_read_tool executes read-only operations, and invoke_tool executes write/destructive operations. There is no meaningful overlap between discovery and dispatch, and the read/write split is clearly enforced by the read-only annotation.
All tool names follow a consistent lowercase snake_case verb_noun pattern: find_tool, invoke_read_tool, invoke_tool. The qualifier 'read' in invoke_read_tool is predictable and mirrors the semantic distinction from invoke_tool.
Three tools is the right minimal set for a discovery-and-dispatch gateway: one to search/resolve tools, one for read-only invocation, and one for write/destructive invocation. Each tool is essential and none is redundant.
The tool surface fully covers the intended lifecycle: discover an action, invoke it read-only, or invoke it as a write. The find_tool schema option and cursor handling cover schema retrieval and pagination, while invoke_tool's dispatch design handles backend validation and confirmation for destructive operations. No obvious gap exists for this meta-tooling purpose.