Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@casper-network-mcp show me the top alarms on my Aruba Central site right now"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One small MCP server for HPE Aruba Networking Central, Juniper Mist and HPE Aruba Networking ClearPass, built for Casper. Your AI sees four tools; behind them are about 3,900 tools for the three products, each one labelled with the kind of change it makes.
You normally never install this yourself: Casper sets it up, pins the exact version and starts it for you.
Tool | What it is for |
| Finds the right tool for what you asked ("bounce port 7 on the closet switch") and says what kind of change it makes: read, troubleshoot, config, disruptive, firmware, delete or admin. |
| Runs a tool that only reads, or a check that changes nothing. Anything else is refused. |
| Runs any tool, including ones that change your network. Casper asks you first. |
| Says, for each product, whether a login is set and where that login can change things. |
Behind them:
hand-written tools for everyday work (sites, clients, alarms, switch ports, guests, sessions, SSIDs, VLANs and more), each one checked against the vendor's own API description;
one generated tool for every operation in the bundled API descriptions;
overview tools for broad questions: central_site_overview, mist_site_overview and clearpass_overview give
health, device counts and the top alarms in one read;
lookup_api, which answers exact questions about the vendors' APIs (endpoints, fields, allowed values) from the
bundled documents, with no network.
Related MCP server: HPE Aruba Networking Central MCP Server
uvx --from casper-network-mcp==0.1.0 casper-network-mcp --read-onlyOption | Meaning |
| Only read and run checks; never send a change. Read once at start: nothing turns writes on while it runs. Casper passes this until you allow changes. |
| The default: talk over standard input and output. |
| Listen on this machine only ( |
From a checkout, .mcp.json.example starts it read-only with uv run; logins come from your shell.
The server reads only these variables from the environment Casper starts it with. It reads no settings files.
Leave out a product you do not use: the server still starts, access_check says that login is missing, and a call
to one of its tools answers {"error": "login_missing", "product": "..."}.
Product | Variables |
Juniper Mist |
|
HPE Aruba Networking Central |
|
HPE Aruba Networking ClearPass |
|
There are no write switches. What a login may do is set by its role in the product, and Casper asks you before every change, showing the tool and what it changes. On top of that:
--read-only refuses every change before anything is sent;
a path piece that could reach somewhere else (/, ?, #, ..) is refused before anything is sent;
when the server knows a Mist login can only read a site, a change to that site is refused before anything is sent;
tools that disrupt the network (reboots, port and PoE bounces, disconnects) are labelled disruptive, so Casper asks every time;
tokens, passwords and pre-shared keys are hidden in replies and errors.
The server never asks you to type anything and never treats an argument the AI sets as your approval. Approval is Casper's box only.
find_tool was measured on a fixed set of 60 plain questions (20 each for Central, Mist and ClearPass, in
tests/bench/find_tool_questions.yaml), then tuned one change at a time. A change stayed only if it found more
right tools in the top 3, or answered faster without finding fewer. Run uv run python scripts/bench_find_tool.py
to measure it yourself.
Right tool first | Right tool in top 3 | Top 3, no product given | Time per question (p50 / p95) | First question in a new process | |
Before | 67% | 77% | 68% | 0.6 / 1.6 ms | 3.4 s |
After | 85% | 100% | 90% | 0.6 / 2.0 ms | 0.4 s |
What changed, in order:
Synonyms (router/synonyms.yaml) and plural folding: "access point" finds ap, "kick" finds disconnect, "who is
on" finds clients. Top 3: 77% to 97%.
Ranking by what the question asks: "what" and "show" prefer tools that read, "create", "delete" and "change" prefer those changes; the product name in a tool's name no longer counts against it. Top 3: 97% to 98%, first pick 75% to 87%. (Weighting name words over description words was tried and dropped: top 3 fell to 90-95%.)
A prebuilt word index shipped in the package (router/index.json): the first question no longer loads every
tool. First question: 3.4 s to 0.4 s.
Overview tools for broad questions (central_site_overview, mist_site_overview, clearpass_overview: health,
device counts and top alarms in one read) and mist_list_site_clients for "who is on the wifi". A synonym that
spreads into several words ("wifi" to wlan, ssid, wireless) now counts once. Top 3: 98% to 100%.
Times are on a laptop with the router already loaded, except the last column.
The package includes HPE's proprietary API documents (not MIT; see specs/NOTICE.md) and Juniper Mist's MIT
OpenAPI file. They are stored exactly as the vendors serve them; scripts/refresh_specs.py --check fetches them
again and confirms every hash. See NOTICE.md and THIRD_PARTY_NOTICES.md.
The package has no install step, downloads nothing when it starts and never updates itself.
uv sync
uv run pytest -q
uv run ruff check .
uv run python scripts/bench_find_tool.py # find_tool accuracy and speed
uv run python scripts/build_manifests.py # after the bundled specs change
uv run python scripts/build_index.py # after any tool changesA release is built from a v* tag: the wheel, then casper-network-mcp.lock.txt (every dependency pinned by hash,
plus this package pinned to the wheel's own hash, made by scripts/make_lock.py). The release checks that lock
installs with Casper's exact command before publishing:
uv pip install --require-hashes --no-deps --only-binary :all: -r casper-network-mcp.lock.txtReport problems privately; see SECURITY.md.
MIT for this project's code (LICENSE). The bundled vendor documents keep their own terms (NOTICE.md).
What each product login can do, and whether this server is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that the tool surfaces whether the server is read-only, which is modest extra context, but it says nothing about auth requirements, cost, or when the result could change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler. It is front-loaded enough to be read at a glance, though the phrasing is slightly awkward as a fragment rather than a clear action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't explain return values, and with no input parameters the surface area is small. The description covers the two things the tool reports, making it reasonably complete for a trivial diagnostic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no parameter semantics to add. Per the baseline for zero-parameter tools, a 4 is appropriate; the description makes no parameter claims that need reconciling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the information returned (per-login capabilities and server read-only status) but never states a verb or the resource being inspected, so it reads more like a return-value summary than a tool purpose. An agent can infer it reports access/permission state, but it is not crisply differentiated from find_tool or the invoke_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the sibling tools (find_tool, invoke_read_tool, invoke_tool), and no preconditions or exclusions. Usage is only implied by the description of what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the tool for a task. Call this first.
query: what you want to do, in plain words ("bounce port 7 on the
closet switch") or an exact API call ("GET /api/v1/sites/{site_id}").
product: central, mist, clearpass or specs (the API document lookup).
Each hit has name, product, summary, kind (read, troubleshoot, config,
disruptive, firmware, delete or admin) and label. Pass include_schema
to get the arguments a tool takes. Then call invoke_read_tool (kind
read or troubleshoot) or invoke_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| product | No | ||
| include_schema | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so safety is covered. The description goes beyond them by describing what a hit contains (name, product, summary, kind with its enumerated categories, label) and that include_schema expands the result with a tool's arguments, which meaningfully shapes how the agent consumes the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the 'call this first' instruction are front-loaded, then parameters, then routing; every sentence carries information. The docstring-style indentation makes it slightly denser to parse than a clean paragraph, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description usefully summarizes hit fields and the include_schema effect, and it covers the full discovery-to-invocation workflow including which sibling to call. Missing only edge details such as behavior on zero hits and the meaning of top_k.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load, and it does for three of four parameters: it explains that query accepts plain language or an exact API path (with examples), and it enumerates the product values (central, mist, clearpass, specs) that appear nowhere in the schema. top_k is left unexplained, which is the only real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find the tool for a task') and distinguishes itself from the sibling invoke_read_tool / invoke_tool pair by being the discovery step that precedes them. An agent can tell immediately that this is the entry point of the tool-selection flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first' gives explicit ordering, and the routing rule (kind read or troubleshoot -> invoke_read_tool, otherwise invoke_tool) tells the agent exactly which sibling to use afterward. It stops short of stating when not to call it (e.g., when the tool name is already known), leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a tool that only reads, or runs a check that changes nothing (from find_tool).
A tool that can change something is refused with "not_a_read_tool".
cursor: the next_cursor from a reply that was cut short, to get the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| cursor | No | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the exact refusal error string 'not_a_read_tool' and the meaning of cursor for continuing truncated replies, which the agent cannot get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and kept to a few short clauses; the cursor note is appended as a labeled aside. The parenthetical '(from find_tool)' and the stray formatting are slightly rough but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists and the description says nothing about what a successful invocation returns, and it leaves the two most important parameters (name, arguments) unexplained. It covers the routing/error behavior and pagination continuation well, but an agent still lacks enough to know how to build the invocation payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full explanatory burden, yet it only documents 'cursor' (the next_cursor for truncated replies). The required 'name' parameter (the tool to invoke) and the 'arguments' object passed through to that tool are completely unaddressed in both description and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (run a read-only tool or a no-op check) and even clarifies provenance ('from find_tool'). It effectively distinguishes this from the mutating sibling invoke_tool by declaring that anything that can change state is refused, though it never names that sibling directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear selection condition — use this when the tool only reads or the check changes nothing — and states the failure mode ('refused with not_a_read_tool') if the condition is violated. What is missing is an explicit pointer to invoke_tool as the alternative for mutating tools, which the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any tool from find_tool, including ones that change the network.
The tool's own kind (from find_tool) says what it changes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is largely covered. The description adds useful context that the invoked tool's own 'kind' from find_tool determines what it changes, which helps the agent reason about side effects. However it says nothing about failure modes, auth, or what happens if the named tool is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines, front-loaded with the core action and no filler. The second sentence is a little telegraphic but still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an open-world dispatcher with no output schema, the description should say more about what a result looks like and how errors surface when the invoked tool fails. It covers the essential routing concept but leaves the call mechanics under-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, yet it only implies that 'name' comes from find_tool and says nothing about the 'arguments' object shape, defaults, or how to pass tool-specific parameters. Passing arbitrary arguments to an arbitrary tool is exactly where guidance is needed most.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Run') and resource ('any tool from find_tool'), and the phrase 'including ones that change the network' implicitly distinguishes it from the read-only sibling invoke_read_tool. It stops short of naming that sibling directly, so differentiation is present but inferential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies a workflow (discover via find_tool, then run here) and hints at the read/write split, but never states when to prefer this over invoke_read_tool or excludes cases. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0access_checkfind_toolinvoke_read_toolinvoke_toolScored across 4 tools
find_tool is clearly the discovery step, and access_check is distinct. invoke_read_tool and invoke_tool overlap because invoke_tool can also perform reads, but the descriptions clearly distinguish read-only vs. any operation, so an agent can select based on safety intent.
Three of four tools follow a verb_noun pattern (find_tool, invoke_read_tool, invoke_tool), and all use snake_case. access_check breaks the verb-first convention but remains readable and semantically clear.
Four tools is well-scoped for a gateway server that proxies many underlying network APIs. Each tool has a distinct role: discovery, read-only invocation, general invocation, and access inspection.
The surface covers discovery, read-only execution, general execution, and permission checking, which are the core operations for this meta-server. Minor gaps include no explicit list-all-tools or describe-by-name operation, though find_tool with a query likely covers these use cases.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
