HPE Networking Assistant
OfficialServer Quality Checklist
Latest release: v1.14.0
- Disambiguation5/5
Each tool targets a distinct resource and action, from device inventory and client lookup to authentication troubleshooting and config diffing. Even seemingly similar tools like get_clients, get_wired_clients, and get_nac_clients are clearly differentiated by their descriptions (wireless vs. wired vs. Access Assurance). The only mild overlap is between get_access_points and get_offline_access_points, but the latter is a specific filtered view, so confusion is unlikely.
Naming Consistency5/5All tool names follow a consistent verb_noun snake_case pattern. The verbs vary semantically (generate, get, find, trace, troubleshoot, start, set, export, diff) but are predictable for their function: generate_ for reports, get_ for lists/retrievals, and so on. This consistency allows an agent to infer behavior from the name alone.
Tool Count3/5With 25 tools, the server sits at the upper boundary of the 'heavy' range (16–25). The domain is broad, covering inventory, clients, NAC, Marvis, config management, and session setup, so many tools are justified. However, some report generators (inventory, firmware, health, NAC dashboard) could potentially be consolidated, making the count feel slightly bloated.
Completeness4/5The tool surface provides thorough coverage for network observability, troubleshooting, and configuration backup/compare. It includes inventory, health, client tracking, authentication analysis, Marvis insights, alarms, SLE scores, and port-level details. The main gaps are the lack of write operations (e.g., implementing Marvis fixes) and no singular device detail lookup, but these feel intentional given the assistant's likely read-only role.
Average 3.9/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any permission requirements, default behavior when org_id is absent, or what the response contains. The 'list' verb implies non-destructiveness but this is not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no waste. It is appropriately front-loaded, though it is minimal enough that conciseness borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and only a one-line description. It does not clarify what a 'site' is, how org_id affects results, whether the list is exhaustive, or any pagination/limit behavior. An agent would have insufficient context to make nuanced decisions about invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage for the only parameter (org_id) is 100%, and the schema already states it is an optional Mist organization id. The description adds no further meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list) and resource (sites) with an organizational scope. It does not explicitly differentiate from sibling tools like get_access_points or get_organizations, but the resource name is distinct enough for basic disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context such as whether org_id is required, what happens if omitted, or how it relates to other site-related operations. The description offers no usage direction beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and 'List' does imply a read-only operation while 'optionally filtered to a site' describes a key behavior. However, it does not disclose what happens when neither org_id nor site_id is supplied, pagination behavior, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence of ten words: 'List access points (APs) in an organization, optionally filtered to a site.' Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional params and no output schema, the description covers the core list-and-filter behavior adequately. However, it omits how the target organization is determined when org_id is absent and does not acknowledge the related sibling get_offline_access_points, leaving gaps in the agent's contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both org_id and site_id documented inline. The description adds a minor semantic gloss ('filtered to a site') that aligns with site_id, but it does not clarify parameter behavior beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('access points (APs)'), and defines scope ('in an organization, optionally filtered to a site'). It is clear and unambiguous, though it does not explicitly differentiate from the closely named sibling tool get_offline_access_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_offline_access_points, get_clients, or get_switches. It does not state prerequisites, exclusions, or how the organization is resolved when org_id is omitted, so an agent gets no selection help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool's purpose and does not disclose whether it is a read-only operation, whether it requires an active organization context, what information is returned, or any side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action and scope. It is maximally concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate but leaves gaps: it does not explain whether org_id filtering is needed or how this differs from get_access_points, nor does it describe the return format. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents org_id as an optional Mist organization id (100% coverage). The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Report' and explicitly scopes to 'access points that are currently offline (disconnected)', clearly distinguishing it from the sibling tool get_access_points which presumably lists all access points. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_access_points. The description does not mention exclusions, prerequisites, or the appropriate context for selecting this tool over others in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the action and optional filter but does not clarify the default scope when org_id is omitted, nor mention pagination, authentication, or return format. This ambiguity is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the basic function, but it lacks details on default behavior when org_id is absent and the output structure. Given no annotations or output schema, some ambiguity remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The description adds only the phrase 'optionally filtered to a site,' which mirrors the schema and provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('switches') with clear scoping ('in an organization'), which clearly distinguishes it from sibling tools like get_access_points or get_clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or exclusions are mentioned, but the description implies the tool is for retrieving switches, optionally scoped to a site. The context is adequate for a straightforward listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (Markdown) and coverage (every AP and switch) but does not mention whether the operation is read-only, any required permissions, or the behavior when org_id is omitted (e.g., uses active org). These are material behavioral traits for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, grammatically clear, front-loaded with the main verb 'Generate' and immediately specifies the output format and data fields. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the purpose, output format, and included data. However, it could mention the default organization behavior and any limitations, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a 100% description for org_id, making the parameter self-explanatory. The tool description does not add any further semantics, but the baseline of 3 is appropriate given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates a full device inventory report in Markdown, enumerating specific fields (model, serial, MAC, site, status, firmware version) for both APs and switches. This distinguishes it from sibling report tools because it covers the full inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—when you need a comprehensive inventory report—but does not explicitly state when to prefer this over sibling tools like get_access_points or generate_health_report. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context by stating that the output is a self-contained HTML file the user can save and open in a browser, which clarifies the return behavior. However, it does not explicitly state whether the operation is read-only or whether any side effects occur, and it omits details about data sourcing or authentication. This is a partial, but not complete, behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and resource, and then provides return format. Every sentence carries essential information with no redundancy or filler. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional params, no output schema, no annotations), the description is sufficiently complete: it states the purpose, the dashboard contents, and the output format. It could be enhanced by mentioning data prerequisites or how to use it among alternatives, but for its complexity, this is adequate. The lack of an output schema is compensated by the explicit statement that HTML is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides for 'org_id' and 'duration'. It does offer high-level context on the dashboard content, but no direct link to parameter usage or format. Therefore, it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Build' and a specific resource: a self-contained HTML Access Assurance (NAC) dashboard. It enumerates the dashboard's components (summary cards, bar charts for auth types, client types, status, event types, and top failing users/rules) and explicitly notes the return format, making it easily distinguishable from sibling report tools like generate_inventory_report or generate_health_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling report/dashboard tools. It does not mention alternatives, exclusions, or prerequisites. While the purpose is clear, there is no explicit usage context or 'when not to use' direction, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose the types of data returned and the filtering behavior, but it does not explicitly state read-only semantics, pagination, or response format. The 'get' prefix suggests read-only, but the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the resource and enumerates data fields followed by filters. No waste words, concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by listing what statistics are returned and the available filters. However, it omits org_id as a filter and does not describe the response shape (e.g., list of ports) or any limits, leaving some gaps. Overall, sufficient for a read-only statistics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description summarizes three filters (switch_mac, site_id, up) but does not add semantic detail beyond the schema; org_id is omitted from the description. Baseline of 3 applies since the schema carries the parametric meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving switch/device port statistics and enumerates specific data fields (link state, speed/duplex, PoE, LLDP neighbor, traffic). It distinguishes from sibling tools like get_switches by focusing on port-level metrics, though it lacks an explicit verb in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used when port-level statistics are needed and lists filterable criteria (switch_mac, site_id, up), but it does not explicitly state when to prefer this over alternatives or provide exclusions. The usage context is clear but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It describes detection, discovery, validation, and report generation, which imply a read-only operation, but 'onboarding' and 'setup' could suggest configuration changes. The description does not explicitly state whether calling this tool modifies state, requires prerequisites (e.g., valid token), or fails when no orgs are accessible. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every phrase adds value. It front-loads the core action and outcome, then gives usage guidance and the optional parameter. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-step setup tool with no output schema, the description gives a good outline but remains incomplete. It does not explain what constitutes 'READY FOR USE,' whether the tool sets an active organization or writes configuration, what happens if the token is invalid, or if no organizations are accessible. These details matter for an agent deciding to invoke it under uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'organization' is complete ('Organization NAME to use when several are accessible (optional).'), and coverage is 100%. The tool description adds minimal context by saying 'to choose among multiple orgs,' which essentially restates the schema. No extra syntax, constraints, or edge-case behavior is provided, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run first-run onboarding,' which clearly states a distinct action. It lists specific steps (auto-detect Mist region, discover organizations and sites, run validation) and an output ('READY FOR USE report'), making it easy to distinguish from sibling report/data tools like generate_inventory_report or get_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this when the user is setting up or asks to get started.' This is clear contextual guidance. However, it does not mention when not to use it or point to alternatives (e.g., set_active_org for org selection without setup), so it misses the full guidance given in the highest-caliber examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation without side effects, but it does not mention authentication requirements, rate limits, or any caveats about data freshness. The description is accurate but lacks depth beyond the basic 'List' behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the verb 'List' and the resource, and efficiently includes the key output fields and filters without redundancy. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description enumerates the return fields (user, client type, auth type, SSID, VLAN, matched auth rule, status) and lists the optional filters, covering what the caller can expect. It does not mention pagination or ordering, but for a simple list tool with optional filters, this is reasonably complete. Slight gap: no explicit guidance on prerequisites or typical use cases, but the listed fields and filters are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds minimal value by repeating the filter names (mac, auth_type, type) but does not explain parameter formats, defaults beyond 'duration', or how the filters interact. It does not compensate beyond the schema's already detailed descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Access Assurance (NAC) clients authenticated to the network' with a specific verb and resource, and enumerates the returned fields (user, client type, auth type, SSID, VLAN, rule, status). This distinguishes it from sibling tools like get_clients or get_wired_clients by focusing on NAC-specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the tool's purpose and optional filters, but it does not explicitly state when to use this tool versus alternatives like find_client or get_clients. No exclusions or alternative suggestions are provided, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It describes the comparison behavior and output, but does not explicitly state that it is read-only or non-destructive. The word 'compare' implies this, but it is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and output, second clarifies the parameter. No redundancy, well front-loaded, and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, input, and high-level output. It lacks an explicit read-only note or usage example, but is otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds minimal value beyond the schema, only clarifying that baseline_file comes from export_org_config, which the schema already states. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: compare current org configuration against a backup file and report added, removed, and changed objects per resource type. This distinguishes it from sibling tools like export_org_config, which creates the baseline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly links baseline_file to 'previously produced by export_org_config', implying the workflow: export first, then diff. It does not explicitly say when not to use it, but the context is clear for a diff tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It adds the output format (Markdown) and details about the report's content, which is useful. However, it does not mention side effects, permissions, or what happens with missing data, leaving some ambiguity for a read-only report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that capture the report's purpose, format, content, and use case. Every word adds value, and the structure front-loads the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essential context: what the report contains, its format, and its intended use. It does not describe return values in detail, but the description's content overview is sufficient for a low-complexity report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (org_id) with a description, and schema coverage is 100%. The tool description does not add any additional meaning about this parameter, so it relies entirely on the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a firmware compliance report in Markdown, specifying the content (per AP/switch model, fleet version, devices behind) and the use case (finding firmware drift). This distinguishes it from sibling report tools like generate_inventory_report and generate_health_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool ('Use to find firmware drift'), which implies a specific scenario for firmware compliance analysis. However, it does not explicitly mention alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format (Mermaid plus nodes/edges), the scope (per-site), and the optional inclusion of clients. However, it does not clarify what 'save it' entails (file location, side effects) or any permissions/rate limits, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and output, then gives usage tips. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional params and no output schema, the description provides a solid overview of inputs, output, and a key flag. It lacks detailed return-value structure or error conditions, but the core usage context is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a description. The description repeats the purpose of 'site' and 'include_clients' but adds no new semantic meaning beyond the schema; it does not mention 'org_id' explicitly, though the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a per-site network topology as a Mermaid diagram with structured nodes and edges, specifying the included entities (gateways, switches, APs) and the data source (LLDP neighbors). This specific verb+resource distinguishes it from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct usage guidance: 'Provide a site name' and 'set include_clients=true' for client inclusion. The context for when to use is evident, though no explicit alternatives or exclusions are mentioned relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explains the output type (percentages, example categories) but does not mention whether the data is live, historical, requires specific permissions, or how results are structured. Some context is added, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no fluff. The first sentence defines the tool with acronym expansion and examples; the second provides a clear usage directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description explains the return value well (SLE percentages with examples) and the usage context. It does not specify the exact output structure (e.g., per-site object list), but for this low-complexity tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter org_id, so the baseline is 3. The description does not add any parameter-level detail beyond the schema, which is acceptable given the high schema coverage, but it also does not explain behavior when org_id is omitted (e.g., using active org).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns Service Level Expectations (SLE) per site as user-experience scores in percentages, with specific examples. It distinguishes itself from sibling tools by focusing on SLE specifically, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use it: 'Use to gauge experience quality by site.' It does not explicitly mention alternatives or when not to use it, but the context is clear enough given the specialized nature of SLE.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('event timeline, type counts, and highlighted failures') and implies a read-only diagnostic nature via the verb 'trace'. However, it does not explicitly state that it makes no modifications, nor does it mention any limitations or authorization requirements. While acceptable, it leaves some behavioral details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing the action, purpose, and expected outputs. Every clause earns its place, with no redundancy or filler. It is concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain what the tool returns. It explicitly lists 'event timeline, type counts, and highlighted failures', which covers the key output. The presence of the duration parameter is implied by the lookback context. It could mention how to interpret failures or whether results are ordered, but overall it provides sufficient context for a diagnostic tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter has a clear description (mac, org_id, duration). The tool description reinforces the purpose but does not add new semantic details about parameters. The baseline of 3 is appropriate because the schema already documents them sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Trace' and clearly identifies the resource: 'a wireless client's recent connection events'. It enumerates event types (association, auth, DHCP, roam, disconnect) and explicitly states the purpose: 'to troubleshoot why it can't connect or roams poorly'. This distinguishes it from sibling tools like get_clients or find_client, which list clients rather than trace event sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: 'to troubleshoot why it can't connect or roams poorly'. This provides a clear usage context. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5 which requires explicit when/when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'read-only', 'Secrets are excluded/masked', and output as JSON. This conveys non-destructiveness and security handling. It does not cover error behavior or org_id omission consequences, but for an export tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and each sentence adds value: the first covers scope and format, the second covers secret handling. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with one optional param and no output schema, the description explains output format, included scope, and security behavior. It could mention the effect of omitting org_id (e.g., using active org), but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional param org_id, including its description. The tool description adds no additional parameter semantics beyond the schema. Baseline 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Export a read-only backup of the org configuration as JSON'. It enumerates included items (sites, networks, VPNs, etc.) and distinguishes itself from siblings like generate_* reports and diff_org_config by clearly stating its backup/export nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'read-only backup' and 'for the user to save to a .json file' clearly indicate the intended use case. However, it does not explicitly mention when not to use it or compare to alternatives (e.g., diff_org_config for comparisons). The context is clear but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results include counts per severity and type, and that there is an optional severity filter. This goes beyond a simple list and gives meaningful output structure, though it does not mention pagination, ordering, or timezone details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. It effectively conveys the tool's purpose and key output details without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, 3 parameters, and no output schema, the description adequately covers inputs and the high-level output (counts). It might have explained the response shape more explicitly, but the mention of per-severity and per-type counts gives the agent enough to understand the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 3 parameters with descriptions (org_id, duration, severity), so the baseline is 3. The description reinforces the severity filter but adds no additional syntax or format details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('organization alarms') with clear scope ('over a window') and output details (per-severity and per-type counts). It distinguishes itself from sibling tools like get_marvis_actions or get_offline_access_points by focusing on aggregated alarm counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to list alarms over a time window with optional filtering by severity. It does not explicitly state when to avoid it or name alternatives, but the context and examples make the use case apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clarifies that the tool is read-only (lists clients) and scopes results org-wide or to a site, but it does not mention pagination, required permissions, data freshness, or any other operational behaviors. The 'currently connected' qualifier adds some transparency about the state of data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It immediately conveys the action, resource, and scope, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema and annotations, the description is sufficient for a simple, low-complexity list operation. It specifies the core function and scope, and the lack of return format details is acceptable for a listing tool. The only minor gap is not naming alternative tools for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described as optional. The description adds valuable meaning by explaining how the parameters affect scope: org-wide when site_id is omitted, or restricted to a single site when provided. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('wireless clients'), and clearly states scope ('org-wide or for one site'). This distinguishes it from sibling tools like get_wired_clients and find_client, which target different client types or purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool: to list currently connected wireless clients at an org or site level. It does not explicitly state exclusions or name alternatives, but the scope options are clearly communicated, making it easy to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the kind of information returned (prioritized issues and fixes), which is good, but it omits any details about response format, pagination, default behavior without org_id, or whether the list includes all statuses by default. These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The primary action and resource are in the first few words, and the second sentence provides a practical usage hint. Every sentence adds value, and the length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core functionality and the nature of the output well, especially for a read-only list tool with no output schema. It could mention whether it returns all issues by default or only open ones, but given the schema annotations and sibling context, the description is sufficient 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100%, so baseline is 3. The description adds meaning to the status parameter: 'Pass status="open" for active items only' clarifies what 'open' means and suggests a common usage. org_id is not elaborated beyond the schema, but the schema already provides a clear description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource ('List Marvis (AI) suggested actions') and clearly differentiates this tool from sibling report/alarm tools by explaining it provides Mist's prioritized view of what's wrong and recommended fixes. It mentions concrete examples of issues (offline switches/APs, firmware, ports, RF/DFS), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case: "Use for 'what's wrong with my network?'" and provides a concrete filtering tip (status='open' for active items). However, it does not explicitly mention when NOT to use this tool or point to alternatives like get_alarms or get_offline_access_points, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must self-disclose. It clarifies what constitutes a wired client (devices on switch ports) and specifies the returned fields (switch MAC, port, VLAN, IP, vendor). It also notes optional filters. It doesn't mention pagination or rate limits, but for a read-only list tool, the behavioral context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total. The first sentence immediately states the action and scope, the second describes filters and the relationship to get_clients. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema, but the description covers the tool's purpose, filter set, and sibling differentiation. It omits org_id and duration details, but those are in the schema. For a straightforward list operation, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the 5 parameters with descriptions. The description additionally names mac, hostname, and site_id as optional filters, reinforcing the schema. It does not mention org_id or duration, but the schema already documents those. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'List wired clients' providing a specific verb and resource, clarifies scope with 'devices seen on switch ports,' and lists output fields. It explicitly distinguishes from sibling get_clients by noting 'Complements get_clients (wireless).'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States the tool is for wired clients and explicitly mentions 'Complements get_clients (wireless)' to differentiate from the wireless counterpart. It also lists optional filters, implying when to use them. However, it doesn't explicitly state when not to use or alternatives beyond get_clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait: it returns the auth-event timeline, per-type counts, and highlighted failures. The phrase 'returns' strongly implies a read-only operation. While it doesn't explicitly state 'read-only' or mention rate limits/pagination, it gives substantial output detail and filtering behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, then the output, then the focus. There is no wasted text; every clause adds value. It is concise while covering the essential aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains what the tool returns (timeline, counts, failures) and the filtering criteria. It doesn't mention org_id or duration explicitly, but those are documented in the schema. It could add a bit more about use cases or limitations, but overall it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a small semantic nuance by stating 'Focus on one identity with mac and/or user', clarifying that these parameters are alternative or combinable filters. It also reiterates the meanings of mac and user but does not significantly extend the schema descriptions for org_id or duration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Troubleshoot 802.1X/MAB authentication using Access Assurance (NAC) events'. It specifies the resource (802.1X/MAB auth via NAC events), the action (troubleshoot), and the outputs (timeline, per-type counts, highlighted failures). This distinguishes it from sibling tools like get_nac_clients or generate_nac_dashboard by emphasizing identity-focused troubleshooting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Focus on one identity with mac (client MAC) and/or user (username or certificate CN)'. This implies use for drilling into a specific client's auth issues. However, it does not explicitly mention alternatives or exclusion criteria, such as when to use trace_client or find_client instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the output is Markdown that the user can save (implying no file is written directly) and that include_clients=true causes a slower org-wide client count. However, it does not mention authentication, error behavior, or what happens if org_id is omitted, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function and output format, followed by a practical note on parameter usage. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters, no output schema), the description sufficiently covers what the report contains, the output format, and a performance consideration. An agent can confidently select and invoke this tool without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context for include_clients by explaining the performance trade-off (slower when true), which goes beyond the schema's simple 'Include the org-wide wireless client count'. This extra semantic helps the agent decide how to set the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool generates a network health report in Markdown format, enumerating the content (device totals, online/offline counts, offline AP list, per-site breakdown). This clearly distinguishes it from sibling report tools like generate_inventory_report and generate_firmware_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (generating a health report) and offers a specific usage tip (setting include_clients=false to avoid a slower query). It does not explicitly mention when not to use it or list alternatives, but the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. The verb 'List' indicates a read-only operation, and the phrase 'the API token can access' adds relevant filtering behavior. However, it does not explicitly state that it does not modify anything or mention any limitations such as pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently states the tool's purpose without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters, annotations, and output schema, the description is adequately complete. It clearly explains what the tool does and what scope it operates under, making it fully usable by an agent without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides complete coverage. The description adds no parameter-specific details, but with no parameters this is not a gap. The baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'Juniper Mist organizations' with a clear scope ('the API token can access'). This clearly distinguishes it from sibling tools like get_sites or get_access_points, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to discover which organizations the current API token has access to, providing clear context. However, it does not explicitly mention when not to use it or point to alternatives such as set_active_org for selecting an organization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Report' implies a read-only operation, and the content (mode, region, org, token permissions) suggests no side effects. However, it does not explicitly state that the tool makes no changes or describe any other behavioral traits such as auth requirements or rate limits. The description adds some context beyond the name but lacks full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and followed by a usage hint. Every sentence earns its place, with no wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema), the description is complete enough. It enumerates the status information provided (mode, region, org, token change ability) and specifies when to use it. There is no return type to document, and the description covers the essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. There are no parameters to explain, and the description appropriately focuses on the tool's function rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and resource (current mode, region, organization, token permissions), making it clear what the tool does. It distinguishes itself from sibling tools which are all about generating reports, finding clients, or troubleshooting, none of which cover status/mode reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use when the user asks about their mode or write access.' This provides clear context. It does not mention alternatives or when-not-to-use, but given the unique purpose and lack of similar sibling tools, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states what the tool returns (site, AP, SSID, IP, band, signal) and the required input ('mac or hostname'). This is a read-only lookup operation, and the description is clear about its output. It does not address edge cases or error behavior, but for a simple locate function, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the target, the search criteria, and the output fields. There is no fluff or repetition of schema details—every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description sufficiently explains the return values. It does not need to explain parameters because the schema covers them. It could mention lookback behavior or error handling, but for a relatively simple lookup tool, the information provided is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already describes all four parameters (100% coverage), the description adds crucial semantics: it specifies that the caller must provide 'mac or hostname', resolving ambiguity about which parameter is required. It also clarifies that the tool specifically targets wireless clients, which is not fully explicit in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Locate' with the resource 'wireless client' and enumerates the output fields (site, AP, SSID, IP, band, signal). It clearly distinguishes from siblings like 'get_clients' (which lists clients) and 'trace_client' (which traces paths) by targeting a single client by MAC or hostname.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Provide mac or hostname', giving clear input guidance. It implies this tool is for looking up a specific client by identifier, which differentiates it from list-style siblings. However, it does not mention alternatives or exclusion criteria, so it stops short of full when-to-use versus 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool changes session state and affects subsequent tools, which is the key behavioral trait. It does not mention potential errors or persistence, but for a simple setter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and then necessary context. Every word contributes to understanding the tool's purpose and usage, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the purpose, usage condition, and effect. It does not explain return values or error handling, but for a session setter those are not critical for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Organization name or id' (100% coverage). The description adds value by explaining the purpose of the parameter: it sets the default for the session and influences subsequent tools. This goes beyond the schema's basic type/description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the default organization for this session by name or id.' It specifies the resource (default organization), the method (by name or id), and the effect (subsequent tools target the chosen org), which distinguishes it from sibling tools like get_organizations or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear condition for use: 'Useful when the token can access several organizations.' This explains when to invoke the tool. It does not explicitly mention alternatives or when not to use it, so it misses the full 'when/when-not' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hpe-networking-lab/hpe-networking-assistant'
If you have feedback or need assistance with the MCP directory API, please join our Discord server