Skip to the content.

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.