Example prompts
These examples are written for the default low-token router profile:
CENTRALMCP_ROUTER_MODE=minimal
CENTRALMCP_TOOLSETS=central,glp,rag
In this profile, ask your MCP client to use find_tool first, then call invoke_read_tool for read-only work. That keeps the tool list small while still reaching the backend catalog.
First smoke test
Natural-language prompt:
Use centralmcp to find the tool for listing Aruba Central sites, then call it with limit 10.
Router flow:
find_tool("list Aruba Central sites")
invoke_read_tool("list_sites", {"limit": 10, "offset": 0})
Check active alerts
Natural-language prompt:
Show me the active critical alerts in Aruba Central. Keep the result short.
Router flow:
find_tool("active critical alerts")
invoke_read_tool("list_active_alerts", {"severity": "CRITICAL", "limit": 20, "offset": 0})
Search clients without flooding context
Natural-language prompt:
Find connected clients whose hostname contains "printer". Return only the first 25.
Router flow:
find_tool("connected clients hostname contains")
invoke_read_tool("list_clients", {"hostname_contains": "printer", "limit": 25, "offset": 0})
Ask documentation questions
Natural-language prompt:
Use the Aruba docs index to explain how WPA3 SAE transition mode is represented. Include citations.
Router flow:
find_tool("ask Aruba docs with citations")
invoke_read_tool("ask_docs", {"question": "WPA3 SAE transition mode", "top_k": 5})
Look up exact API details
Natural-language prompt:
Look up the exact OpenAPI endpoint or schema for Central client alerts. Do not guess from prose.
Router flow:
find_tool("exact OpenAPI lookup")
invoke_read_tool("lookup_api", {"query": "Central client alerts", "top_k": 10})
Inspect device inventory
Natural-language prompt:
List the first 25 access points at a site, then tell me which tool can get device health for one serial number.
Router flow:
find_tool("list devices by site")
invoke_read_tool("list_devices", {"device_type": "AP", "site_id": "SITE_ID", "limit": 25, "offset": 0})
find_tool("device health by serial number")
Optional products
Optional product starters are disabled unless you enable them:
CENTRALMCP_PRODUCTS=clearpass,mist,apstra,aos8,edgeconnect,uxi
CENTRALMCP_PRODUCT_ACCESS=read-only
Example prompt:
Check whether the Mist optional backend is configured, then find the guarded read-only Mist GET tool.
Router flow:
find_tool("Mist backend status")
invoke_read_tool("mist_status", {})
find_tool("Mist read-only GET")
Typed optional read prompt:
List the first 10 Apstra blueprints and show only their IDs, labels, and status.
Router flow:
find_tool("Apstra list blueprints")
invoke_read_tool("apstra_list_blueprints", {"limit": 10})
UXI read prompt:
List the first 10 UXI sensors, then get online/testing status for one sensor ID.
Router flow:
find_tool("UXI list sensors")
invoke_read_tool("uxi_list_sensors", {"page_size": 10})
find_tool("UXI sensor status")
invoke_read_tool("uxi_get_sensor_status", {"sensor_id": "SENSOR_ID"})
Lab write dry-run prompt:
CENTRALMCP_PRODUCT_ACCESS=read-write
Find the Mist alarm acknowledgement tool and show the dry-run payload for alarm ALARM_ID at site SITE_ID. Do not execute it.
Router flow:
find_tool("Mist acknowledge alarm")
invoke_tool("mist_ack_alarm", {"site_id": "SITE_ID", "alarm_id": "ALARM_ID", "note": "lab verified", "dry_run": true})
Write or destructive work
For writes, make intent explicit and dry-run first when the selected tool supports it:
Find the tool to build an SSID, show me the dry-run payload only, and do not apply changes yet.
Use invoke_tool only after the user intentionally asks for a write/destructive action. The router marks it destructive because it can dispatch write-capable backend tools.