This MCP server lets an AI discover and run read, troubleshooting, and change operations across HPE Aruba Networking Central, Juniper Mist, and ClearPass, exposing four main tools over ~3,900 vendor API operations.
find_tool — search for the right tool using plain language or an exact API call, optionally filtered by product, with schemas and change-kind labels (read, troubleshoot, config, disruptive, firmware, delete, admin).
invoke_read_tool — run only read-only or non-disruptive troubleshooting tools; refuses tools that can change anything. Supports cursors and read-result shaping with all_pages, fields, and group_by.
invoke_tool — run any tool, including network-changing operations; Casper asks for approval before changes, and --read-only mode refuses all changes.
access_check — report each product’s login status, named logins, expiry, and whether the server is read-only.
Use bundled overview and specialty tools such as site overviews, ClearPass denial summaries, lookup_api offline API lookup, busy_hours, and Mist WLAN discovery diagnostics.
Work with multiple Central accounts via named logins, receive structured API/transport errors with guidance, and keep tokens/passwords/pre-shared keys hidden from replies.
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 non-disruptive troubleshooting check (ping, show). 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;
clearpass_why_denied summarizes recent sessions, endpoint status/profile, NAD and applied roles for exactly
one MAC or username. The bundled 6.12.7 API exposes active accounting sessions, not full Access Tracker
rejects; missing auth results, reject reasons and enforcement profiles remain unknown;
ClearPass session and auth-failure reads accept MAC, username, NAD IP, accounting service type and ISO 8601
start/end times (with timezone). Time windows scan at most ten pages locally; next_server_offset continues
a scan, including an empty page. The service filter is not an Access Tracker policy service name;
lookup_api, which answers exact questions about the vendors' APIs (endpoints, fields, allowed values) from the
bundled documents, with no network.
busy_hours profiles a site hour by hour over up to a month (client counts, or a switch uplink's traffic) in your
time zone and names the quietest window for planned downtime.
Related MCP server: HPE Aruba Networking Central MCP Server
invoke_read_tool can shape a reply before it reaches the AI, so a question about every AP or every client is one
call, not a page loop:
Option | What it does |
| Follows the tool's own paging ( |
| Keeps only these keys of each item; |
| Returns a count per value of one field instead of the items. |
For example {"name": "central_get_device_inventory_v1", "arguments": {}, "all_pages": true, "group_by": "status"}
answers "how many devices are in each state" for a whole account. Shaping is for reads only,
so a repeated call never repeats a change.
uvx --from casper-network-mcp==0.1.6 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 |
|
For ClearPass, an API client is best: the server logs in with it and gets a new token before the old one runs out.
In ClearPass Guest, open Administration > API Services > API Clients, create a client with grant type Client
Credentials and an operator profile that allows what you want Casper to do, and set its client ID and secret. If
CLEARPASS_API_TOKEN is set it is used as is and the client ID and secret are ignored.
A second Central account (a customer's temporary key, a lab) needs no second server. Set
CENTRAL_TEMP_BASE_URL, CENTRAL_TEMP_CLIENT_ID and CENTRAL_TEMP_CLIENT_SECRET and the login is called temp.
access_check lists it under Central's named_logins, and invoke_read_tool or invoke_tool with "login": "temp" runs that one call as it; without login the main account answers. Names are letters and digits. The
--read-only pin covers every login. Remove the variables when the key is retired.
ClearPass API tokens expire (the API client's token lifetime in ClearPass sets when); a pasted token is not renewed.
When a product turns a login away (HTTP 401), access_check reports that product with "login": "expired" and a
call to one of its tools returns {"error": "login_expired", "product": ...}, so the client can ask you for a new one.
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 (cable tests, reboots, port and PoE bounces, disconnects) require invoke_tool
and 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.
For AirPrint, Bonjour or mDNS problems, find mist_wlan_discovery_summary with
find_tool("AirPrint discovery", product="mist", include_schema=True), then call it with
{"ssid": "Example"}. Add site_id or org_id when known to skip scope lookups.
It returns exact SSID matches, VLAN, isolation, mDNS/SSDP filtering and Bonjour service evidence,
including template-derived WLANs, without dumping clients or full site settings. The same evidence helps
investigate Sonos and AirPlay discovery, but does not verify playback or cross-VLAN reachability.
Automatic scope discovery is limited to 10 sites (at most four concurrent WLAN reads).
Multiple orgs, larger scopes and duplicate SSIDs require explicit target selection;
incomplete reads are reported, never treated as a healthy network or an absent SSID.
This tool only reads: findings do not confirm printer reachability or trigger a change.
mist_list_wlans also includes discovery settings so a separate full WLAN read is often unnecessary.
See implementation and validation notes for usage, limitations, the two-MCP-call offline regression scenario and Sonos/AirPlay follow-up evidence.
API failures keep their existing error, status, detail, request_id and url fields, and add
code and guidance: permission_denied for 403, rate_limited for 429, upstream_error for 5xx,
and api_error otherwise. A valid Retry-After header also supplies retry_after_seconds.
The existing login_missing and login_expired replies are unchanged.
Transport failures report timeout or connection_error. After a write timeout, the outcome is unknown:
check the target's current state before retrying. Writes are never resent automatically, including after
401; renewable logins refresh and resend only plain reads.
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.
A later offline comparison uses merged PR #12 (72e41ce) as its baseline. The original
75-question held-out dataset was unavailable; these are 36 new synthetic evaluation questions
(12 per product), frozen before router edits. Only aggregate evaluation baseline scores were inspected
before tuning; evaluation misses were not used. This small sample is not evidence of equivalent gains
on real requests or on the original 75 questions.
The additional 30-question development set exposed a general parsing error: a leading product name
or alias hid the following action verb. find_tool now skips those prefixes when reading intent.
Scoring weights, candidate retrieval, tool summaries, the shipped index and dependencies are unchanged.
Product | First, filtered | Top 3, filtered | First, unfiltered | Top 3, unfiltered | MRR, filtered |
Central | 10/12 → 12/12 | 11/12 → 12/12 | 10/12 → 12/12 | 11/12 → 12/12 | 0.8869 → 1.0000 |
Mist | 10/12 → 11/12 | 12/12 → 12/12 | 9/12 → 10/12 | 12/12 → 12/12 | 0.9167 → 0.9583 |
ClearPass | 10/12 → 11/12 | 12/12 → 12/12 | 10/12 → 11/12 | 12/12 → 12/12 | 0.9028 → 0.9583 |
Top-ten accuracy remains 12/12 for every product in both modes. Warm filtered top-three p50/p95 was 0.72/5.37 ms before and 0.80/5.95 ms after in this local measurement, below the unchanged 50 ms p95 limit. The original 60-question benchmark's per-product accuracy is unchanged in both modes; its p50/p95 was 0.51/2.27 ms before and 0.53/2.29 ms after. Timings are descriptive, not portable speed guarantees.
Two filtered evaluation first-pick failures remain: "show WLAN security for one WLAN" and
"show every authentication service"; each acceptable answer is second. Unfiltered evaluation also
prefers Central's overview for "show the site health overview". No further tuning used these misses.
The new development set also exposes a limitation: without a product filter, "mist restart an access point"
drops out of the top three (Mist unfiltered development top-three: 11/11 → 10/11). These measurements
predate the product-routing fix: an unambiguous product name or alias now restricts plain-language results
to that product when no explicit filter is supplied. Explicit filters and exact API matches take precedence;
requests naming several products remain unfiltered.
The benchmark now reports every wrong-first result with its expected rank, separately from top-three misses, plus per-product filtered/unfiltered top-one, top-three, top-ten and MRR:
uv run python scripts/bench_find_tool.py --questions tests/bench/find_tool_evaluation.yaml
uv run python scripts/bench_find_tool.py --questions tests/bench/find_tool_evaluation.yaml --jsonDataset provenance, development failure categories and frozen baseline hashes are in
tests/bench/README.md. This evaluation set is now regression data; another
tuning cycle needs a fresh evaluation set. Tests guard each product's first/top-three scores independently,
so improvements elsewhere cannot conceal regressions.
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 a non-disruptive troubleshooting check (ping, show). Names come from find_tool.
Cable tests can interrupt a link and require invoke_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.
login: a named Central login from access_check (default: the main one).
all_pages: fetch every page of a list here (up to 50 pages / 10,000 items) instead of one.
fields: keep only these keys of each item ("radio.channel" reaches inside); cuts big replies.
group_by: return a count per value of this field instead of the items ("firmwareVersion").
Together they answer site-wide questions in one call: all_pages + group_by="status".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| login | No | ||
| cursor | No | ||
| fields | No | ||
| group_by | No | ||
| all_pages | No | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the exact refusal error for mutating tools, the link-interruption caveat that routes cable tests elsewhere, and concrete pagination caps (50 pages / 10,000 items). It does not describe error shapes or response structure, keeping it just short of 5.
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?
Purpose and the invoke_tool boundary are front-loaded, followed by compact parameter notes; nearly every line carries information. It is somewhat list-heavy and the pagination/group_by examples could be tighter, but there is little waste.
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 a 7-parameter, no-output-schema tool, the description covers routing, refusal behavior, paging limits, and field/group_by semantics, plus an example combining all_pages + group_by. The unexplained 'arguments' parameter and absence of response-shape notes leave a modest gap.
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 burden, and it explains most parameters substantively: cursor as 'next_cursor from a reply cut short', login as a named Central login defaulting to main, all_pages limits, fields with dot-path nesting ('radio.channel'), and group_by with an example ('firmwareVersion'). The 'arguments' parameter is left unexplained, which keeps it from a 5.
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 ('Run a tool that only reads, or a non-disruptive troubleshooting check') and names the source of the name ('Names come from find_tool'). It also explicitly distinguishes itself from the sibling invoke_tool by noting cable tests and mutating tools belong there.
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?
Gives explicit routing rules: read-only/non-disruptive work uses this tool, while cable tests 'require invoke_tool' and changing tools are 'refused with not_a_read_tool'. The agent knows when to use this tool and when to use the alternative, without inference.
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.
login: a named Central login from access_check (default: the main one).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| login | No | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds real context beyond them by explaining that mutation scope is delegated to the discovered tool's 'kind' and that logins come from access_check — but it says nothing about error behavior, whether results are passed through, or what happens when the invoked tool is destructive.
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 core statement is front-loaded and the whole thing is short, but the formatting is scrappy (stray indentation, a dangling 'login:' fragment) and the phrase 'the tool's own kind (from find_tool) says what it changes' is indirect enough to require rereading.
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 a generic dispatcher with three parameters, zero schema descriptions, and no output schema, the description is too thin: it does not explain the argument-object contract, result shape, or failure modes. The login note is the only substantive addition.
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 parameter burden. It explains only 'login' (a named Central login from access_check, defaulting to the main one); 'name' is merely implied to be the find_tool tool name, and 'arguments' — the free-form pass-through object — is not described at all, which is the largest gap for a dispatcher.
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 verb and resource — run any tool discovered via find_tool — and notes it covers tools 'that change the network,' which implicitly distinguishes it from the read-only sibling invoke_read_tool. It is clear what the tool does, though the contrast with invoke_read_tool is only implied rather than stated.
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 establishes the prerequisite workflow (discover with find_tool, resolve credentials with access_check), which is genuinely useful routing guidance. However, it never states when an agent should pick invoke_tool over the sibling invoke_read_tool for non-mutating calls, leaving the most important selection decision to inference.
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.6invoke_read_tool4 fields changedInput schema / properties / all_pagesAdded value: +{
+ "default": false,
+ "title": "All Pages",
+ "type": "boolean"
+}Input schema / properties / fieldsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Fields"
+}Input schema / properties / group_byAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Group By"
+}Input schema / properties / loginAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Login"
+}invoke_tool1 field changedInput schema / properties / loginAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Login"
+}v0.1.0access_checkfind_toolinvoke_read_toolinvoke_toolScored across 4 tools
The four tools have largely distinct roles: discovery (find_tool), authentication/status (access_check), safe execution (invoke_read_tool), and full execution (invoke_tool). The read/write split between the two invoke tools is clear and enforced, though agents must first discover a tool's kind before choosing the right invoker.
Three tools follow a verb_noun pattern (find_tool, invoke_tool, invoke_read_tool), while access_check uses noun_verb ordering. This is a minor deviation and all names remain readable and semantically clear.
Four meta-tools are exactly right for a gateway that fronts a large external API surface via discovery rather than exposing every endpoint directly. Each tool has a distinct, necessary role.
The surface covers discovery with schema lookup, authentication inspection, read-only execution, and mutating execution, with pagination and field filtering handled in the read path. A direct way to list all available tool kinds without a query is absent but workable through find_tool.
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.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
