hpe-networking-mcp
Related Servers
Alternatives to hpe-networking-mcp
No user-submitted related servers found.
Related Servers
- FlicenseNot gradedqualityDmaintenanceProduction-grade MCP server that exposes the complete HPE Aruba Networking Central REST API as 90 tools across 19 categories, enabling AI assistants to manage Aruba Central networks.-
- AlicenseNot gradedqualityCmaintenanceMCP server that exposes HPE Aruba EdgeConnect Orchestrator SD-WAN infrastructure as LLM-callable tools for listing appliances, reading interface/tunnel/bandwidth state, and changing HPE SSE tunnel state.Apache 2.0
- FlicenseNot gradedqualityBmaintenanceEnables MCP-capable AI agents to observe, troubleshoot, and configure Aruba CX (AOS-CX) switches through REST and SSH, with safety controls, inventory management, and verification workflows.-
- FlicenseBqualityDmaintenanceAsynchronous MCP server for unified multi-platform network infrastructure management, providing 97 tools across 10 connectors including SSH, MikroTik, Palo Alto, Aruba, Graylog, LibreNMS, Cisco APIC/NDFC, and Panorama.9722-
- AlicenseNot gradedqualityDmaintenanceMCP server for network operations that lets AI assistants interact with Cisco/Juniper network devices through safe, well-defined tools like compliance audits and configuration backups.MIT
- AlicenseAqualityDmaintenanceA community MCP server for Cisco Secure Access that exposes the Secure Access REST API to AI clients as a curated catalog of tools for Admin, Deployments, Investigate, Policies, and Reports.421Apache 2.0
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.