HPE Aruba Central(New Central)을 위한 Python 도구 — 네트워크 장치 마이그레이션, SSID 구성, 스위치 프로비저닝 및 GreenLake 플랫폼 관리.
Claude Code MCP 서버로 작동하여 대화형으로 네트워크 운영을 수행할 수 있으며, 배치 마이그레이션 워크플로우를 위한 독립형 CLI 도구로도 사용할 수 있습니다.
3개 도메인 서버(모니터링, 구성, 운영)에 걸친 88개의 MCP 도구
8단계 마이그레이션 파이프라인 — 장치 검색 → 구성 확인 → New Central로 푸시
범위 맵 타겟팅(조직 전체, 사이트 또는 그룹)을 통한 SSID 생성/삭제
스위치 프로비저닝: VLAN, 포트 프로필, SVI
GreenLake 플랫폼(GLP) 구독 및 장치 관리
비동기 문제 해결: ping, traceroute, 케이블 테스트, PoE 바운스, 재부팅
Related MCP server: HPE Aruba Networking Central MCP Server
Python ≥ 3.10
uv (권장) 또는 pip
API 자격 증명(OAuth2 클라이언트 ID + 비밀번호)이 있는 HPE Aruba Central 계정
# 1. Clone and install dependencies
git clone https://github.com/your-org/API-Central.git
cd API-Central
uv sync
# 2. Configure credentials
cp config/credentials.yaml.example config/credentials.yaml
# Edit config/credentials.yaml — fill in client_id, client_secret, base_url
# 3. Configure MCP servers (for Claude Code integration)
cp .mcp.json.example .mcp.json
# Edit .mcp.json — replace /path/to/API-Central with your actual clone path보안:
config/credentials.yaml및.mcp.json은 git-ignored 처리되어 있습니다. 절대 커밋하지 마십시오.
.mcp.json이 구성되면 이 디렉토리에서 Claude Code를 시작하십시오. 3개의 MCP 서버(aruba-monitoring, aruba-config, aruba-ops)가 자동으로 로드됩니다.
프롬프트 예시:
"Home Lab 사이트의 모든 장치 나열해줘"
"모든 AP에 대해 VLAN 100에서 Corp-WiFi라는 WPA3 SSID를 생성해줘"
"스위치 SN123456에서 8.8.8.8로 핑을 보내줘"
python run_pipeline.py --input inputs/devices.csv전체 8단계 마이그레이션(검색 → 할당 → 구성 → 확인)을 실행합니다. 멱등성(Idempotent)을 보장하므로 다시 실행해도 안전합니다.
python run_ssid.py대화형 SSID 생성/삭제 워크플로우입니다.
mcp_servers/
monitoring.py Monitoring tools (health, trends, wireless metrics)
config.py Config tools (SSIDs, VLANs, profiles, webhooks, firmware)
ops.py Ops tools (reboots, ping, cable test, PoE bounce, GLP)
shared.py Shared utilities
pipeline/
clients/ CentralClient, GLPClient, MCPClient, TokenManager
stages/ s1_discover → s8_verify
config.py Credential loader
ssid_underlay.py SSID build/delete logic
config/
credentials.yaml.example Template — copy to credentials.yaml and fill in
resources/ Postman download script (collections git-ignored — see resources/README.md)
inputs/ CSV templates for batch migration
tests/ Unit + integration testspytest tests/모든 테스트는 모의 자격 증명을 사용하며 실제 API 호출은 이루어지지 않습니다.
다음 내용은 CLAUDE.md를 참조하십시오:
전체 MCP 도구 참조 및 동사/명사 명명 규칙
범위 및 장치 유형 변환 규칙
API 엔드포인트 패턴
토큰 비용 최적화 팁
자격 증명은 런타임 시 config/credentials.yaml(git-ignored)에서 로드됩니다.
소스 파일에 하드코딩된 비밀 정보는 없습니다.
토큰 캐시 파일(.token_cache_*.json)은 git-ignored 처리됩니다.
MCP 서버 구성(.mcp.json)은 로컬 경로를 포함하므로 git-ignored 처리됩니다.
보안 문제는 GitHub Issues를 통해 보고해 주십시오. 버그 보고서에 자격 증명을 포함하지 마십시오.
Ask Aruba/HPE docs for a compact cited answer.
Use this for prose/how-to questions when you want a short answer instead of raw retrieval hits. Exact endpoint/schema questions should still use lookup_api first.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns a 'compact cited answer' rather than raw retrieval hits, which provides additional behavioral context about the response format. However, it could elaborate more on the nature of citations or any side effects, though annotations already cover safety.
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 description is extremely concise at two sentences, with no redundant or filler content. It front-loads the core purpose and immediately provides usage guidance, making every sentence earn 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 a simple query tool with good annotations and clear purpose, the description is mostly complete. It covers purpose, usage guidance, and distinguishes from a key sibling. However, it lacks details about the return structure (e.g., format of cited answer) and does not mention the top_k parameter. Still, it is sufficient for an agent to understand and use the tool correctly.
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 has 2 parameters (query, top_k) with 0% description coverage in schema. The tool description only implicitly mentions the query via context, but does not explain top_k or specify formats. Given the low schema coverage, the description should compensate but fails to add meaningful parameter semantics beyond the parameter names.
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 clearly states the tool asks Aruba/HPE docs for a compact cited answer. It distinguishes itself from siblings like lookup_api by specifying usage for prose/how-to questions versus exact endpoint/schema questions, making its purpose distinct and unambiguous.
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?
The description explicitly provides usage context: use for prose/how-to questions when a short answer is desired, and not for exact endpoint/schema questions which should use lookup_api. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate already-retrieved observations against a declarative compliance policy.
Pure, bounded, read-only evaluation only -- this never calls
invoke_tool/invoke_read_tool or any backend itself, and never fetches
anything. Fetch device/config/inventory state first (e.g. one or more
invoke_read_tool results), then pass the already-retrieved data here
as observations alongside a declarative policy. The architecture
is inspired by NAPALM's compliance_report (a fixed comparison-
operator dispatch table evaluated over structured state) and by
Nornir-style aggregate run counts, but is implemented independently
in pipeline/compliance.py with this repository's own bounds and
conventions -- no eval/exec, no arbitrary expressions, no dynamic
imports, and no write/destructive tool is ever reachable from here.
Args: observations: bounded (max 100) list of objects, one per device/ entity already retrieved by the caller (e.g. a single invoke_read_tool result, or one element of a list response). Never fetched by this tool. policy: bounded (max 50) list of rule objects, each with "field" (a dotted/indexed path, e.g. "interfaces[0].status" or "firmware.version" -- Mapping key lookup and Sequence integer indexing only, never eval/attribute access), "operator" (one of "eq", "ne", "lt", "le", "gt", "ge", "contains", "in", "regex_fullmatch", "version_gte", "version_range", "exists", "not_exists"), and "expected" (required for every operator except exists/not_exists). Optional per-rule "id" (defaults to "rule_"), "severity" ("critical"/"error"/"warning"/ "info", default "error", informational only -- it does not change pass/fail logic), and "optional" (bool, default False -- a missing field on an optional rule is reported "skipped" instead of "error"). A structurally invalid policy (unknown operator, malformed field path, an "expected" shape that does not match its operator, an unparsable regex/ version value, or exceeding a bound) is rejected before any observation is evaluated. policy_id: free-text label carried through into the report and artifact only. max_result_entries: bounded per-rule result detail cap (default 200, max 500). Aggregate counts always reflect the true total even when the detail list is capped -- see "results_truncated"/"results_total".
Returns "ok", "compliant" (True only when every rule for every observation passed or was explicitly skipped -- never True while any "fail"/"error" result exists), "counts" (pass/fail/error/skipped totals), "observations" (per-observation compliant flag + counts), "results" (bounded per-rule detail), "results_total"/ "results_truncated", and "artifact" (a compliance_report-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool). A structurally invalid policy/ observations input fails closed with "ok": False and a bounded "error" message before any rule evaluation begins.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | ||
| policy_id | No | ad-hoc | |
| observations | Yes | ||
| max_result_entries | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readonly, idempotent, non-destructive. The description reinforces this with 'pure, bounded, read-only evaluation only' and details bounds, error handling, and lack of write operations. No contradiction.
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 description is lengthy but well-structured with clear sections. It front-loads purpose and provides detailed arg descriptions. Slightly verbose but every sentence adds value.
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?
Given the tool's complexity (4 params, output schema exists), the description covers all necessary context: return shape, bounds, error behavior, artifact handling. Complete without gaps.
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%, but the description compensates fully by explaining each parameter: observations (bounded list), policy (detailed structure with field/operator/expected), policy_id (free-text label), max_result_entries (default+max).
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 clearly states the tool evaluates already-retrieved observations against a compliance policy. It distinguishes itself from data-fetching tools by explicitly noting it never fetches data itself.
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?
The description explicitly says to fetch data first using invoke_read_tool, then pass it here. It gives guidance on what not to do (no backend calls). However, it does not compare with sibling tools like plan_reconciliation_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a client by name / MAC / IP.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is clear. The description adds that the search is by name, MAC, or IP, but no additional behavioral details (e.g., case sensitivity, partial matching). No contradiction with 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?
The description is a single 7-word sentence: 'Find a client by name / MAC / IP.' It is front-loaded, concise, and contains no extraneous information. Every word is necessary.
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?
Given the low complexity (1 required parameter, no enums, no nested objects) and the presence of an output schema, the description is complete. It clearly explains what the tool does and what the input parameter represents.
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 input schema has 0% description coverage for parameters, but the description compensates by stating the query can be a name, MAC, or IP. This adds necessary context to the otherwise bare 'query' string parameter, helping the agent understand valid input types.
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 clearly states the tool's purpose: 'Find a client by name / MAC / IP.' It specifies the verb 'find,' the resource 'client,' and the search criteria, distinguishing it from siblings like find_device (searches devices) and find_tool (searches tools).
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?
The description implies usage when you have a name, MAC, or IP to identify a client, but it does not provide explicit guidance on when to use this tool versus alternatives, such as list_devices or lookup_api. No exclusions or alternate tool mentions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a device by serial number.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral traits beyond stating the search criterion, which is consistent with 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?
The description is a single sentence that is front-loaded with the verb and resource. Every word earns its place; there is no 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 simple tool with one parameter and full annotations, the description is complete. It tells the agent exactly what the tool does and how to use it. The presence of an output schema means return values are adequately documented elsewhere.
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%, but the description adds meaning by stating 'by serial number', indicating that the 'query' parameter should contain a serial number. This compensates for the lack of parameter description in the 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 clearly states the action 'Find' and the resource 'device', with the specific criterion 'by serial number'. This distinguishes it from sibling tools like list_devices (which lists all devices) and find_client/find_tool (different resources).
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?
The description implies usage for searching a specific device by serial number, providing clear context. It doesn't explicitly state when not to use or mention alternatives, but the differentiation is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; semantic matches are annotated 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 both 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 aruba-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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| origin | No | ||
| server | No | ||
| platform | No | ||
| capability | No | ||
| operation_id | No | ||
| include_schema | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals deduplication, match annotation types, safety flag mirroring, and compact default results. No contradictions.
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 description is well-structured with a clear opening, usage note, result details, and parameter list. Some redundancy could be trimmed, but overall effective and front-loaded.
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?
Given the tool's complexity (8 parameters, output schema), the description covers all essential aspects: usage, filters, defaults, and integration with sibling tools. Output schema exists so return values need not be 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?
Despite 0% schema description coverage, the tool description provides detailed explanations for all 8 parameters in the Args section, adding significant meaning beyond the 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 clearly states the tool finds tools by query using semantic search and keyword matching. It distinguishes itself from sibling tools like 'search_docs' and 'invoke_tool' by being the discovery step.
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?
Explicitly says 'Call this first when you need an action.' Provides actionable guidance on how to use the returned name with invoke_read_tool or invoke_tool, and when to set include_schema=True.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the global (org-wide) scope-id.
| 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, and destructiveHint, so the description's role is lighter. It adds value by specifying the exact return value (global scope-id), which is not fully covered by 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?
Single sentence, front-loaded, no superfluous text. Every word is necessary and informative.
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?
Given the tool has no parameters, a rich set of annotations, and an output schema, the description is complete for its simplicity. It clearly states the output.
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?
No parameters exist, so the description cannot add parameter semantics. With zero parameters, baseline score is 4 per guidelines.
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 clearly states the verb 'return' and the specific resource 'global (org-wide) scope-id', effectively distinguishing it from siblings like list_scopes which returns multiple scopes.
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?
No guidance on when to use this tool versus alternatives like list_scopes or other sibling tools. The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| cursor | No | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the annotations: it refuses non-read-only tools, and thoroughly explains cursor semantics including process-locality, integrity protection, time-limits, binding to tool name/arguments, and error behavior for invalid cursors. This goes well beyond the readOnlyHint/idempotentHint 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?
The description is front-loaded with the main purpose and usage guidance, followed by a structured 'Args' section that details cursor behavior. The cursor explanation is long but necessary and well-organized. Overall, it is appropriately concise without being under-specified.
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 dispatcher tool with no output schema, the description covers the primary use case, restrictions, and error behavior for cursors. It could mention how arguments should be structured or what the return format looks like, but these are somewhat incidental given the tool's nature. It is sufficiently complete for an agent to invoke it correctly.
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 cursor parameter is explained in great detail, which is crucial for its opaque nature. However, the 'arguments' parameter is not described at all beyond the schema, and 'name' is only implied as coming from find_tool. With 0% schema description coverage, the description partially compensates but leaves gaps for the arguments parameter.
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 clearly states it calls a read-only Aruba tool by name, which is a specific verb-resource pairing. It distinguishes itself from the sibling invoke_tool by explicitly limiting to read-only tools.
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 explicitly says to use this tool for read-only tools and to use invoke_tool for write/destructive tools after explicit user intent. This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch a bounded, ordered batch of read-only tool calls in one round trip.
Nornir-inspired bounded fan-out: each entry in calls is
dispatched sequentially (no concurrency in this version --
deterministic ordering and rate-limit safety over throughput)
through the identical read-only gate/response-bounding path
invoke_read_tool itself uses. One call's failure never aborts
the rest: every call gets its own ordered result entry plus
rolled-up aggregate counts, never a raised exception and never
a success-shaped failure. A write/destructive/unknown tool named in
any entry is rejected for that entry alone and never reaches the
backend (same gate as invoke_read_tool).
Args: calls: bounded (max 25) ordered list of call objects, each with required "name" (exact backend tool name from find_tool), optional "arguments" (object, default {}), optional "id" (caller-supplied correlation string, max 100 chars, unique within the batch -- defaults to the call's list index as a string), and optional "cursor" (an opaque next_cursor from a previous truncated single-call or batch-item read of this exact tool+arguments, resumed exactly like invoke_read_tool's own cursor argument). "arguments" is bounded to 20,000 serialized bytes and 8 levels of nesting per call -- an oversized/malformed call entry is rejected with status "invalid_call" before any dispatch is attempted for that entry, and never included in a validation-error message (so a secret placed in "arguments" is never echoed back). Duplicate ids reject the whole batch before any dispatch: correlating results by id is the point of supplying one, and silently returning two entries with the same id would make that impossible.
Rate limiting is charged per backend call, not per batch, so a 25-call batch draws 25 tokens from the same bucket a single invoke_read_tool call draws one from.
Returns "ok" (True only when every call in the batch succeeded -- never True while any failure exists), "results" (ordered list, one entry per call, each with "index", "id", "tool", "server", "status" -- one of "ok", "error", "blocked", "unknown_tool", "invalid_cursor", "invalid_call" -- and either "result" (on "ok") or "error" (bounded to 500 characters, otherwise)), "counts" ("total"/"succeeded"/ "failed"), "failed_ids" and "failed_indexes" (both ordered, one entry per failed call), and "truncated" (True when the response had to be shrunk to fit the configured byte budget -- CENTRALMCP_ROUTER_BATCH_RESPONSE_MAX_BYTES, default 300000). Each item additionally gets its own share of that budget while dispatching, so no single call can consume the whole batch's budget. The returned response is strictly within budget.
| Name | Required | Description | Default |
|---|---|---|---|
| calls | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds detail: sequential dispatch (no concurrency), per-call rate limiting, failure isolation (never aborts rest), and budget handling. This adds context beyond 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?
The description is comprehensive but lengthy. It is well-structured with paragraphs and bullet points, but could be more concise. Some detail, like the budget explanation, could be shortened.
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?
Given the tool's complexity (batch, validation, rate limiting, budget), the description is thorough. It covers behavior, validation, response structure, and edge cases. Output schema exists, so return values are sufficiently documented.
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% at the top level, but the description explains each field within the batch call: name, arguments, id, cursor, with bounds (max 25 calls, argument size, nesting). It adds meaning beyond the schema's inline descriptions.
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 clearly states it dispatches a bounded, ordered batch of read-only tool calls. It uses specific verbs like 'dispatch' and 'batch', and contrasts with the single-call sibling invoke_read_tool.
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 explains when to use: for multiple read-only calls to reduce round trips. It notes sequential dispatch and failure handling. It doesn't explicitly list when not to use, but the read-only hint and mention of write rejection imply exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 FastMCP tool manager, so arguments
get FastMCP 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. (FastMCP injects ctx here and strips it from the
published schema, so callers only pass name + arguments.)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes FastMCP dispatch, context injection for confirmation, and schema stripping. Adds detail beyond annotations (`destructiveHint: true`).
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?
Concise paragraph with example and explanation. Every sentence adds value, though slightly longer than necessary.
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 and description does not explain return value (e.g., what the called tool returns). Omits error handling or side effects beyond destructive hint.
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 description compensates minimally by explaining `name` comes from `find_tool` and `arguments` is a kwargs dict with an example. No per-parameter details but sufficient for basic use.
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?
Clearly states it calls an Aruba tool by name with arguments dict, distinguishes from `invoke_read_tool` and references `find_tool` for name discovery.
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?
Provides example, explains that arguments get FastMCP validation, and notes it handles destructive ops requiring confirmation. Doesn't explicitly contrast with `invoke_read_tool` but context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List devices (paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'paginated' as behavioral context. No contradiction, but adds limited extra value beyond 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?
Single sentence with no redundancy. Front-loaded with core purpose and pagination hint. Every word 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?
Tool has output schema and is simple. Description is adequate for a basic list, but lacks differentiation from sibling find_device. Could mention it returns all devices versus filtering.
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% with two parameters (limit, offset) lacking descriptions. The description hints at pagination, which implies their use. This compensates well, though explicit mapping would improve clarity.
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?
Description explicitly states 'List devices (paginated).' with a clear verb and resource. Distinguishes from sibling tools like find_device (specific device search) and list_sites (different resource).
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?
No explicit guidance on when to use vs alternatives. Usage is implied for browsing all devices, but no exclusions or references to sibling tools like find_device for specific searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Central scopes (sites, groups, global) — ID + name (paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| full_list | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is clear. The description adds that the response is paginated and returns ID and name, but does not explain the behavior of the full_list parameter or other relevant traits.
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 description is a single, concise sentence that is front-loaded with the key information. Every word adds value, and there is no unnecessary text.
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?
The tool is simple and has an output schema, so the description is partially adequate. However, it fails to explain the full_list parameter or usage context, leaving gaps for the agent.
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 schema has 0% description coverage, yet the description does not explain the purpose or behavior of the three parameters (limit, offset, full_list). The agent cannot determine how to use these parameters from the description alone.
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 clearly states the verb 'List' and the resource 'Central scopes', specifying that they include sites, groups, and global. It also mentions the returned data (ID + name) and pagination. This distinguishes it from sibling tools like list_sites.
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?
The description provides no guidance on when to use this tool versus alternatives such as list_sites. It does not mention any prerequisites or context where one would prefer this over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sites (paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds 'paginated', a useful behavioral detail, but omits other aspects like sorting or filtering.
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?
One sentence, no redundant words. Clearly front-loaded with 'List sites'.
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?
Output schema exists, so return values not needed. Tool is simple; description and annotations cover core behavior. Could add clarification on what constitutes a 'site' but not critical given sibling context.
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 description must compensate. 'Paginated' implies limit/offset control pagination, but doesn't explain defaults (50, 0) or semantics. Partial compensation.
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?
Description clearly states verb 'list' and resource 'sites', and notes 'paginated' which distinguishes from potential non-paginated siblings. However, it could be more specific about the scope or criteria.
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?
No explicit guidance on when to use vs. alternatives like list_devices or list_scopes. Agent must infer from resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact Aruba Central API lookup — endpoints, schemas, fields, enum values.
Use INSTEAD of search_docs for "what enum values does field X accept", "which endpoint configures Y and with what method", or "what fields does schema Z have". Authoritative answers from the parsed OpenAPI specs. Returns [] when the specs hold no confident answer — fall back to search_docs in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating safe read operations. The description adds value by disclosing that the tool returns an empty array when it lacks a confident answer, which is useful behavioral context beyond 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?
The description is extremely concise—four short sentences—front-loaded with the core purpose, followed by clear usage guidelines. Every sentence contributes essential information without redundancy.
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?
The tool has no output schema, so the description should clarify what the tool returns. It mentions 'endpoints, schemas, fields, enum values' but does not describe the response structure. Parameter semantics are missing, leaving the agent partially informed. Despite good usage guidance, the lack of param and output detail limits completeness.
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 must compensate by explaining parameters. However, the description does not mention 'query' or 'top_k' at all, providing no additional meaning beyond the schema's basic type and default. This is a significant 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?
The description clearly states the tool provides an 'Exact Aruba Central API lookup — endpoints, schemas, fields, enum values.' It uses specific verbs and resources, and explicitly distinguishes itself from the sibling 'search_docs' tool by listing concrete use cases.
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?
The description gives explicit when-to-use guidance: 'Use INSTEAD of search_docs for ...' with specific examples, and also provides fallback instructions: 'Returns [] when the specs hold no confident answer — fall back to search_docs in that case.' This fully clarifies when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a bounded, read-only, plan-only recurring reconciliation schedule.
Never creates an OS timer, cron job, or GitHub Actions schedule, and never executes a tool -- this only validates a cadence and resolves a bounded set of currently enabled tools into a schedule specification. Write/destructive tools are always excluded from the executable entry list (reported in "excluded" instead, with a reason), regardless of whether the caller explicitly requested them.
Args: cadence: either a named cadence string ("hourly", "daily", "weekly") or an object such as {"kind": "interval_minutes", "interval_minutes": 30} or {"kind": "cron", "expression": "*/15 * * * *"}. Validated structurally only -- never parsed into an actual next-run time or registered as a real schedule. tools: exact tool names to resolve via the loaded catalog. Omit to fall back to the platforms/servers filters below. platforms: normalized platform filter (e.g. "central", "glp") applied to the loaded catalog when tools is omitted. servers: exact backend server name filter (e.g. "aruba-monitoring") applied to the loaded catalog when tools is omitted. max_entries: safety ceiling on schedule entries (default 50, max 100).
Returns "ok", "cadence" (validated descriptor), "entries" (read/diagnostic tools only), "excluded" (everything else, with a reason), "dry_run" (always True), and "artifact" (a router_reconciliation_plan-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool).
| Name | Required | Description | Default |
|---|---|---|---|
| tools | No | ||
| cadence | Yes | ||
| servers | No | ||
| platforms | No | ||
| max_entries | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, etc.) are supplemented by the description detailing that the tool never writes to disk, always returns dry_run=True, and excludes write/destructive tools. No contradiction with 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?
The description is relatively long but well-structured, front-loading the core purpose. Each sentence adds value, though some details could be slightly condensed. Overall efficient given complexity.
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?
The description covers input parameters, behavioral constraints, return values (ok, cadence, entries, excluded, dry_run, artifact), and mentions output schema indirectly. Complete for a complex read-only tool with good annotations.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: cadence with examples, tools, platforms, servers, max_entries (including default and max). Adds significant meaning beyond the basic schema types.
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 clearly states the tool's purpose: 'Build a bounded, read-only, plan-only recurring reconciliation schedule.' It distinguishes from sibling tools by emphasizing that it never creates a real schedule or executes a tool, providing a specific verb+resource and scope.
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?
The description explicitly states when to use this tool: it only validates a cadence and produces a schedule specification. It explicitly says it never creates OS timers, cron jobs, or executes tools, guiding the agent to use siblings for actual execution. This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a deterministic, read-only dependency/order plan across enabled backend tools.
Never executes any tool. Every resolved tool reference is checked only against the currently loaded, enabled backend catalog (the same index find_tool searches) -- an unresolved or ambiguous reference is reported explicitly, never guessed or silently dropped.
Args: steps: bounded (max 25) list of step specs. Each step is a dict: - "id": optional stable step id (str); defaults to "step_". - "tool": exact tool name to resolve via the loaded catalog (preferred -- deterministic, exact match, never guessed). - "hint": free-text action description used only when "tool" is omitted; resolved via the same bounded keyword search find_tool uses (no semantic/embedding guessing). Marked "ambiguous" when multiple close-scoring candidates exist. - "depends_on": list of step ids (or exact tool names) that must run before this step. include_candidates: include up to 5 scored candidate tools per unresolved/ambiguous step. Defaults to False to keep the plan compact.
Returns "ok", "steps" (resolved metadata per step), "order" (topological order, or None whenever any step/dependency is unresolved or the graph has a cycle), "acyclic", "cycles", "unresolved_step_ids", "unresolved_dependencies", and "artifact" (a router_dependency_plan-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool). This never calls invoke_tool/invoke_read_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | ||
| include_candidates | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by detailing that tool references are checked against the loaded catalog, never guessed, and unresolved references reported explicitly. No contradictions.
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 description is thorough but slightly long. However, it is well-structured with clear sections and bullet-like list for step spec fields. Could be more concise, but still effective.
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?
Given the complexity of a planning tool with nested steps and dependencies, the description covers all aspects: input parameters, constraints (max 25 steps), resolution logic, return fields, and behavior. Output schema exists but description adds necessary context.
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%, but the description fully explains both parameters: steps (bounded max 25, each step dict with id, tool, hint, depends_on) and include_candidates (default false, returns up to 5 candidates). Also explains return fields in detail.
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 clearly states it builds a deterministic, read-only dependency/order plan across enabled backend tools. It uses specific verbs and resources, and distinguishes itself from siblings like invoke_tool and find_tool.
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?
Explicitly says 'Never executes any tool' and explains when to use (planning dependencies) and when not (execution). Provides alternative: find_tool for searching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Aruba/HPE documentation (Central config, APIs, NAC, VSG).
For EXACT API questions (enum values, endpoints, schema fields) prefer lookup_api — it is lossless; this is fuzzy retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by describing it as 'fuzzy retrieval' and noting lookup_api is 'lossless'. Annotations already declare readOnlyHint and idempotentHint, which are consistent with search behavior.
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 sentences front-load purpose and provide usage guidance concisely. No wasted words.
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 and no parameter details. Does not explain return values or differentiate fully from siblings like ask_docs. Incomplete for a search tool with multiple parameters.
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?
With 0% schema description coverage, the description fails to explain the meaning of parameters like top_k and source. Only implies query usage via context. Minimal help for parameter understanding.
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 clearly states it searches Aruba/HPE documentation with specific topics (Central config, APIs, NAC, VSG). It distinguishes from lookup_api, but could specify the exact scope of documentation.
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?
Explicitly advises to use lookup_api for exact API questions, offering a clear alternative. Does not address other siblings like ask_docs, limiting comprehensive guidance.
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.7.0evaluate_compliance_policyfind_tool2 fields changedInput schema / properties / operation_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Operation Id"
+}Input schema / properties / originAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "curated",
+ "generated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Origin"
+}invoke_read_tool1 field changedInput schema / properties / cursorAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Cursor"
+}invoke_read_tool_batchinvoke_toollist_sitesplan_reconciliation_scheduleplan_tool_workflowv0.4.0find_tool3 fields changedInput schema / properties / capabilityAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "read",
+ "diagnostic",
+ "write",
+ "destructive"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Capability"
+}Input schema / properties / platformAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Platform"
+}Input schema / properties / serverAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Server"
+}invoke_toollist_sitesv0.2.8ask_docsfind_clientfind_devicefind_toolget_global_scope_idinvoke_read_toolinvoke_toollist_deviceslist_scopeslist_siteslookup_apisearch_docsScored across 16 tools
Each tool targets a distinct purpose: documentation retrieval (ask_docs vs search_docs vs lookup_api), entity finding (find_client, find_device), list operations (list_devices, list_scopes, list_sites), invocation (invoke_read_tool, invoke_read_tool_batch, invoke_tool), planning (plan_reconciliation_schedule, plan_tool_workflow), and compliance evaluation. No two tools overlap in function.
All tool names follow a consistent verb_noun pattern with underscores (e.g., ask_docs, evaluate_compliance_policy, invoke_read_tool_batch). There are no deviations like camelCase or inconsistent verb styles.
With 16 tools, the set is well-scoped for an API Central server that provides documentation, discovery, invocation, planning, and compliance evaluation. The number is neither too few to be ineffective nor too many to be cumbersome.
The tool surface covers the full lifecycle of interacting with Aruba/HPE backends: documentation lookup, entity discovery, tool finding, read/write invocation, batch operations, policy evaluation, and task planning. No obvious gaps exist for the server's stated purpose.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Give your AI agents the tools to build, manage, and run automation workflows.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
