Find tools by query. Combines semantic search + tool-name keyword match.

Call this first when you need an action. The returned name is what you pass to invoke_read_tool for read-only tools or invoke_tool for writes. Results are deduplicated; exact METHOD /path or operationId matches are annotated match='exact' (including generated-only tools disabled by the current profile), semantic matches match='semantic', name-overlap matches match='keyword', and safety flags mirror backend ToolAnnotations. Results are compact by default; set include_schema=True only when you need the full JSON schema for a selected tool. Optional platform, server, normalized capability, curated/generated origin, and exact OpenAPI operation-ID filters apply to exact, keyword, and semantic matches.

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.

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 next_cursor value from a previous truncated response, to resume it from where it left off. Only ever returned by this tool for capability "read" tools -- it is process-local (invalidated by a server restart), integrity protected, time-limited, and bound to this exact tool name and these exact arguments. A malformed/tampered/expired/mismatched cursor returns an error and never reaches the backend.

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 ctx here and strips it from the published schema, so callers only pass name + arguments.)