Example prompts

These scenarios are written for the default low-token router profile:

HPE_MCP_ROUTER_MODE=minimal
HPE_MCP_TOOLSETS=central,glp,rag

In this profile, ask your MCP client to use find_tool first, then dispatch with invoke_read_tool (read), invoke_tool (diagnostic/write/destructive). That keeps the tool list small while still reaching the full backend catalog. See tool-router.md for how discovery and dispatch work and what each safety classification means.

read diagnostic write destructive label each scenario below by its normalized capability.

1. First read

read

Prompt: "Use hpe-networking-mcp to find the tool for listing Aruba Central sites, then call it with a limit of 10."

find_tool("list Aruba Central sites")
invoke_read_tool("list_sites", {"limit": 10, "offset": 0})

Expected shape: a JSON array of site records (id, name, location fields), or a {"items": [...], "_pagination": {...}} wrapper only if the result needed clipping.

Variation: swap in list_devices with device_type/site_id filters to inventory APs or switches instead of sites. For wireless troubleshooting, use list_bssids with site_id, serial_number, or MAC filters to map each BSSID to its AP, radio, WLAN, band, and site. Use list_sites_client_health with site_id, site_name, or health sorting to compare wired and wireless client experience across sites.

2. Exact API lookup

read

Prompt: "Look up the exact OpenAPI endpoint or schema for Central client alerts. Do not guess from prose."

find_tool("exact OpenAPI lookup")
invoke_read_tool("lookup_api", {"query": "Central client alerts", "top_k": 10})

Expected shape: a JSON array of matched OpenAPI operations/schema fields, authoritative and lossless from the parsed specs; an empty array means no confident match -- fall back to ask_docs or search_docs.

Variation: ask for exact enum values, e.g. lookup_api("wlan-ssids opmode enum values"), or bypass fuzzy ranking with an exact route or operation ID: lookup_api("GET /network-monitoring/v1/sites-client-health") and lookup_api("listSitesClientHealthV1").

3. RAG answer

read

Prompt: "Explain how WPA3 SAE transition mode is represented in Central config. Include citations."

find_tool("ask Aruba docs with citations")
invoke_read_tool("ask_docs", {"question": "WPA3 SAE transition mode", "top_k": 5})

Expected shape: a compact extractive answer plus a bounded list of citations (file_path and matched chunk), instead of several long raw chunks.

Variation: call search_docs directly for raw retrieval when you want to see every matched chunk yourself.

4. Bounded batch

read

Prompt: "Show me the active critical alerts and the first 25 sites in one round trip."

find_tool("active critical alerts")
invoke_read_tool_batch({
  "calls": [
    {"id": "alerts", "name": "list_active_alerts", "arguments": {"severity": "CRITICAL"}},
    {"id": "sites",  "name": "list_sites",         "arguments": {"limit": 25}}
  ]
})

Expected shape: {"ok": bool, "results": [{"id": ..., "tool": ..., "status": "ok"|"blocked"|..., "result": {...}}], "counts": {"total": 2, "succeeded": ..., "failed": ...}, "failed_ids": [...], "truncated": bool}. ok is only true when every entry succeeded; one failed entry never aborts the rest.

Variation: outside a batch, resume one oversized single read by passing the previous response's next_cursor back as cursor: invoke_read_tool("list_devices", {"site_id": "SITE_ID"}, cursor="eyJ2IjoxLCJl..."). invoke_read_tool_batch is available outside minimal mode.

5. Diagnostic call

diagnostic

Prompt: "Ping 10.0.0.1 from CX switch CN12ABC456 and show me the result."

find_tool("ping from a CX switch")
invoke_tool("cx_ping", {"serial_number": "CN12ABC456", "destination": "10.0.0.1"})

Expected shape: an async result dict (the call polls for roughly 60s) with the ping output and an errors list. Diagnostic tools dispatch through invoke_tool, not invoke_read_tool, because they are intentionally not annotated read-only even though they change no device state.

Variation: cx_traceroute for a path trace, or cx_show with a commands list for raw CLI output.

6. Dry-run write

write

Prompt: "Build a MAC-auth guest SSID on scope SCOPE_ID. Show me the dry-run payload only -- do not apply it yet."

find_tool("build an SSID")
invoke_tool("build_underlay_ssid", {"ssid_name": "guest-wifi", "scope_id": "SCOPE_ID", "opmode": "OPEN", "dry_run": true})

Expected shape: the preview payload describing what would be created, plus an execution_contract whose dry_run.state reports preview. Nothing is written while dry_run is true.

Variation: after the user reviews the preview and asks for the change, repeat the same call with "dry_run": false.

7. Confirmation-gated destructive change

destructive

Prompt: "I reviewed the dry-run output for migration run RUN_ID -- apply it for real now."

find_tool("AOS8 apply migration run")
invoke_tool("aos8_apply_migration_run", {"run_id": "RUN_ID", "dry_run": false, "confirm": true})

Expected shape: per-candidate apply/resume results. This tool takes an explicit confirm: bool argument alongside dry_run and refuses a real write without both a prior dry run and confirm=true.

Variation: some destructive ops tools (reboot_device, port_bounce, poe_bounce, disconnect_client) have no confirm argument at all -- they confirm interactively through MCP elicitation instead. Check the tool's schema before assuming either shape.

8. Blocked by a write gate

write

Prompt: "Invite jane@example.com to the GreenLake workspace."

find_tool("invite a GLP user")
invoke_tool("invite_glp_user", {"email": "jane@example.com"})

Expected shape (default install): GLP writes default to disabled, so this returns a blocked response before any backend call -- {"error": "... glp writes are not enabled ...", "tool": "invite_glp_user", "status": "blocked", "platform": "glp", "execution_contract": {...}}. See the router safety-gates section for the full shape.

Variation: set HPE_MCP_GLP_V2BETA1_WRITES=1 and repeat the identical call to actually send the invite.

9. Optional-product example

read

Prompt: "Check whether the Mist optional backend is configured, then list the first 10 Apstra blueprints."

HPE_MCP_ACCESS_PROFILE=custom
HPE_MCP_PRODUCTS=mist,apstra
HPE_MCP_PRODUCT_ACCESS=read-only

find_tool("Mist backend status")
invoke_read_tool("mist_status", {})
find_tool("Apstra list blueprints")
invoke_read_tool("apstra_list_blueprints", {"limit": 10})

Expected shape: mist_status returns {"configured": bool, "host": ..., "has_token": bool}; apstra_list_blueprints returns a limit/offset-paginated list of blueprint records. Optional products stay disabled unless HPE_MCP_PRODUCTS/HPE_MCP_TOOLSETS enables them, and their write tools stay hidden while HPE_MCP_PRODUCT_ACCESS=read-only under the custom compatibility profile.

Variation: swap in UXI -- invoke_read_tool("uxi_list_sensors", {"page_size": 10}) then invoke_read_tool("uxi_get_sensor_status", {"sensor_id": "SENSOR_ID"}).

Write or destructive work. Confirm scope, device type, and (for SSIDs) security mode and VLANs before calling a write tool – never assume. Prefer dry_run=true first when the tool supports it, and use invoke_tool only after the user has given explicit intent for a write or destructive action.

Next