Cisco ISE MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are organized into distinct namespaces (ers, openapi, mnt, dc) and each targets a specific resource or action. However, there are notable ambiguities: within ERS there are both typed tools (ise_ers_list_<resource>) and generic ones (ise_ers_list, ise_ers_get), and MNT session lookup has several overlapping variants (session_by_mac, session_by_ip, session_by_endpoint_ip) that an agent could confuse. The resources namespaces help significantly but the raw passthrough tools (ise_ers_request, ise_openapi_request, ise_mnt_request) create some ambiguity about which to use.
Naming Consistency4/5
Naming follows a clear pattern of ise_<surface>_<action>_<object> (e.g., ise_ers_list_downloadableacl, ise_openapi_*), with consistent snake_case throughout. Minor inconsistencies exist within the DC surface where some tools are generic (ise_dc_view, ise_dc_query) while others are typed per-view (ise_dc_view_radius_authentications), and the MNT group mixes verbs (active_session_list, session_by_mac, session_delete_by_mac) without a fully consistent action-object order.
Tool Count2/5
At 201 tools this is an enormous surface that far exceeds what an agent can reasonably navigate or for which selecion disambiguation works well. While a full ISE platform server legitimately touches many resources, the count is extreme and borderline unmanageable; the calibration guidance treats 50+ as a serious concern. The generic routing/orchestration tools (ise_route, ise_capabilities, ise_ers_resources) mitigate this somewhat, but 201 tools is disproportionate.
Completeness5/5
For the stated purpose of Cisco ISE administration, the surface is remarkably complete: it covers the four major API surfaces (Open API, ERS, Data Connect, Monitor API), full CRUD on the ERS side via typed and generic tools, a broad set of Data Connect reporting views (RADIUS, TACACS, endpoints, posture, admin logins, audits), policy set management for both Network Access and Device Admin, plus operational concerns like backup/restore, certificates, licensing, patches, and deployment management. The raw passthrough tools plus catalog-diff/deployment orchestration tools close any remaining gaps.
Average 3.2/5 across 200 of 201 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.json to 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?
No annotations are provided, so the description carries full behavioral disclosure burden. It doesn't state what happens if the ID doesn't exist (error behavior), whether this is a read-only operation, what data the Portal object contains, or whether deployment selection affects which Portal is retrieved. For a retrieval tool, basic behavioral context about return semantics and error cases is missing. However, 'Get' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence. However, this borders on under-specification rather than efficient brevity—it's short because it says almost nothing beyond the tool name. The schema provides the deployment parameter documentation, so the structure is clean and front-loaded, but the brevity sacrifices necessary guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a single vague purpose statement, this description is incomplete. It doesn't explain the return format, notable fields, error handling, or the relationship between the id and the Portal object. It relies heavily on the agent understanding what 'Portals' means in the ISE context and what getting it by ID entails. The schema covers deployment well but leaves the core id parameter and behavioral expectations undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (the deployment parameter is described in the schema, but the required 'id' parameter has no description in either schema or tool description). The description 'by ID' only confirms the id parameter's role without adding format, type, or source guidance. The deployment parameter is well-documented in the schema, but the id parameter's semantics are assumed."
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Portals object by ID' uses a clear verb+resource pattern and specifies the resource type (Portals). However, it doesn't distinguish itself from sibling tools like ise_ers_get_downloadableacl or ise_ers_get_guesttype beyond the resource name, which the tool name already conveys. It's clear what it does but provides minimal differentiation value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. There are list, search, and get variants for Portal (ise_ers_list_portal, ise_ers_search_portal, ise_ers_get_portal) in the sibling tools, but the description doesn't explain when to prefer 'get' over 'search' or when the id-based lookup is appropriate. The deployment parameter is documented in the schema but not in the description.
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. As a POST (create/mutation) operation, it should inform the agent about side effects, idempotency, validation behavior, or what happens on duplicate names. The description reveals nothing about side effects, error modes, or operational characteristics beyond the HTTP verb in the endpoint path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and compact (single line), with the schema carrying the substance. However, it's under-specified — the '[Repository]' tag and bare endpoint path provide no narrative value, and critical context about what a repository is could fit in the same line budget. This is efficiency without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with zero annotations and no output schema. The 'data' parameter is a nested JSON body whose structure is completely opaque to the agent — the agent would have no idea what fields are required to create a valid repository. For a create operation with a complex object body, the description should reference documentation, provide field hints, or at minimum warn about the nested structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both 'data' and 'deployment' parameters are described in the schema. The 'data' field is described as 'JSON request body' which tells the agent the structure is opaque (likely a complex nested repository object), and the deployment parameter has a rich description with format examples and a pointer to ise_list_deployments. However, the description itself adds nothing about parameters beyond what the schema conveys, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[Repository] Create a new repository (POST /api/v1/repository)' states a verb+resource ('Create a new repository'), but it doesn't clarify what a 'repository' is in this ISE context or how it differs from sibling tools like ise_openapi_repo_list, ise_openapi_repo_get, ise_openapi_repo_update, or ise_openapi_repo_delete. The '[Repository]' prefix is a weak categorization rather than meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention whether this is the standard way to create repositories versus some other path, nor does it describe any prerequisites (e.g., needing an existing deployment, available disk space, naming conventions). The deployment parameter mentions calling ise_list_deployments but that's parameter-level guidance, not usage context for the tool itself.
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 says 'Paginated' but provides no detail about what fields are returned, how many results appear per page, whether the response includes total counts, or what happens with large datasets. For a read-only list operation this is somewhat adequate, but the pagination behavior is only vaguely referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero wasted words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and limited annotations, the description is thin. It tells the agent this lists profiles and is paginated, but doesn't explain return format, ordering, filtering capabilities (if any), or distinctions from other list/search variants. Slightly more detail about what an agent should expect would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, meaning the deployment parameter is documented in the schema but page and size are not. The description mentions 'Paginated' which implies the existence of pagination parameters, but doesn't explain defaults, maximums, or the interaction. This is a minor compensation for the two undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Authorization Profiles. Paginated.' states the verb and resource but adds minimal differentiation. There are many sibling list tools (list_profilerprofile, list_guesttype, list_endpointgroup, etc.) that share the identical 'List all X. Paginated.' pattern, so this description does not distinguish it from siblings beyond the resource name in the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives. Siblings include ise_ers_get_authorizationprofile and ise_ers_search_authorizationprofile which target specific profiles or search patterns, but the description doesn't explain the distinction or when listing all is preferred over search/get.
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 full behavioral disclosure burden. It discloses nothing beyond a search/filter operation. It doesn't state pagination behavior, what the response contains, whether typically 'search' returns multiple matches while 'get' returns one, or any ERS API idiosyncrasies. With zero annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no waste. It's appropriately brief given the tool's simple nature, though it could have used the space budget to add more useful context like filter expression syntax or ERS specifics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 params, no output schema, no annotations, and 80% of parameters undocumented. For a search tool in a large family of similarly-named siblings, the description should clarify the filter expression syntax, pagination, and behavioral distinction from search_ancpolicy and list_ancendpoint. It's under-specified for the complexity of the ERS API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (5 params, only 'deployment' documented). The description mentions 'ERS filter expressions' but doesn't explain the format of the 'filter' parameter potential syntax. The deployment parameter has a helpful description in the schema itself. The description adds minimal value beyond the schema and doesn't compensate for the low coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter ANC Endpoints with ERS filter expressions' states a clear verb+resource, but it's somewhat terse. It distinguishes from list/get siblings by emphasizing search/filter, but doesn't explain what ANC Endpoints are or what the search returns. The purpose is clear enough but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There are close siblings like ise_ers_list_ancendpoint, ise_ers_get_ancendpoint, and ise_ers_search_ancpolicy. The description doesn't distinguish when to use search vs list, nor mention the search_ancpolicy sibling. No exclusions or alternative recommendations.
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 does not state whether this is a read-only operation, what pagination/sorting behavior to expect, whether filter syntax follows ERS conventions, or what the response format looks like. For a search/filter tool, the lack of behavioral context (especially around filter expression syntax) is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it is under-specified for a tool with 5 parameters and 80% undocumented schema coverage. Conciseness is good, but it sacrifices necessary detail about filter expression syntax and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only 20% schema description coverage, this tool is under-documented. A search/filter tool with pagination params and a filter expression language needs more explanation about the filter syntax, pagination behavior, and how it relates to sibling endpoint tools. Currently the description provides just a single sentence that leaves most behavioral and parameter details undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate for the undocumented parameters. The description mentions 'ERS filter expressions' which hints at the 'filter' parameter, but it does not explain page, size, or sort semantics beyond their defaults. The 'deployment' parameter has good in-schema documentation, but the description adds nothing about how filter expressions are structured or what ERS filter syntax expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter Endpoints with ERS filter expressions' which names a specific verb (search/filter) and resource (Endpoints). It does not, however, differentiate itself from sibling tools like ise_ers_list_endpoint, ise_ers_get_endpoint, or the many other search_* tools, nor does it clarify how it differs from the generic ise_ers_search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of how it relates to ise_ers_list_endpoint, ise_ers_search_endpointgroup, or the generic ise_ers_search. The 'deployment' parameter description does direct users to ise_list_deployments, which is helpful but peripheral to core usage guidance about when to filter versus list versus get.
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 provided, the description carries full behavioral burden. It discloses nothing about pagination behavior, sorting semantics, read-only safety, whether filter is required, what fields are searchable, or the meaning of the 'size' default of 100. For a search/filter tool with no annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste. However, it is so terse it barely adds value - this is under-specification rather than meaningful conciseness. The deployment parameter description in the schema is notably more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter search tool with no output schema and only 20% schema description coverage, the description is incomplete. It doesn't explain filter syntax, pagination limits, or how search differs from list. The agent would need to look at the generic ise_ers_search tool or documentation to understand this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'deployment' has a description). The description adds no parameter-level detail beyond that. The 'filter' parameter - central to the tool's purpose - has no explanation of ERS filter expression syntax. Parametric guidance is almost entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter Internal Users with ERS filter expressions' which identifies the verb (search/filter) and resource (Internal Users). However, it duplicates the tool name (ise_ers_search_internaluser) nearly verbatim and does not distinguish from the sibling ise_ers_list_internaluser or the generic ise_ers_search tool, making its specific value unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use search vs list, no mention of ERS filter expression syntax, and no exclusions or alternative tool recommendations. It says filter expressions are used but doesn't explain how they work, leaving the agent to guess the filter format and when this tool is the right choice.
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 does not indicate whether this is a read-only operation, what ERS filter expression syntax is expected, what happens on no matches, or whether results are paginated/limited. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste. It front-loads the core purpose. Well structured for what it contains.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search/filter tool with 5 parameters (0 required), no output schema, and only 20% schema coverage. It needs to explain ERS filter syntax, relation to the list variant, and pagination behavior. The one-sentence description is insufficient for an agent to correctly construct a filter expression or choose this over ise_ers_list_portal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only the deployment parameter has a description). The description mentions 'ERS filter expressions' in prose, which hints at the filter parameter's purpose, but it does not explain the page, size, or sort parameter semantics beyond what the bare schema types imply. With 80% of parameters undocumented in the schema, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter Portals with ERS filter expressions' which has a clear verb and resource. However, since the sibling tools include both ise_ers_search_portal and ise_ers_list_portal, the description does not distinguish what makes 'search' different from generic listing (e.g., whether it supports filter-based search vs pagination). It's clear but not differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this search tool versus ise_ers_list_portal or the generic ise_ers_search. The only usage context comes from the deployment parameter description which mentions calling ise_list_deployments, but there's no explicit when/when-not guidance for the search vs list decision.
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 doesn't state whether this is a read-only operation, what filter syntax is expected, whether pagination is applied, or what the response contains. For a search tool that presumably queries ERS, the behavioral context is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and waste-free (no filler), but it's arguably under-specified rather than appropriately concise. It gets credit for being short and front-loaded with the purpose, but doesn't earn bonus for structure since there's very little content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 80% undocumented in schema, no annotations, and no output schema, the description should compensate significantly. It does not. It doesn't explain filter syntax, pagination defaults, or how this differs from the list and generic search variants that exist as siblings. The description is insufficient for an agent to safely and correctly use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, meaning 4 of 5 parameters lack descriptions. The description only mentions 'ERS filter expressions' without explaining the filter syntax, and does nothing to clarify page, size, sort, or filter semantics. Only the deployment parameter is documented in the schema. The description adds minimal value over the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Profiler Profiles with ERS filter expressions' uses a clear verb (search/filter) and resource (Profiler Profiles), but doesn't distinguish from the many sibling search_* tools (e.g., ise_ers_search_downloadableacl, ise_ers_search_guesttype) beyond the resource name itself. The meaning is clear but there's no differentiation beyond the resource type, which is expected given the naming pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus ise_ers_list_profilerprofile, ise_ers_get_profilerprofile, or the generic ise_ers_search. It doesn't clarify whether this replaces listing or complements the generic search tool. No exclusions, prerequisites, or when-not-to-use guidance is provided.
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 mentions 'erase search/filter' mechanics implicitly via 'ERS filter expressions' but doesn't describe pagination behavior, what fields are filterable, whether results are partial or complete, rate-limit implications, or what the response structure looks like. For a search tool with zero annotation coverage, this is a substantial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action. It's concise and free of waste, though it does nothing beyond the minimal statement. The brevity is appropriate given the simplicity, but the one-sentence ceiling also limits how much value it can add relative to the schema gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and only 20% parameter coverage, so the description must explain more. It fails to describe what a TACACS+ command set is, what the search returns, how filtering works, or how results are structured. For a search tool with 5 parameters, no output schema, and no annotations, 'Search/filter TACACS+ Command Sets with ERS filter expressions' is under-specified for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — only the 'deployment' parameter has a description. The description text itself mentions ERS filter expressions, which relates to the 'filter' parameter, but gives no syntax or format guidance beyond the generic phrase. The 'page', 'size', and 'sort' parameters have no descriptions in the schema and the tool description doesn't compensate for them. The description adds minimal value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter TACACS+ Command Sets with ERS filter expressions' which names the resource (TACACS+ Command Sets) and the action (Search/filter with ERS expressions). It's clear but generic among siblings — the 'search_' prefix tools (search_downloadableacl, search_allowedprotocols, search_guesttype, etc.) all follow the same pattern, so it doesn't distinguish what is unique about TACACS command sets specifically. It uses a compound verb and identifies the resource, but lacks specificity distinguishing it from its many search_ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Siblings include ise_ers_list_tacacscommandsets, ise_ers_get_tacacscommandsets, and ise_openapi_tacacs_command_sets_list, which are functionally alternatives, but the description gives no direction on choosing among them. The ERS filter-expression mention implies filtering capability but doesn't explain when a filter is appropriate or how it differs from plain listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails entirely here: it doesn't mention return format, pagination behavior beyond the schema's page/size defaults, result ordering, whether conditions are filtered by policy type, or whether the 'library' restrictions are system-defined vs user-defined. For a list endpoint with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus an endpoint reference. It's front-loaded with the main purpose. No wasted words, though it could add more behavioral detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description is thin. It doesn't describe what condition objects look like, how many can be returned, response structure, error conditions, or how 'library' conditions differ from policy-specific ones. A more complete description would explain the returned condition schema and any constraints on the list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only the deployment parameter has a description). The page and size parameters are bare integers with defaults but their semantics (pagination) are self-evident from names. The deployment parameter has a thorough description explaining accepted formats, which adds value. Overall the description adds marginal value beyond the schema for only one of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns all library conditions for Network Access policy (GET /api/v1/policy/network-access/condition). The verb 'returns' plus resource 'all library conditions' is reasonably clear, but the term 'library conditions' is domain-specific and not explained. It distinguishes from siblings like radius_condition_get (single fetch) and tacacs_condition_list (TACACS variant) via the Network Access qualification, but only weakly since it doesn't name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like ise_openapi_radius_condition_get or ise_openapi_tacacs_condition_list. The deployment parameter description references ise_list_deployments, which provides some context, but the tool itself gives no when-to-use or 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.
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 does not state whether this is a read-only operation, how results are returned, whether pagination applies, what happens with large result sets, or what ERS filter expression syntax looks like. For a search tool with zero annotation coverage, this is a significant gap - the agent can't know the operation is non-destructive or what the response format is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence - concise and to the point. However, it under-specifies rather than being efficiently concise; it's brief but omits critical context that would help an agent (filter syntax, pagination behavior, read-only guarantee). At 21 words it earns points for brevity but loses points for not front-loading the most decision-relevant information about how ERS filter expressions work.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 20% schema coverage, no annotations, and no output schema, the description's single sentence is insufficient. A search tool with filter expressions needs to explain the filter syntax, pagination default behavior (size=100), and what distinguishes it from the list and get siblings for Guest Users. The complexity is moderate but the documentation density is very low, making this tool hard to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, meaning 4 of 5 parameters have no schema-level description. The description notes the mechanism is 'ERS filter expressions' which maps loosely to the 'filter' parameter. The deployment parameter does have a rich schema description explaining name/slug/number formats and referencing ise_list_deployments. The page, size, and sort parameters have no description and no schema-level explanation, leaving the agent to infer pagination semantics. Baseline 3 is slightly too generous given the high parameter count with low coverage, but the deployment param is well documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches/filters Guest Users with ERS filter expressions, which identifies the verb (search/filter), resource (Guest Users), and mechanism (ERS filter expressions). However, it doesn't differentiate from siblings like ise_ers_list_guestuser (list vs search distinction is implied by convention but not stated), and the generic pattern of search tools across many resource types (search_downloadableacl, search_internaluser, etc.) means this could describe many siblings equally well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use search vs list vs get for Guest Users. The description doesn't explain the difference between the filter-expression-based search here versus the plain list operation, what kind of filter expressions are supported, or when a user would prefer this over ise_ers_list_guestuser or ise_ers_get_guestuser. The deployment parameter does reference calling ise_list_deployments for choices, which is a small positive signal for deployment selection context.
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 labels the tool [DESTRUCTIVE], yet describes a GET status operation—this is a confusing behavioral claim. It doesn't explain what 'disconnect' means operationally (does it trigger a CoA disconnect? just report status?), nor the raw XML return implications. The destructive claim conflicts with the apparent read-only nature of a 'Get status' GET call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tight and front-loaded with the [DESTRUCTIVE] [CoA] tags. However, the '[DESTRUCTIVE]' tag is potentially misleading for a GET, and the 'Returns raw XML' note is useful. No wasted words, but the content could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description (raw XML note + tags) is thin. It doesn't clarify the destructive semantics, what the status response contains, or how it differs from ise_mnt_coa_reauth. The params are documented but the tool's actual behavior—why a GET would be destructive—remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description (though 'Path parameter X' adds minimal value). The description itself adds no parameter meaning beyond the schema. The confirm/deployment params have useful schema annotations, but the description contributes nothing. Baseline 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it 'Get[s] CoA disconnect status' with the HTTP path. However, it's labeled [DESTRUCTIVE], which is odd for a status/read operation—the verb is clear (get status) but the destructive tagging creates confusion about its true nature. It doesn't distinguish from siblings like ise_mnt_coa_reauth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The [CoA] tag hints at the domain but there's no exclusions or comparison to ise_mnt_coa_reauth or the session query tools. A 'when to use' statement is absent.
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 full responsibility for behavioral disclosure. It reveals this is a read-only GET on a system license endpoint but doesn't state whether authentication/privileges are required, what the response structure contains, pagination behavior implications, or how it interacts with the 'deployment' context. The read-only nature is implied by the endpoint method but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single curated line with the endpoint path. It's compact and front-loaded with the [Licensing] category tag and method. However, it's minimal—it essentially just names the endpoint and resource. It's concise but under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read-only system license query with no output schema and no annotations, so the description should compensate. It doesn't state what fields/values the eval-license data contains, how pagination works, or what deployment context means. Sibling tools like ise_openapi_license_smart_state_get and ise_openapi_license_tier_state_get suggest a broader license suite where this 'eval-license' role could be clarified but isn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%. The 'deployment' parameter has a helpful description in the schema directing users to ise_list_deployments. However, 'page' and 'size' have defaults (1 and 100) but no description explaining pagination semantics or limits. The description itself adds nothing about parameters beyond what the schema provides. For a no-required-params read tool this is acceptable but not strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as a GET for license/registration information via the system eval-license endpoint. The verb 'get' plus the resource 'eval-license registration information' is reasonably specific, though it's mostly restating the endpoint path. It doesn't clearly distinguish from sibling license tools like ise_openapi_license_smart_state_get or ise_openapi_license_tier_state_get except by the 'eval-license' resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. There is no statement about when eval-license info is relevant versus smart-state or tier-state license tools. The deployment param helpfully suggests calling ise_list_deployments for options, but there's no broader when/when-not guidance.
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's a GET (read) operation implied by the method in parentheses, but the description doesn't confirm it's read-only, what the response contains, or whether it requires licensing privileges. It adds essentially nothing beyond what the name and endpoint convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short line with the licensing category, resource, and endpoint. It's compact and front-loaded, but borderline under-specified - it resembles an auto-generated endpoint label rather than a thoughtfully written tool description. No waste, but also minimal substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a GET that returns smart license state, the description should explain what fields/structure the response includes, what 'smart state' signifies, and implications for licensing. None of this is present. For a licensing tool, more context about what the smart state represents would help correct tool selection and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the deployment param is described). The page and size params have no description in the schema and no mention in the tool description. The deployment param description is helpful (explains name/slug/number formats and suggests ise_list_deployments). The description itself adds no parameter information beyond the endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'License - smart license information (GET /api/v1/license/system/smart-state)'. This identifies the resource (license smart state) and the HTTP method, but the verb is generic ('information') rather than specific. It's clear this retrieves smart license state, but doesn't differentiate from sibling license tools like ise_openapi_license_tier_state_get or ise_openapi_license_smart_state_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the API endpoint but no guidance on when to use this versus license siblings (tier_state_get, smart_state_set, eval_get, register). It doesn't state what 'smart state' means or what scenario calls for retrieving it. No alternatives or exclusions are mentioned.
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 for behavioral disclosure. The tool name contains 'set' suggesting a mutating operation, but the description only says 'smart state information' which reads like a read operation. This is internally contradictory and doesn't disclose any side effects, what the POST modifies, whether registration is required first, or what happens on invocation. For a state-changing endpoint this is a significant disclosure gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short string that is compact and free of filler, which is good. However, it's arguably under-specified rather than genuinely concise — it's a terse fragment ('[Licensing] License - smart state information') that captures less than it could in the same space. It reads more like an auto-generated label than a purposeful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation-like tool (POST endpoint named 'set') with no annotations, no output schema, and a required nested 'data' object whose structure is entirely undefined. The description provides no context about the request body format, response handling, licensing prerequisites, or error conditions. For a state-changing licensing operation this is incomplete and would leave an agent guessing about how to construct the payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (data and deployment) are documented in the schema itself. The data parameter is described as 'JSON request body' which is minimal but the description doesn't clarify the expected structure of the smart state payload — an important gap given data is required and has nested objects. The description adds no parameter-level value beyond the schema. Baseline 3 is appropriate since the schema covers the field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[Licensing] License - smart state information (POST /api/v1/license/system/smart-state)' indicates it handles license smart state, with the POST verb and resource path adding some specificity. However, 'smart state information' combined with 'set' in the name suggests a state change, yet the description is ambiguous about whether this sets, gets, or updates smart state — the name says 'set' while the description says 'information'. This ambiguity doesn't clearly distinguish it from the sibling ise_openapi_license_smart_state_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 ise_openapi_license_smart_state_get or ise_openapi_license_tier_state_get. The description gives no context about when setting smart state is appropriate, what prerequisites exist (e.g., licensing registration), or scenarios where this would be needed versus avoided.
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. The description only states it lists installed patches with the endpoint path - it does not disclose pagination behavior, whether this is a read-only safe operation, response shape, or any side effects. The page/size parameters hint at pagination but the description says nothing about it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), which is concise, but it packs limited useful information. The '[Patch]' prefix and endpoint path are informational but not particularly valuable for an agent deciding what this tool does. It's minimal rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description is under-specified. It doesn't explain what the response looks like, how pagination works, whether the list is empty-safe, or any filtering capabilities beyond what page/size imply. The deployment targeting is explained but the overall behavior (what patches look like, how to interpret results) is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% with 3 parameters, and the description adds value only for the 'deployment' parameter by explaining it accepts name, slug, or number and pointing to ise_list_deployments. The page and size parameters have defaults but no semantic explanation in either schema or description. The description adds some value for deployment but leaves page/size semantics implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says '[Patch] List installed patches (GET /api/v1/patch)' which indicates this is a list operation for installed patches, distinguishing it from sibling tools like ise_openapi_patch_install and ise_openapi_patch_rollback. However, it lacks detail about what exactly is returned or any meaningful scope clarification beyond the endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't explain the relationship to patch_install/patch_rollback siblings or the hotpatch_list tool, nor does it mention any prerequisites. The deployment parameter description does point to ise_list_deployments for choices, which is a small nod to usage, but there's no when/when-not guidance.
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. The description reveals this is a GET/list operation, which implies read safety, but it doesn't disclose pagination behavior, default limits, ordering, what gets returned, or any rate/permission constraints. For a list tool with zero annotation coverage, the behavioral transparency is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, which is good, but it appears to be auto-generated API documentation fragment rather than a curated description. The '[Policy: Network Access]' prefix is noisy metadata that adds little for an agent. It's minimal but the brevity is a result of under-specification rather than deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain the return value shape, but it doesn't. There's no mention of what dictionary data is returned, the structure, or pagination behavior. For a list tool with 3 parameters and no output schema, this description is incomplete - an agent can't predict what it will receive or how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33%, meaning only the deployment parameter has documentation. The description itself adds nothing about the page or size parameters beyond what the schema provides (defaults are in the schema but no semantic meaning). The description's mention of the GET endpoint and list behavior slightly enriches understanding, but it doesn't compensate for the undocumented page/size parameters beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Returns a list of Dictionaries' with the specific endpoint, which clearly identifies the verb+resource. However, it appears to be an auto-generated API doc fragment (note the [Policy: Network Access] prefix and HTTP path) rather than a purposefully written description. It does not distinguish itself from the sibling ise_openapi_radius_dictionary_get or other list-style tools, and 'Dictionaries' is somewhat ambiguous without context about what these dictionaries represent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The deployment parameter references ise_list_deployments for choices, which provides some context, but there's no statement about when a user would need this tool, what data it's useful for, or any exclusions/alternatives. The page/size semantics are implied but not explained in the description itself.
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. The description reveals nothing beyond the basic get operation — no mention of error behavior when ID is not found, no mention of permissions required, no mention of what fields are returned, and no clarification on whether 404 or empty results are expected for invalid IDs. For a GET-style operation, this minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers the core purpose efficiently. There's no fluff or repetition. The deployment parameter schema text is detailed but belongs to the schema, not the description. The one-line description is appropriately minimal for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a get tool with no output schema and no annotations, the description should explain what the return value looks like or at least confirm the response structure. It provides none of that. Given there are related tools (ise_ers_list_downloadableacl, ise_ers_search_downloadableacl) that supply IDs, the description could clarify the sourcing of the ID parameter, but doesn't. The tool is minimally functional but leaves important usage questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (the deployment parameter has a full description, but the id parameter has none beyond being a string). The description adds meaning for 'deployment' via the schema's detailed text (name/slug/number formats), and the 'by ID' phrase clarifies the primary parameter's purpose. However, the id parameter format (e.g., whether it's a UUID or object name) is never explained, which for a CRUD get-by-ID is important context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single Downloadable ACLs (dACLs) object by ID' which clearly identifies the verb (get), resource (dACLs), and access method (by ID). However, it doesn't distinguish from sibling tools like ise_ers_search_downloadableacl or ise_ers_list_downloadableacl beyond the obvious 'by ID' qualifier, which is somewhat implied by the function name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. While the 'by ID' qualifier implies it's for fetching a specific object, there's no explicit statement like 'use list for multiple objects' or 'use search when you don't know the ID'. The deployment parameter references ise_list_deployments, which offers some context, but no when/when-not guidance is given.
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 does not state whether this is a safe read operation, any error behavior when the ID doesn't match, whether special permissions are required, or any rate limiting. For a 'get' tool with zero annotation coverage, the transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It gets to the point immediately. It's appropriately sized for a simple retrieval tool, though it could use slightly more critical detail within that same economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 50% schema description coverage, the description is thin. It doesn't describe the return format, what fields exist on a Guest Types object, error handling for invalid IDs, or any restrictions. Given the complexity is low (single object fetch), a score of 2 reflects that the minimal viable information about behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'deployment' parameter has a well-written description in the schema covering targeting and explicit reference to ise_list_deployments. The 'id' parameter has no schema description, and the tool description adds nothing about what format the ID takes. One of two params is well documented in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Guest Types object by ID' states a specific verb (get), resource (Guest Types), and lookup mechanism (ID). It's clear about what it does, but does not distinguish itself from sibling tools like ise_ers_list_guesttype or ise_ers_search_guesttype, which operate on the same resource. The generic pattern is shared across dozens of sibling get_ tools without differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 vs ise_ers_list_guesttype or ise_ers_search_guesttype. The description gives no context about when to fetch by ID as opposed to listing all or searching. No exclusions, alternatives, or prerequisites are mentioned beyond the implicit distinction in the name.
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 doesn't state whether this is a safe read operation, what happens for a non-existent ID (error vs empty), whether it requires specific permissions, or what the response shape is. For a 'get' tool this is a modest but real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, zero filler. The structure is efficient. However, it's under-specified rather than concisely comprehensive, which prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with no output schema and no annotations, the description is minimal. It's adequate to convey the basic operation but fails to add value regarding error behavior, return content, or inter-tool relationships. The 'deployment' parameter indicates multi-deployment complexity that the description entirely ignores.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (id undocumented, deployment documented). The description provides no additional parameter semantics beyond the schema. The required 'id' parameter has no description in the schema, and the description doesn't compensate by explaining what a valid ID looks like or how to obtain one. The deployment parameter IS well documented in the schema, so partial credit applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single TACACS+ Command Sets object by ID' states a clear verb (get) and resource (TACACS+ Command Sets object), which distinguishes it from the list/search siblings. However, it doesn't add detail like what fields are returned or how it differs from the search variant (ise_ers_search_tacacscommandsets). It's adequate but skeletal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. There's no mention that ise_ers_search_tacacscommandsets or ise_ers_list_tacacscommandsets would be preferred for lookup-by-name or enumeration scenarios. The description gives no exclusions, prerequisites, or context for selection among the get/search/list siblings.
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 provided, the description carries the full burden of behavioral disclosure. The only behavioral trait disclosed is pagination ('Paginated'), which is useful but minimal. It does not mention whether responses are truncated, whether it returns all fields or summaries, rate limiting, or any read-only safety confirmation. For a list operation this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with zero filler. It states the purpose and the key behavioral trait (paginated). While underspecified, it earns points for efficiency and clarity in what it does say.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations and no output schema, the description should provide more guidance on pagination behavior, return format, or filtering options. The 33% schema coverage leaves page/size semantics unclear. The description does not explain how to interpret the paginated results or whether there are size limits, making it incomplete for an agent expected to consume its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 parameters described: 'deployment'). The page and size parameters have defaults but no descriptions; the description mentions 'Paginated' which hints at page/size usage, adding marginal value. However, the description fails to compensate for the two undocumented parameters, and the deployment parameter details are only in the schema, not reinforced in the description. Baseline 3 with schema doing partial work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Network Device Groups'), which distinguishes it from get/search variants in the sibling tools. However, the purpose is somewhat minimal and could benefit from context on what these groups are or how they relate to network devices. The differentiation from get/search siblings is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 ise_ers_get_networkdevicegroup or ise_ers_search_networkdevicegroup. The pagination mention hints at bulk retrieval, but there is no explicit statement about when to choose this over the alternatives or any exclusions/limitations of the list 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 of behavioral disclosure. It does not state what ERS filter expression syntax is expected, what the return format is, whether pagination applies (page/size defaults suggest yes), or whether this is a read-only operation. For a search tool with zero annotation coverage, this is a notable gap in transparency about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It's efficient and free of waste. It could arguably be slightly more helpful, but for what it covers, it's appropriately tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with 5 parameters, only one of which is described in the schema, and no output schema. No annotations exist. The description does not explain the ERS filter expression syntax, pagination behavior, or the distinction from list/get variants. For a complex search tool, the description is under-specified and leaves the agent to guess about filter syntax and result semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 20%, meaning most parameters (page, size, sort, filter) are undocumented in the schema. The description mentions 'ERS filter expressions' which hints at the filter parameter's purpose, and the deployment parameter has a solid schema description. However, the description doesn't explain the filter expression syntax meaningfully, so it adds only marginal value beyond the schema for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter Authorization Profiles with ERS filter expressions,' which identifies the verb (search/filter), resource (Authorization Profiles), and mechanism (ERS filter expressions). It's clear enough but doesn't differentiate from sibling search tools (ise_ers_search_downloadableacl, etc.) beyond the resource name, and the generic listing/generic search siblings share the ERS framework.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that listing all profiles might use ise_ers_list_authorizationprofile, that getting one by ID uses ise_ers_get_authorizationprofile, or that the generic ise_ers_search covers this resource. The deployment parameter description references ise_list_deployments for choosing a deployment, which is a small usage hint, but overall no when/when-not guidance.
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 full behavioral disclosure burden. It notes it returns 'raw XML' (useful), but does not disclose whether this is a read-only operation, the size/format of the response, pagination, rate limits, or authentication needs. For an MNT endpoint, clearer safety and format expectations would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: one names the endpoint, one notes the XML return format. The [System] prefix and endpoint path are efficiently packed. No wasted words, though slightly more content (usage/response details) would justify a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description only states 'raw XML' without describing the XML structure, fields, or how to interpret failure reasons. For a diagnostic tool with zero annotations and no output schema, the description should carry more context about what the caller receives and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the deployment parameter is fully documented in the schema. The description adds no implementation detail about the parameter beyond what the schema provides, so the baseline 3 applies. The description correctly omits param info since the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get Failure Reasons' with an explicit endpoint (GET /admin/API/mnt/FailureReasons) and notes it returns raw XML. The verb+resource is clear, but it does not specify what failure reasons refer to (RADIUS failures? MNT failures?), and among the many ise_mnt_* siblings this does not clearly differentiate what makes this distinct from other MNT tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not explain when this MNT failure-reasons endpoint would be appropriate vs. other session/auth list tools, nor does it mention prerequisites or when to omit vs. specify the deployment parameter. Only the deployment schema description hints at usage.
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 full burden for behavioral disclosure. It doesn't mention whether the install is asynchronous (returns a task id), requires upload/download of patch first, needs a maintenance window or reboot, affects active sessions, or is destructive. '[Patch]' prefix is decorative and adds no behavioral information. For an install (mutation) operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus endpoint reference. It's efficient with no wasted words. The deployment parameter's rich documentation is embedded in the schema, not the description. Could be slightly improved by front-loading more semantic context, but overall it's appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: it's a mutation operation (install) with a nested 'data' object as required parameter, no output schema, and no annotations. With high schema coverage for params but zero behavioral disclosure, the description leaves the agent uninformed about whether the operation is synchronous or async, what the response contains, and what the 'data' body should actually contain (patch name? version? wait-for?) - critical for a patch install. The deployment parameter hint is the only genuinely useful supplementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (data as JSON body, deployment as target selection). The description adds the useful hint about deployment format options (name/slug/number) and references ise_list_deployments, which is genuinely helpful beyond the schema. However, the 'data' parameter's structure/nested fields aren't explained, and schema coverage being complete means baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Trigger patch installation on the Cisco ISE node' with the endpoint path. This makes the verb+resource clear. However, it's minimal - no detail on what 'install' entails, prerequisites, or what distinguishes it from hotpatch_install or patch_list siblings. The purpose is clear but not richly specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. It doesn't reference alternatives like ise_openapi_hotpatch_install or distinguish when a regular patch vs hotpatch should be used. The only implicit usage context comes from the tool name itself, which isn't sufficient to differentiate choices.
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's a list/read operation but the description doesn't state this explicitly, doesn't note pagination, response format, ordering, or whether the {id} refers to a policy-set that must exist first. For an unannotated tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At roughly two clauses, the description is appropriately brief and the core action ('Get authentication rules') is front-loaded. The endpoint path provides useful technical reference without bloat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a list operation for a policy-scoped resource with no output schema and no annotations. Given the complexity (nested under policy-set id, RADIUS vs TACACS variants, many sibling list tools), the description should provide more: what the response contains, how it relates to the policy-set, and how it differs from sibling list tools. The description is minimal for the context it operates within.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds little beyond the schema: the explanatory context around the deployment parameter (naming options and fallback to default) is embedded in the schema itself. Baseline 3 is appropriate since schema does the heavy lifting and description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get authentication rules' with the endpoint path, providing a specific verb+resource. However, it's mostly just restating the function name/generic context ('authentication list' → 'get authentication rules'), and doesn't articulate scope (all rules in a policy set? filtered?) beyond the path parameter. The 'Network Access' policy classification helps establish domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs. the many sibling radius/tacacs list tools. It doesn't distinguish from ise_openapi_radius_authentication_create, the tacacs_authentication_list sibling, or the generic ise_openapi_request. The description provides no when-to-use or when-not-to-use direction.
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 does not state that this is a mutating/create operation's implications (e.g., requiring admin privileges, being irreversible, affecting network access enforcement). The description confirms 'Create' but adds no detail about consequences, required auth, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact line with the method, resource, and endpoint path. The deployment parameter description is informative and front-loads the key routing decision. No wasted words, though the endpoint string is somewhat redundant with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create/mutation operation with nested object data ('data' is an object with unspecified structure), no annotations, no output schema, and a complex policy-set authorization context. The description provides almost no guidance on the structure of the 'data' body, required fields, or what constitutes a valid authorization rule. For a tool whose primary payload is an opaque JSON object, this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having at least a basic description ('Path parameter id.', 'JSON request body', target deployment guidance). The description adds no param details beyond the schema, but the deployment parameter does get useful context ('Omit to use the only/default deployment', pointer to ise_list_deployments). With 100% coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP method (POST) and resource path clearly: 'Create authorization rule' with the API endpoint. It identifies the tool as a create operation on authorization rules within a policy set. However, it doesn't add much beyond the tool name and path; the parenthetical endpoint reference is the main differentiator from the many 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools like ise_openapi_radius_authorization_list clearly relate but no distinction is made. The description provides no context for when an authorization rule should be created vs. other operations, and no prerequisites (e.g., needing an existing policy set ID) are stated.
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 full burden for behavioral disclosure. It fails to disclose that this is a read operation, whether it returns all authorization rules, pagination behavior, or required context (the policy set must already exist). It only echoes the endpoint URL rather than describing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, with the endpoint embedded for reference. It doesn't repeat schema information. However, it could be restructured to front-load the verb (GET) and resource more clearly rather than the '[Policy: Network Access]' prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool requiring a policy set id and with no output schema, the description doesn't explain what the response contains, whether additional fields like rule count are returned, or how many results to expect. The dependence on first retrieving a policy set id is not mentioned. Given the parameter complexity is low but the API context is specific, this feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the deployment parameter has detailed documentation including examples (name, slug, or number formats). However, the description itself adds no parameter context. Since schema coverage is high, baseline 3 is appropriate, though the description doesn't enrich the id parameter's meaning (it's only called the 'path parameter').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the API endpoint and '[Policy: Network Access] Network Access - Get authorization rules' clearly identifying it retrieves authorization rules for a policy set. However, it doesn't clearly state this is specifically RADIUS authorization (vs TACACS which has a sibling tool ise_openapi_tacacs_authorization_list) beyond the tool name, and it doesn't indicate whether it lists all rules or rules for a specific set, though the {id} path parameter implies a specific policy set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention that it requires a policy set id (which must first be obtained from a policy-set listing tool), nor does it distinguish this from the sibling ise_openapi_radius_authorization_create or ise_openapi_tacacs_authorization_list. No exclusions or alternatives are given.
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 full behavioral disclosure burden. It doesn't disclose pagination behavior (beyond what schema shows), sorting, filtering capability, response format, or whether it returns policy set details or summary metadata. For a list operation with zero annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that conveys the resource being operated on and the endpoint. It's efficient with no filler, though the [Policy: Network Access] prefix is more of a category tag than actionable prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There's no output schema and no annotations, so the description carries the full burden. For a paginated list operation, it should describe what the response contains (policy set names, IDs, settings), page/size semantics, and how it relates to related get/create/update/delete operations. The current description is minimal and leaves the agent guessing about return structure and iteration semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% - the deployment parameter has a detailed description, but page and size parameters have only defaults with no explanatory text. The description doesn't add any parameter meaning beyond what the schema provides, leaving page/size undocumented. Baseline of 3 is appropriate given partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists 'policy sets' for 'Network Access' and provides the endpoint path, clearly identifying it as a list operation. However, it doesn't distinguish itself from the similar ise_openapi_tacacs_policy_set_list sibling, though the 'Network Access' qualifier and RADIUS context in the name provide partial differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention that this is RADIUS-specific versus TACACS policy sets, nor does it clarify relationship with ise_openapi_radius_policy_set_get (for retrieving single policy sets). The endpoint path is shown but no usage context is provided.
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 full burden. It discloses it contains accounting record details and which columns are filterable, but doesn't mention what columns are returned by default (only which are filterable), whether results are paginated, what the time window behavior is, or whether it's a read-only snapshot. The days_back parameter suggests time-based filtering but the description doesn't clarify the view's default time scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences. The first establishes purpose, the second enumerates the filterable columns. No wasted words. It's front-loaded with the primary action. Slightly useful addition would be elaboration on the days_back default, but it's appropriately sized for a report view.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report view with 100% schema coverage, no nested objects, and standard query parameters, the description provides the necessary column list and record type. The list of filterable columns is the main value-add. However, it could be more complete by clarifying the differences among the multiple tacacs_* views (authentication, authorization, accounting, command_accounting) given the breadth of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column) are all documented in the schema. The description adds the list of filterable columns (REMOTE_ADDRESS, ID, USERNAME, IDENTITY_GROUP, GENERATED_TIME, LOGGED_TIME, ISE_NODE, AUTHENTICATION_SERVICE), which is genuinely useful beyond the schema since it tells the agent which columns are valid for filter_column. However, it doesn't add depth beyond that list, hitting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a view of TACACS accounting records and lists the filterable columns. However, it's titled as a '[Report]' which is generic, and while it distinguishes it among the dc_view siblings by specifying TACACS accounting, it doesn't articulate what makes it different from the related tacacs_authentication and tacacs_authorization views (beyond 'accounting').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like ise_dc_view_tacacs_authentication or ise_dc_view_tacacs_command_accounting. It doesn't mention when a report view is preferred over ise_dc_query or ise_dc_view. No exclusions or alternatives are given, so an agent must infer appropriateness from the name alone.
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 does not state whether the operation is read-only, whether it requires specific permissions, what happens if the resource/id is unsupported, pagination/format behavior, or error handling. For an object retrieval tool, the safety profile (read-only) is a notable gap given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It is appropriately concise for a simple retrieval tool. However, given that it's a generic tool covering many resources, slightly more guidance about the resource parameter could merit inclusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage and no output schema, the description is adequate but thin. The tool is generic across dozens of resource types with no behavioral details about what a GET returns, response format, or limitations per resource. Given the complexity of a tool handling 80+ resource types, more contextual explanation would be warranted, though the generic purpose is reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (id, resource, deployment) with meaningful descriptions. The resource enum references ise_ers_resources for supported operations, and deployment references ise_list_deployments. The description adds no parameter-level information beyond the schema, which is acceptable given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a single ERS object by its ID' clearly states a specific verb (retrieve) and resource (ERS object by ID). However, it is generic and does not distinguish itself from the many sibling get_* tools (ise_ers_get_downloadableacl, ise_ers_get_sgt, etc.) or clarify that it is the generic resource-type-based variant versus the specific per-resource getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 generic tool versus the numerous specific per-resource get tools (ise_ers_get_endpoint, ise_ers_get_sgt, etc.) present in siblings. It also doesn't mention how to discover which resources support get operations beyond the schema enum pointing to ise_ers_resources. No exclusions or alternative tool references are given.
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 behavioral burden. It discloses pagination ('Paginated.') and that it lists all, but does not describe the response format, what happens with large result sets beyond pagination defaults, ordering behavior, or whether read-only operations require special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste. Front-loaded with the purpose statement. Efficient given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only 33% parameter coverage, the description is thin. For a list tool with pagination defaults it works minimally, but an agent cannot know the return structure, how to page effectively, or whether there is a max size limit. The deployment param guidance is the strongest part, but it's buried in schema rather than description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (deployment has a description; page and size do not). The description adds no parameter semantics beyond noting pagination exists. The page and size params have defaults but no semantic explanation of how they interact or what the max size is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Guest Users. Paginated.' clearly states the verb (list), resource (Guest Users), and scope (all), distinguishing it from sibling get/search variants like ise_ers_get_guestuser and ise_ers_search_guestuser. The purpose is clear 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Lists all' with no exclusion criteria, but provides no guidance on when to use this versus get/search variants, no mention of prerequisites, and no indication that it returns everything (which could be large). There is no alternative tool named or when-not guidance.
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 provided, the description carries full responsibility for behavioral disclosure. It reveals nothing beyond the basic search/filter action—no mention of pagination behavior, filtering syntax format, limits, or what happens with empty results. This is a search operation with several undocumented behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. While extremely brief, it's appropriately front-loaded and there's no redundancy. Its brevity is a positive, though the content it omits is a negative (scored elsewhere).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, this description is clearly under-specified. There is no explanation of filter expression syntax, no pagination/sorting behavior, no contrast with generic or related sibling tools, and no indication of what results look like. A search/filter tool on a complex resource like Active Directory needs far more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only the 'deployment' param has a description). The description adds nothing about the 'filter', 'sort', 'page', or 'size' parameters or their formats. The 'filter' parameter in particular is completely unexplained—no ERS filter syntax or examples are given, despite being the core mechanism of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Active Directory with ERS filter expressions' has a clear verb+resource structure, specifying it searches/filters a specific Enterprise Service Router (ERS) resource (Active Directory). It's reasonably distinguishable from sibling _list and _get activedirectory tools, though it could more explicitly contrast with those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives like ise_ers_list_activedirectory or ise_ers_get_activedirectory. The description only states what it does (search/filter), not when it's preferred over sibling tools, nor what kind of filter expressions are valid or how they differ from generic ise_ers_search.
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 doesn't state whether this is a read-only operation, what filtering syntax is expected, pagination behavior, or what the response shape looks like. For a search tool with zero annotation coverage and no output schema, the behavioral transparency is thin — the agent is left guessing about filter format and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the core purpose. However, it is arguably too brief given the tool's complexity — conciseness is achieved but at the expense of meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 20% schema coverage, the description is under-specified for a search tool with 5 parameters. It doesn't explain ERS filter syntax, pagination semantics, sort behavior, or what distinguishes search from list in this family. The deployment parameter is well-handled via pointing to ise_list_deployments, but the overall description leaves too many gaps for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 20% of schema parameters have descriptions (only 'deployment' is described), leaving filter, sort, page, and size undocumented. The description mentions 'ERS filter expressions' which hints at the filter parameter's purpose, but doesn't explain the ERS filter syntax or how sort/page/size behave. With low schema coverage, the description should compensate but provides almost no parameter-level detail beyond the deployment hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches/filters Downloadable ACLs with ERS filter expressions, which clearly identifies the verb (search/filter) and resource (Downloadable ACLs). However, it doesn't distinguish itself from the sibling 'ise_ers_list_downloadableacl' — both appear to enumerate dACLs, and the description doesn't clarify how search differs from list in this family beyond mentioning filter expressions (which the 'list' variant may also support).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'filter' parameter is alluded to ('with ERS filter expressions') and the deployment parameter mentions calling ise_list_deployments to see options. However, there's no explicit guidance on when to use search vs. list_downloadableacl vs. get_downloadableacl, nor when filtering is preferable to listing. The deployment reference provides some context but no exclusionary guidance against siblings.
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 full burden. It reveals it is a read/search operation but does not disclose pagination behavior, result limits, whether empty results return empty arrays, or how filter expressions behave syntactically. For a search tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with zero waste, but it under-specifies. While concise, it omits critical usage context. It's not bloated, but it doesn't invest its brevity effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters (including a filter expression format that needs explanation), no output schema, no annotations, and minimal parameter documentation, the description is inadequate. It should explain the ERS filter expression syntax, pagination behavior, and how search differs from list. No examples or return-value description is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only the deployment parameter has a description). The tool description mentions 'ERS filter expressions' but doesn't explain the filter parameter format or the meaning of page/size/sort. The deployment parameter is well-described in the schema, but the search-specific parameters (filter, page, size, sort) lack semantic guidance beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches/filters Guest Types using ERS filter expressions. It distinguishes from list_guesttype (list all) and get_guesttype (get by id) at a basic level, but 'search/filter' is not deeply elaborated. The purpose is reasonably clear but lacks detail on what fields can be filtered or the nature of the result set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the filter expression usage but gives no explicit guidance on when to use search vs list vs get, no examples of filter syntax, and no explanation of the page/size/sort semantics. Siblings include list_guesttype and get_guesttype, but the description never clarifies when search is the right choice.
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. The description only states filter functionality but doesn't disclose pagination behavior, return format, what happens with no filter (full listing), rate limits, or whether the filter syntax 'contains' vs 'equals' semantics. For a search tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It front-loads the core purpose. However, given the low schema coverage, it could afford to be slightly longer to add parameter guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and low parameter coverage, the description is under-specified. The 'filter' parameter's ERS expression syntax is a critical piece of guidance that is absent. The description doesn't explain how filtering works, what a typical filter expression looks like, or how results are paginated. More context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with only the 'deployment' parameter (and sort, filter, page, size) having descriptions in the schema. The description itself adds no parameter information beyond the name. The 'filter' parameter is not explained in terms of ERS filter expression syntax, and 'sort' format is not documented. With low schema coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Search/filter Security Group Tags (SGTs) with ERS filter expressions'), which is clear. However, it fails to distinguish from the many sibling variants like ise_ers_list_sgt, ise_ers_get_sgt, and similar 'search' tools for other resources (search_downloadableacl, search_guesttype, etc.), though the SGT specificity does differentiate from those other resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtering/searching SGTs without listing everything. It doesn't explicitly state when to use this versus ise_ers_list_sgt (unfiltered listing) or ise_ers_get_sgt (individual fetch), nor does it mention ise_ers_search as a general alternative. Some context is implied by the word 'filter' but no explicit alternatives or exclusions are named.
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 provided, the description carries the full burden of behavioral disclosure, but it provides almost none. It doesn't state whether this is read-only, whether authentication/permissions are required, what happens on invalid/missing id (404?), or what the response shape looks like. 'Returns a library condition' gives no behavioral detail beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus the endpoint reference. It's compact and front-loaded with the domain label. However, the brevity works against it since the space isn't used to add helpful behavioral content. Still, conciseness itself is appropriate—no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GET-by-id tool with no output schema and minimal annotations, the description should explain what a library condition is, what the returned object contains, and how it differs from other condition tools. None of this is provided. This is a moderate-complexity tool (ISE policy conditions) whose documentation is too thin to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the descriptions are nearly empty: 'Path parameter id' adds no semantic meaning about what the id represents or its format. The deployment parameter is well documented (name/slug/number syntax with an explicit example), but the primary 'id' parameter that selects the condition receives zero semantic context beyond being a path parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'Returns a library condition' for Network Access via a specific API endpoint. It identifies the resource (library condition) and the operation (get/return) clearly. However, it doesn't differ from sibling ise_openapi_radius_condition_create/list, and it doesn't clarify what a 'library condition' is or how it distinguishes from tacacs_condition. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for fetching a single condition by its id. It provides no explicit when-to-use guidance, no exclusions, no mention that the id must already exist or how it relates to the condition_list tool. It does not contrast with ise_openapi_radius_condition_list or the create variant, so usage context is only implied.
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 provided, the description carries the full burden of behavioral disclosure. It doesn't state whether this is read-only, whether it requires specific permissions, what pagination behavior occurs, how results are ordered, or what the response structure looks like. It's a 'Get' so read-only is implied by convention, but nothing is disclosed about behavior beyond the bare HTTP call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the scope, but it includes the raw HTTP endpoint which is redundant against the tool name. The single sentence is efficient but also lacks substance—it's minimal rather than meaningfully concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 parameters, no output schema, no annotations, and only 33% schema documentation coverage, the description is under-specified. It doesn't describe what the returned global exception rules look like, pagination behavior, or what fields distinguish results. It also fails to disambiguate from the very similar-sounding ise_openapi_radius_exception_list sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, meaning the page, size, and deployment parameters are largely undocumented in the schema. The deployment parameter does have a useful description in the schema (name/slug/number and reference to ise_list_deployments). However, the tool DESCRIPTION itself adds nothing about parameters; page and size semantics are left to the agent's inference. The deployment param's good schema documentation partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[Policy: Network Access] Network Access - Get global execption rules' with a specific HTTP endpoint, so it identifies the verb and resource. However, it's a thin restatement that doesn't clarify what 'global exception rules' are, and there's a misspelling ('execption'). It doesn't distinguish itself from the closely-named sibling ise_openapi_radius_exception_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. The sibling ise_openapi_radius_exception_list appears semantically very similar ('exception list'), but the description doesn't explain when to use one over the other. There's no mention of whether this is a complete list or paginated, no relationship to other policy tools, and no exclusions.
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 provided, the description carries the full behavioral burden. It identifies this as a read-only report ('[Report]'), which is good, but it doesn't disclose pagination behavior, what the output format looks like (no output schema), whether records have a time window or are historical, or how the 'all' records are defined given there's a days_back filter parameter. The description is essentially a label plus a column list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the purpose with '[Report] TACACS Authentication'. The column list is useful but presented as a single run-on sentence. It's reasonably concise with no wasted words, though it lacks structural organization (e.g., paragraph breaks for purpose vs. capabilities).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report-style tool with 7 parameters, no annotations, and no output schema, the description should provide more context. It doesn't explain the report's scope, time frame, what 'all records' means, the meaning/purpose of each filterable column, or what the response looks like. The existence of sibling TACACS views (authorization, accounting, command accounting) with no differentiation leaves the agent guessing which report fits the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all 7 parameters having descriptions in the input schema (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column). The description adds the list of filterable columns (REMOTE_ADDRESS, SELECTED_AUTHORIZATION_PROFILE, etc.), which is useful for choosing filter_column values. However, the description does not add insight beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '[Report] TACACS Authentication' and that it provides details of all TACACS authentication records, listing filterable columns. It uses a specific verb+resource construction and differentiates somewhat from siblings (the tacacs_authorization, tacacs_accounting variants). However, it doesn't explicitly distinguish from the sibling ise_openapi_tacacs_authentication_list or clarify the 'dc_view' vs 'openapi' distinction, which weakens sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or mention of alternatives. The filters are listed but there is no statement about when this report view is appropriate versus other TACACS reporting tools like ise_dc_view_tacacs_authorization/accounting. The 'deployment' parameter references calling ise_list_deployments, but no broader usage context is given.
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 full burden for behavioral disclosure. It's a read-only report view, but the description doesn't state this explicitly, nor does it describe pagination behavior, performance implications of large day ranges, or output format. The description only lists columns, which is useful but not sufficient behavioral transparency for a data-viewing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with column enumeration. It's front-loaded with '[Report]' which is helpful. However, the column list is somewhat redundant with what output would naturally reveal, and while concise, it could add more valuable guidance in the space. It's not wastefully verbose but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-view/report tool with no output schema and no annotations, the description should do more. It lists columns but omits the report's purpose context (e.g., security auditing use case), doesn't clarify whether results span multiple deployments or require specific permissions, and doesn't indicate whether this is a high-volume report needing careful date filtering. The tool is simple (no output schema, moderate params) but the missing behavioral and usage context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds the column list which helps users know what filter_column values make sense. Beyond that, it doesn't add much parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a report tool that displays TACACS command accounting details and lists the filterable columns. It starts with '[Report]' prefix which signals its nature. It's distinguishable from siblings like ise_dc_view_tacacs_authentication and ise_dc_view_tacacs_authorization via the name and the TACACS command accounting mention, though it doesn't explicitly differentiate from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool vs alternatives. It doesn't mention when to use this over ise_dc_view_tacacs_authentication or ise_dc_view_tacacs_authorization, nor does it describe any prerequisites or context such as needing a specific deployment. The parameter descriptions do give some usage hints but the description itself provides no when/when-not guidance.
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 for behavioral disclosure. It indicates a read operation ('Get'), and being a profiler profile retrieval it's implicitly non-destructive, but it doesn't state what the response contains, whether a non-existent ID returns an error or empty result, or any deployment-selection behavior. It's minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero wasted words. It's appropriately minimal for a simple get-by-ID operation. No excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool this is borderline adequate, but there is no output schema and no information about the shape of the returned profiler profile object or error behavior. The description is functional but gives the agent no sense of what result to expect beyond 'a single object'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (1 of 2 params documented in schema). The description adds no parameter semantics beyond 'by ID' in the purpose. The 'id' param is self-explanatory and 'deployment' is documented in the schema. Since the schema documents the deployment param and id is obvious, the description's lack of parameter detail is acceptable but doesn't add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Profiler Profiles object by ID' has a clear verb ('Get') and resource ('Profiler Profiles object by ID'). However, it doesn't distinguish this from the many sibling get tools (ise_ers_get_internaluser, ise_ers_get_endpoint, etc.) beyond the resource name itself, which is the standard naming pattern in this family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. It doesn't mention that 'get' takes an ID while 'search' takes query parameters or that 'list' retrieves all — though this pattern is evident from sibling names, the description doesn't articulate it. Among get_x tools there is no differentiation guidance, and no mention that this is for retrieving by ID specifically versus by-name or via search.
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 (no readOnlyHint, destructiveHint), so the description carries the full behavioral burden. It discloses pagination behavior but says nothing about whether this is a read-only operation, requires authentication, what the response format is, or the max page size limits. For a listing tool, the lack of any note about read-only status or rate implications is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short sentences with zero wasted words. It front-loads the core purpose ('List all ANC Endpoints') and flags the pagination behavior. Extremely efficient, though slightly under-specified for the completeness it needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with no output schema and low parameter coverage, the description is sparse. It would benefit from noting that ANC Endpoints are Adaptive Network Control endpoints, the relationship to ise_ers_get_ancendpoint/ise_ers_search_ancendpoint, and default page size behavior. The 'List all' claim combined with pagination suggests enumeration semantics that aren't fully explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 1 of 3 parameters (deployment) has a schema description, giving 33% coverage. The description itself adds no parameter detail. The deployment parameter has rich semantic meaning in its schema description (name/slug/number formats and fallback behavior), but the page and size parameters are bare integers with defaults, and the description doesn't add meaning beyond pagination context. Schema does most of the work here, but coverage is low so the baseline is a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose clearly: 'List all ANC Endpoints' with pagination. However, it doesn't distinguish itself from sibling tools like ise_ers_list_ancpolicy, ise_ers_get_ancendpoint, or ise_ers_search_ancendpoint, making it harder for an agent to know why to choose this specific list operation over related alternatives. The verb+resource is clear but the differentiation gap holds it to a 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Paginated' implies this is the listing operation and that page/size control the result set, which gives some usage context. However, there's no explicit statement of when to use this vs ise_ers_search_ancendpoint (which likely does filtered search) or ise_ers_get_ancendpoint (single item). The 'Paginated' mention hints at full enumeration use but offers no exclusions or alternatives.
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 mentions 'ERS filter expressions' but never explains what ERS is, what the filter expression syntax looks like, whether results are paginated, whether it's read-only, or what happens with invalid filters. For a search operation with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief at one sentence. It's front-loaded with the primary purpose. No wasted words, but could arguably include slightly more useful behavioral or filter-syntax context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, no output schema, and no annotations, the description is thin. It doesn't explain filter expression syntax, pagination behavior, sort format, or what the returned data looks like. With schema coverage at 20%, the description should compensate more for the undocumented filter, page, size, and sort parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only the deployment parameter has a description). The description mentions 'filter expressions' but doesn't elaborate on the filter parameter's syntax or accepted format, leaving the most important parameter (filter) unexplained since the schema also lacks description for it. The deployment parameter is well-documented in the schema, offsetting some of the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it searches/filters Network Device Groups with ERS filter expressions. The verb+resource is clear, but it doesn't differentiate from the many sibling search tools (ise_ers_search_networkdevice, ise_ers_search_endpointgroup, etc.) beyond the resource type which is already in the name. The 'ERS filter expressions' detail adds some technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtering/searching but provides no explicit guidance on when to use this vs alternatives like ise_ers_list_networkdevicegroup (list) or ise_ers_get_networkdevicegroup (get by ID). No exclusions or prerequisites are stated. The deployment parameter hint (call ise_list_deployments) is the only usage guidance present.
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 full burden. It's a mutating PUT operation, but the description doesn't disclose prerequisites (e.g., whether an existing schedule must already exist), side effects, or failure modes. It doesn't mention what happens if no schedule exists, or whether this overwrites all schedule settings. For a write operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the category tag and endpoint path. Every element earns its place. It's compact and gets to the point quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations, no output schema, and a nested 'data' object of unknown shape. The description provides no information about what fields the data object expects, what the response contains, or what the schedule-update relationship to schedule-create is. For a write operation with an opaque nested body, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters (data and deployment). The description adds no parameter-level detail beyond the schema, but the deployment description in-schema is already helpful (name/slug/number formats and reference to ise_list_deployments). With full coverage, baseline 3 is appropriate; the description itself adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it updates a scheduled configuration backup via PUT /api/v1/backup-restore/config/schedule-config-backup. The verb+resource is clear, but it doesn't explain what 'update' means in terms of which settings can be modified (frequency, time, repositories, etc.), leaving the agent guessing at the semantics of the operation beyond the endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [Backup & Restore] category distinguishes this from other ise_openapi_backup_* tools at a high level. The deployment parameter reference to ise_list_deployments provides some context. However, there's no guidance on when to use this vs ise_openapi_backup_schedule_create, nor whether this requires an existing schedule to update vs creating a new one.
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 of behavioral disclosure. The description does identify the API endpoint (POST /api/v1/policy/network-access/condition), which confirms this is a mutation operation, and the '[Policy: Network Access]' namespace scoping is useful. However, it doesn't disclose what happens on success (return values), idempotency, required fields within 'data', or whether existing conditions with the same name are rejected or overwritten. The HTTP POST verb is transparent about the write nature, giving some behavioral context, but the description remains thin on outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence providing the essential purpose and endpoint. It is front-loaded with the functional verb and resource. The '[Policy: Network Access]' prefix adds useful domain scoping. No wasted words. However, it could be slightly more informative about what a library condition is without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create (mutating) operation with no annotations, no output schema, and a nested 'data' object whose internal structure is undisclosed. The description does not explain what a RADIUS library condition is, what properties the 'data' JSON body must contain, or what the successful response looks like. Given the complexity (mutating operation, opaque nested data payload, multiple sibling create tools), the description is substantially under-specified. The deployment parameter is well-documented in the schema, which helps, but the central 'data' payload and behavioral outcomes are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters (data as 'JSON request body' and deployment with detailed value formats). The description adds the endpoint context which implies 'data' carries the condition definition, but it doesn't clarify the structure or required fields inside 'data'. Given 100% schema coverage, a baseline of 3 is appropriate; the description doesn't add meaningful parameter semantics beyond what the schema provides, and the 'data' object's internal structure (a nested object, per context signals) remains opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[Policy: Network Access] Network Access - Creates a library condition. (POST /api/v1/policy/network-access/condition)' which gives a specific verb+resource for creating a condition. However, it doesn't differentiate from sibling condition tools like ise_openapi_radius_condition_list, ise_openapi_radius_condition_get, ise_openapi_tacacs_condition_list, and importantly from other 'create' variants (authorization_create, authentication_create, policy_set_create). The purpose is identifiable but the scope of what a 'library condition' is (vs other condition types) is not clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple create tools (ise_openapi_radius_condition_create vs ise_openapi_radius_authentication_create, ise_openapi_radius_authorization_create, ise_openapi_tacacs_* siblings) and no distinction is drawn between 'library condition' creation and other condition-related operations. No exclusions, prerequisites, or alternative tool references are given. For a create operation in a complex domain, this is a significant gap.
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 full burden. However, it reveals nothing about behavioral traits: no mention of whether this is a full PUT replacement semantics (though the PUT HTTP method hints at it), no mention of required permissions or auth, no mention of validation behavior or error conditions, and no return format. As a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse line that's front-loaded with purpose but the overall tool documentation is thin. It includes the HTTP endpoint which is useful but is essentially just restating the title. It's concise but under-specifies key aspects of behavior, so it's not 'zero waste' in a helpful sense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested object parameter, no output schema, no annotations, and a fairly complex domain (TACACS policy sets), the description is inadequate. It doesn't explain the structure of the data body, doesn't disclose replacement semantics, and doesn't mention deployment context beyond what the schema already states. There's also no reference to sibling get/list tools for retrieving current state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 3 parameters are documented in the schema. The description adds the deployment param helpful note ('Omit to use the only/default deployment') which exists in the schema too. The 'data' param is described only as 'JSON request body' with no shape/structure detail, but since coverage is 100% baseline is 3 and the description doesn't add much beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a policy set') with the specific resource (Device Admin policy set) and even includes the REST endpoint (PUT /api/v1/policy/device-admin/policy-set/{id}). It distinguishes this from sibling tools like tacacs_policy_set_create/delete and get. It's specific but not as richly descriptive as the TDQS high examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't explain that you should first call tacacs_policy_set_get or list to obtain the id, nor does it clarify what happens to existing settings not supplied in the data body (whether it's a full replacement or partial update). No context on preconditions or exclusions.
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 full burden for behavioral disclosure. The description frames this as a read-only 'Report' view, which is useful, but it does not disclose response format, pagination behavior beyond the limit parameter, the meaning of the 'time column' used by days_back, or any caveats about data retention/availability. For a report tool with zero annotation coverage, more disclosure is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient paragraph that packs the report identity, purpose, and filterable columns into a concise block. The filterable column list is dense but genuinely useful. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the view's purpose, its view-details capability, and its filterable columns, which is strong for identifying the data content. However, given 7 parameters, no output schema, and no annotations, a bit more is needed: clarifying the output shape, the time-column basis for days_back, and how this report relates to the generic ise_dc_query would make it complete. It's adequate but not full.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters have descriptions in the schema itself. The description adds the filterable columns list (SYSTEM_DOMAIN, SYSTEM_USER, IP_ADDRESS, etc.) which gives concrete meaning to the filter_column parameter and clarifies the view's contents. With high schema coverage and a useful column listing, score 3 is the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The '[Report]' prefix and 'Posture Assessment By Endpoint' clearly identify this as a report view showing which endpoints have been subject to posture assessment. The description clearly states the tool's purpose of viewing posture assessment details per endpoint, which distinguishes it from the many other ise_dc_view_report tools by naming the specific view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the view shows endpoints subjected to posture assessment and gives the administrator ability to view details, establishing an implied use context. However, there is no explicit guidance on when to use this tool versus the alternative report views like ise_dc_view_endpoints_data or when to prefer generic ise_dc_query/view tools. With 7 parameters and many sibling report views, explicit differentiation would 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 doesn't state whether this is a read-only reporting operation, whether results are paginated beyond the limit parameter, what the default row count behavior is, or what the output format looks like (since there is no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact paragraph that efficiently communicates the report's purpose and lists the filterable columns. It's reasonably front-loaded with the tool's nature ('[Report] Profiled Endpoints Summary'). No wasted words in describing the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a report view, and the filter params are self-describing, which covers much of the operational need. However, with no output schema, no annotations, and no guidance on which columns map to which filter_column values, there's a gap. The column list is useful but doesn't clarify how filter_column relates to those headers or what the report output shape is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 7 parameters, each with clear descriptions (e.g., limit max, days_back semantics, filter_op enum values, deployment targeting). However, the description adds no additional meaning beyond what the schema already documents; for instance, filter_column doesn't specify which columns are valid filterable values (only listed in the description, not schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Profiled Endpoints Summary' report that displays profiling details about endpoints accessing the network. It lists the filterable columns. However, it doesn't distinguish from sibling ise_dc_view_* report tools or clarify what makes this specific report unique versus other views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't say when one would need profiled endpoint data versus registered endpoints (ise_dc_view_registered_endpoints) or other data collection views. The report nature is implied but no exclusions or alternative tool references are given.
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. The description frames this as a 'Report' and says it 'Displays' data, implying it's read-only/safe, but it doesn't explicitly confirm non-mutating behavior. It also doesn't disclose whether results are paginated, how large the dataset could be, or performance characteristics. For a zero-annotation tool, more explicit behavioral disclosure would be warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence enumerating columns, which is compact. However, the column list is somewhat dense and could be considered over-detailed for the description while other important info (usage, return format) is missing. It's reasonably concise but not perfectly front-loaded with the most important purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage on 7 parameters and no output schema, the description conveys the tool's purpose and data contents reasonably well. However, for a tool that involves an ISE deployment (the deployment parameter) and complex reporting data, it would benefit from disclosing the return structure or clarifying how the view relates to registered endpoint records compared to other endpoint views. It's minimal-viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters with their descriptions. The description adds the list of filterable columns, which helps map filter_column values, but the description doesn't add meaning beyond what the input schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a report tool ('[Report]') that 'Displays all personal devices registered by the employees' and lists the filterable columns. It has a specific verb+resource and describes what data is shown. However, it doesn't explicitly distinguish itself from sibling report tools like ise_dc_view_endpoints_data or ise_dc_view_profiled_endpoints_summary, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention when to use it over ise_dc_view_endpoints_data or other data-center view tools. There's no indication of exclusions or when not to use it. The only usage hint is indirect via the '[Report]' prefix and column list.
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. The description is a single sentence stating the operation but provides no details about what the return value looks like, error behavior for unknown IDs, rate limiting, or what fields are included in an 'Allowed Protocols object'. For a GET operation with zero annotation coverage, there's no disclosure of safety traits, and no description of the object shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at a single declarative sentence. It's front-loaded with the core action and resource. However, given that there's no behavioral or usage context, the brevity borders on under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context — no annotations, no output schema, 50% parameter coverage, and a somewhat complex ISE deployment environment with a deployment parameter — the description is too sparse. It doesn't explain the return structure, ID format, error handling for nonexistent IDs, or when this tool is preferred over the many related ERS tools in the sibling list. A single sentence is inadequate for a resource-fetch tool in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID' which maps to the required 'id' parameter. The 'deployment' parameter is well-documented in the schema itself with examples and instructions to call ise_list_deployments. However, with 50% schema description coverage, one parameter (id) is essentially undocumented beyond its name and type, and the description doesn't clarify the format of the ID (UUID vs name vs slug).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single Allowed Protocols object by ID' with a specific verb (get), specific resource (Allowed Protocols), and the retrieval-by-ID mechanism. It clearly distinguishes from sibling tools like ise_ers_list_allowedprotocols (list all) and ise_ers_search_allowedprotocols (search), though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when to use list_allowedprotocols or search_allowedprotocols instead, nor any context about deployment targeting prerequisites beyond what the schema describes. The 'by ID' qualifier implicitly suggests this is for direct ID lookup, but this is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It merely states 'Get' with no detail on what the response contains, whether this is a read-only safe operation, authentication requirements, or pagination/large-response behavior. For a tool with zero annotation coverage, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and purpose. Every word earns its place; there is zero waste. This is appropriately concise for a simple GET-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool without output schema or annotations, the description is very thin. It doesn't mention what object shape is returned, error behavior for missing IDs, or the relationship to the endpoint resource list. Given sibling tools like ise_ers_search_endpoint and ise_ers_list_endpoint exist, more context distinguishing these would help. The deployment param is documented but the core resource semantics are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% - the deployment parameter has a rich description, but the required id parameter has none (just type string). The description says 'by ID' but adds no meaning beyond the schema for the id parameter. With moderate coverage and the description providing minimal param guidance, a 3 is the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Endpoints object by ID' is clear about verb+resource (get, single endpoint by ID). However, it doesn't distinguish this from the many sibling ise_ers_get_* tools beyond the obvious resource name, nor does it differentiate from generic ise_ers_get or search variants. It's minimally clear but not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you have a specific endpoint ID), and the deployment parameter within the schema hints at context. However, there's no explicit guidance on when to use this vs ise_ers_search_endpoint or ise_ers_list_endpoint, nor any exclusions or alternatives mentioned. Usage context is implied but not stated.
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 full behavioral disclosure burden. The description does not state whether the tool returns 404 on missing ID, any auth requirements, or the response format. For a read/get operation the risk is lower, but the description adds nothing about behavior beyond the one-line action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the tool's purpose with zero waste. It prioritizes the core action effectively. Given the schema's deployment parameter has a complete inline description, the brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with 2 params and no output schema, the description is adequate but minimal. The absence of an output schema means the description could note what fields are returned or how to interpret the response. No error/not-found behavior is described. It's functional but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (id is undocumented, deployment has a rich description). The description only mentions lookup by ID, adding no meaning to the 'id' parameter beyond its name. The deployment parameter is well-documented in the schema itself, and the description doesn't compensate for the undocumented id field or explain ID format/source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Internal Users object by ID' clearly states the verb (get), resource (Internal Users object), and scope (by ID). It distinguishes from list and search siblings, though there are many similar 'get by ID' tools with identical pattern, so differentiation comes mainly from the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving one object by ID, contrasting with list and search siblings (ise_ers_list_internaluser, ise_ers_search_internaluser). However, no explicit guidance is given on when to prefer this over the by-name or generic get tools, and no exclusions or alternatives are named.
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 doesn't state that this is a safe read operation, whether it returns a 404 on missing ID, what fields are returned, or any authentication/permission requirements. For a retrieval tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently states the core purpose. The deployment guide context is handled in the schema rather than repeated. No wasted words, appropriate length for a simple get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple single-resource getter with no output schema and moderate sibling differentiation. The description is adequate for the primary action but lacks details on error behavior, ID format, and return structure. It's complete enough for basic use but thin for a tool without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description adds value only via the deployment parameter reference (which is documented in the schema itself). The 'id' parameter is documented by name only; the description doesn't clarify its format (e.g., whether it is a UUID, name, or resource ID). Baseline 3 is appropriate given partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single Network Devices (NADs) object by ID' with a clear verb (get) and resource (Network Devices / NADs). It distinguishes from siblings like ise_ers_list_networkdevice (list) and ise_ers_search_networkdevice (search-by-attribute) via the 'by ID' qualifier, though it doesn't explicitly contrast these.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is given. The description implies use when fetching a single NAD by ID, but doesn't clarify when to prefer this over search/list variants. The deployment param references ise_list_deployments, but no alternative tool is named for the get-by-id use case.
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 provided, the description carries full burden for behavioral disclosure. It states the tool retrieves an object but doesn't disclose behavior such as what happens if the ID is not found (error vs empty), whether network calls require specific permissions, rate limits, or whether it can return multiple objects. The description is minimal and reveals nothing about side effects (likely none) or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, appropriately short. While it could be more informative, it is efficiently written with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get-by-ID tool with only 2 parameters and no output schema, so complexity is low. However, the description is extremely minimal and doesn't provide matching info (does ID refer to ERS id?), nor does it hint at related get/search operations. There's no indication of acceptable ID formats or whether this retrieves from a specific deployment in a multi-deployment environment beyond the deployment attribute's own schema. For a tool in a complex multi-deployment ISE context, more contextual completeness would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, meaning one parameter (deployment) has schema description while id does not. The description mentions 'by ID' which aligns with the id parameter, providing minimal added meaning. The deployment parameter already has a thorough schema description covering name/slug/number formats and the default behavior, so the description adds little beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Network Device Groups object by ID' has a specific verb+resource (get + Network Device Groups object), clearly stating it retrieves a single object by ID. The verb pattern 'get' distinguishes it from sibling 'list'/'search' variants, though it doesn't explicitly note the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not explain when to choose this over the sibling list/search/set_default_deployment tools, nor does it name alternatives. It relies on the generic 'get' naming convention which is shared across dozens of sibling tools without explicit differentiation.
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 were provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get') but doesn't mention error behavior for non-existent IDs, response format, pagination, or whether the ID must come from a listing first. For a get-by-ID tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without verbosity. It is appropriately short for a straightforward get-by-ID tool, though it could add a note about ID source without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, a required 'id' parameter that lacks schema documentation, and no annotations, the description leaves the agent to guess at the return format and ID semantics. For a simple tool this might be adequate, but the undocumented id parameter combined with no behavioral details makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — the 'id' parameter is undocumented in the schema, while 'deployment' has a thorough description. The tool description adds no detail about what the ID represents or how to obtain it. The undocumented id parameter is the critical one, and the description does not compensate for its lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single REST ID Stores object by ID' uses a specific verb (get) with a clear resource (REST ID Stores) and scoping ('by ID'). It distinguishes from sibling search/list tools like ise_ers_search_restidstore and ise_ers_list_restidstore, making the get-by-ID behavior clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention that ise_ers_list_restidstore or ise_ers_search_restidstore might be more appropriate for fetching multiple objects. The deployment parameter has schema-level guidance, but no description-level context on usage tradeoffs.
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 full responsibility for behavioral disclosure. It only states the operation ('get') without revealing what happens on nonexistent IDs (error vs null), whether authentication/authorization is needed, response format, pagination, or any side effects. For a read operation with zero annotation coverage, this is sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with zero filler. It front-loads the verb and resource. The brevity is appropriate for the tool's simplicity, though it could add a note about deployment handling or error behavior without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and an undocumented required 'id' parameter. For an ERS REST API tool fetching a profile object, the description should clarify what the returned object contains, error behavior for invalid IDs, and any relationship to the search_tacacsprofile tool for lookup assistance. Given the low schema coverage and missing output schema, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with 2 parameters (id, deployment). The 'id' parameter is undocumented in the schema and the description only mentions retrieving 'by ID' without format guidance. The 'deployment' parameter has rich schema documentation including examples and a pointer to ise_list_deployments. The description adds marginal value over the schema for id but the deployment param is well covered by schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single TACACS+ Profiles object by ID' with a specific verb (Get) and resource (TACACS+ Profiles object). It clearly differentiates from list and search siblings (ise_ers_list_tacacsprofile, ise_ers_search_tacacsprofile) which return collections. The naming pattern is consistent with sibling get_* tools in the same ise_ers_* family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It doesn't distinguish from ise_ers_search_tacacsprofile or ise_ers_get_by_name, nor does it explain the difference between getting by ID vs searching. The deployment parameter hints at multi-deployment context but no exclusion guidance exists for when to use list/search 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. The description mentions 'Paginated' which discloses that results come in pages, and the schema hints at page/size defaults. However, it doesn't disclose read-only safety, return format, what happens with many results, or whether this hits a live ISE deployment. For a list operation the read-only nature is implied by the verb, but the pagination behavior could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short phrases: 'List all Admin Users. Paginated.' No wasted words, and the pagination note is placed second for minor emphasis. However, it's arguably too sparse—it could be slightly more informative without losing conciseness, such as clarifying scope or output behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description leaves substantial gaps. It doesn't explain the response shape, whether listing all admin users has any scope/visibility constraints (e.g., only the current deployment), or how pagination parameters behave. The deployment parameter is documented in the schema, but page/size semantics are only implied. Sibling tools in the adminuser family (get, search) suggest a list-versus-lookup pattern, but the description doesn't guide this choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the deployment parameter has a description in the schema). The page and size parameters have no description. The description mentions 'Paginated' which implies page/size control, indirectly giving meaning to two of the three undocumented parameters. The deployment parameter's schema description is rich (name, slug, or number, with fallback behavior and pointer to ise_list_deployments). So the description plus schema partially compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List all Admin Users. Paginated." clearly states the verb (List) and resource (Admin Users). However, it doesn't distinguish itself from sibling tools like ise_ers_get_adminuser or ise_ers_search_adminuser, though the 'List' versus 'get'/'search' distinction is somewhat implicit in the name. The 'Paginated' note adds a small behavioral hint but doesn't clarify how pagination works or what makes this different from a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Within the adminuser family, siblings include get_adminuser and search_adminuser, but the description doesn't explain when a list is appropriate versus a search or get. The deployment parameter description in the schema offers some context about omitting it for the default deployment, but this is in the schema, not the description, and 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.
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 mentions pagination but not whether this is a read-only operation, whether results are ordered, what the response format contains, or any side effects. For a list operation with zero annotation coverage, more transparency is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short sentences with zero waste. The 'Paginated.' note is efficient but borderline info-dense. This is acceptable conciseness though it sacrifices explanatory depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with no output schema and no annotations, the description provides the basic purpose and pagination hint but lacks detail on response shape, ordering, filtering capabilities, or how this differs from the generic ise_ers_list alternative. Fewer than 3 parameters means complexity is low, but the missing context around return values and alternatives is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'deployment' has a description), while 'page' and 'size' lack descriptions in the schema. The description's mention of 'Paginated' implies page/size usage but adds no specific detail. The deployment parameter is well-documented inline, leaving the tool under-specified but partially compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Guest Types. Paginated.' uses a specific verb (list) and resource (Guest Types), and the tool name is descriptive. It distinguishes the listing intent from get/search siblings, though it doesn't explicitly note the resource scope beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the alternative access pattern (ise_ers_list, ise_ers_get_guesttype, ise_ers_search_guesttype). With 'list' siblings in the family and generic ise_ers_list as an alternative, the description provides no selection criteria or exclusions.
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 full burden. It states 'Paginated' but gives no return format, no indication of default behavior beyond page/size, no warning about large result sets, no auth or deployment requirements. For a read/list tool with zero annotation coverage, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste. 'List all Network Devices (NADs). Paginated.' is maximally concise for what it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 optional params, no required params, and no output schema, the description is adequate but thin. It doesn't mention return shape, default pagination behavior, or rate considerations. With zero annotations, more behavioral context would help. However, it's a straightforward list operation so the gap is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (1 of 3 params documented). The description mentions 'Paginated' which relates to page/size, but the deployment parameter is well-documented in the schema itself. The page and size parameters lack schema descriptions and the tool description doesn't compensate for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all Network Devices (NADs)' with a clear verb+resource. It distinguishes from sibling 'get_networkdevice' (single) and 'search_networkdevice' (search/filter) via the 'List all' phrasing. However, it doesn't explicitly contrast with the sibling search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings like ise_ers_search_networkdevice presumably handle filtering, but the description doesn't clarify this tool is for unfiltered listing vs. targeted retrieval. It only mentions pagination, not usage context.
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 mentions pagination but provides no detail about what this means concretely — how results are ordered, what the return shape is, whether there are limits, or what happens with large result sets. For a read/list operation with zero annotation coverage, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — a single short sentence stating purpose and pagination. It's front-loaded and has zero superfluous text. It is appropriately sized given that most parameter detail is in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list operation shared across many sibling list_ tools, the description is adequate for basic use. However, there is no output schema, no annotation coverage, and the description doesn't clarify the pagination contract (return format, total counts, page limits). It's minimally viable but relies on the agent understanding the broader ISE ERS list pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'deployment' has a description; 'page' and 'size' rely on their names and defaults). The description mentions pagination but doesn't explain the page/size semantics beyond what the schema already documents via defaults. The deployment parameter is well-documented in the schema itself. The description adds minimal value beyond the schema for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Security Group Tags'), and mentions it is paginated. It distinguishes itself from sibling tools like ise_ers_get_sgt and ise_ers_search_sgt (which are single-item fetch and search operations, respectively), though it doesn't explicitly reference them. The name ise_ers_list_sgt aligns with many other list_ siblings, making its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are dozens of sibling list_ tools and generic ise_ers_list, but no indication of when to prefer this SGT-specific paginated list over the generic bulk list or search tools. No exclusions or alternative recommendations are given.
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 mentions pagination and implies a read operation, but doesn't state what the response shape is, whether it returns all fields per set or summaries, or any rate-limit/performance considerations. For a listing tool, the pagination disclosure is helpful but the description is thin on other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste. The deployment parameter description is front-loaded with concrete examples. The statement 'List all TACACS+ Command Sets. Paginated.' is efficiently dense, though it could have used the saved words to add differentiation from sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with 3 params and no output schema. The description covers the basic operation and pagination. However, given the ecosystem includes get and search variants plus generic ise_ers_list/get wrappers, a brief note on why to use this specialized list over alternatives would improve completeness. The schema is simple enough that this is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, meaning 2 of 3 parameters have descriptions. The deployment parameter has a rich description explaining name/slug/number formats and how to discover choices, which is genuinely valuable. However, page and size parameters have no description beyond their schema types and defaults — the description's 'Paginated' note adds minimal context. With two undocumented parameters but a well-documented third, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (TACACS+ Command Sets), and the pagination behavior. It's a specific and clear purpose. However, it doesn't distinguish itself from the sibling tools ise_ers_get_tacacscommandsets and ise_ers_search_tacacscommandsets, though the naming convention (list vs get vs search) provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the search variant or the get-by-ID variant. The pagination note hints at browsing behavior, but there's no explicit statement about when list is appropriate vs search/get. Sibling tools include ise_ers_search_tacacscommandsets and ise_ers_get_tacacscommandsets, and no differentiation is provided.
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 provided, the description carries full behavioral burden. It notes the tool is 'Paginated' which is useful, but doesn't disclose whether it's a read-only safe operation, whether results are sorted, what the response format is, or whether all profiles are returned or just the first page. It's a list operation so destructive intent is implied absent, but the description doesn't articulate any behavioral nuance beyond pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences). While concise, the 'Paginated' note is thin and the description is arguably under-specified rather than efficiently concise. It front-loads the purpose well but provides no additional structured guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple list tool with 3 parameters, no output schema, and no annotations. Given the low complexity, a minimal description might be acceptable, but the lack of usage guidance relative to the many sibling TACACS/ERS tools, plus the pagination nuance, makes it slightly under-complete. It's adequate for a trivial list operation but leaves the agent to guess about response shape and when to use alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate for the two undocumented params (page, size). The description's 'Paginated' hint partially explains page and size semantics, but it doesn't clarify defaults, maximum size limits, or how results are ordered. The deployment parameter already has a rich description in the schema. The description adds marginal context about pagination but doesn't fully compensate for the 67% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all TACACS+ Profiles, using a specific resource ('List all TACACS+ Profiles'). It distinguishes itself from siblings like ise_ers_get_tacacsprofile (single get) and ise_ers_search_tacacsprofile (search) through the 'List all' phrasing, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like search_tacacsprofile or get_tacacsprofile. It does not mention when a different resource type (e.g., commandsets vs profiles) would be more appropriate, nor does it explain pagination behavior or when the deployment parameter is needed.
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 disclosure. It reveals this is a search operation (implying read-only), but does not state pagination behavior, result count limits, what happens with no match, or filter expression syntax/format. For a tool with zero annotation coverage, important behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It conveys the core purpose directly. However, given the total lack of behavioral and parameter detail, brevity here approaches under-specification rather than genuine conciseness, though the sentence itself is well-formed and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, this search tool description is under-specified. The deployment parameter gets separate documentation indicating multi-deployment awareness, but filter expression syntax, pagination defaults, and sort behavior are all undocumented. A search tool of this complexity should provide filter format details and result-count expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with 5 parameters (page, size, sort, filter, deployment). The description adds no parameter-specific details whatsoever - it does not explain filter expression syntax, sort format, or pagination semantics. Only the 'deployment' parameter has inline schema documentation. The description fails to compensate for the 80% uncovered parameters, though the deployment guidance partially offsets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Admin Users with ERS filter expressions' clearly states the verb (search/filter), resource (Admin Users), and mechanism (ERS filter expressions). It distinguishes from siblings like ise_ers_list_adminuser (which lists without filtering) and ise_ers_get_adminuser (which retrieves a single item). Clear purpose, though terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for searching/filtering, which somewhat distinguishes it from list/get counterparts visible in sibling tools. However, it offers no explicit guidance on when to use ERS filter expressions vs. alternatives, no examples of filter syntax, and no exclusions or alternative tool mentions. The 'ERS filter expressions' hint is useful but not developed.
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 doesn't state whether this is a read-only operation (implied by 'search/filter' but not explicit), how pagination interacts with filtering, whether the search returns all matching groups or requires exact matches, or what happens when the filter is malformed. For a tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that earns its place. It's brief and front-loads the purpose. However, given the tool's parameter complexity and the gap in schema coverage, some additional detail would be warranted, so it's slightly under-specified rather than perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with 5 parameters, 0 required, no output schema, and no annotations, with only 20% schema coverage. The description does not explain the filter expression format, pagination semantics, or return behavior. The deployment parameter is well documented in the schema, but the core 'filter' capability that defines this tool remains vague. For a search tool, the description should explain what filtering can do — this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — only the 'deployment' parameter has a description; 'page', 'size', 'sort', and 'filter' are undocumented in the schema. The description mentions 'ERS filter expressions' which gives some context for the 'filter' parameter, but it doesn't explain the expression syntax, default page/size behavior, or sort format. The description adds some value for 'filter' but doesn't compensate for the 80% coverage gap. The 'deployment' param is well-described in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Endpoint Identity Groups with ERS filter expressions' uses a specific verb (search/filter) with a clear resource (Endpoint Identity Groups) and mechanism (ERS filter expressions). It distinguishes itself from sibling tools by the 'search' prefix versus list/get, though it shares the pattern with other ise_ers_search_* tools so it doesn't fully differentiate against those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. It doesn't explain the distinction from ise_ers_list_endpointgroup (pagination vs filter), from ise_ers_search_endpoint (searching endpoints vs groups), or ise_dc_view_endpoint_identity_groups. The 'search/filter' wording implies usage but provides no exclusions or alternatives, and doesn't explain what ERS filter expressions look like or the tradeoff versus listing.
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 full behavioral disclosure burden. It only states it can search/filter but doesn't disclose pagination behavior (page/size defaults), sorting semantics, whether filter is required, what fields are filterable, or error behavior. The schema has page/size/sort/filter params but the description doesn't contextualize their behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. However, it's somewhat under-specified given the low schema coverage and absence of annotations, so while concise, it doesn't fully leverage the space for needed context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The tool has 5 parameters with 80% undocumented in the schema. The description doesn't explain filter expression syntax, pagination, sorting options, or what the response contains. For a search tool among a crowded family of ise_ers_search_* siblings (networkdevice, endpointgroup, internaluser, etc.), it should clarify the LDAP-specific filter fields but doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'deployment' is documented). The description adds the concept of 'ERS filter expressions' but doesn't explain the filter syntax or format. The page/size/sort/filter parameters are undocumented in the schema and the description doesn't compensate. Baseline 3 per rules since coverage is low but description at least signals the filter mechanism exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states verb (search/filter), resource (LDAP Identity Sources), and mechanism (ERS filter expressions). It distinguishes from generic ise_ers_search by being specific to LDAP. However, it doesn't fully differentiate from sibling ise_ers_list_ldap or ise_ers_get_ldap beyond the 'search/filter' phrasing, and doesn't explain what 'search' returns vs list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search vs list vs get for LDAP sources. The description mentions 'ERS filter expressions' but doesn't explain how to construct them or point to the generic ise_ers_search / ise_ers_resources for filter syntax reference. No exclusions or alternative tool references provided.
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 full behavioral burden. It does not disclose pagination behavior beyond schema defaults, whether results are returned in a particular format, sorting semantics, or any side effects. For a search/read tool this is somewhat less critical, but the description adds no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's concise and front-loaded with the core purpose. However, given the minimal content, more useful detail could have been added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There's no output schema and annotations are absent, so the description should compensate. It fails to explain ERS filter expression syntax, pagination/sort behavior, or how results differ between this and the list variant. For a search/filter tool with undocumented filter semantics, this leaves meaningful gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description bears some responsibility for parameter meaning. The filter and sort parameters are underexplained - the description mentions 'ERS filter expressions' but doesn't detail the syntax or provide examples. The deployment parameter is well-described in the schema itself. It's minimally adequate but doesn't enrich filter/sort semantics meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Network Devices (NADs) with ERS filter expressions' clearly states the verb (search/filter), resource (Network Devices/NADs), and mechanism (ERS filter expressions). It distinguishes from the sibling ise_ers_list_networkdevice (which presumably returns all) and ise_ers_get_networkdevice (single item retrieval), though it doesn't explicitly name those as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for filtering/searching devices but provides no explicit guidance on when to use it versus ise_ers_search_endpoint, ise_ers_search_networkdevicegroup, or generic ise_ers_search. There's no explanation of when to use this over the list variant, no filter syntax examples, and no exclusions stated.
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 doesn't mention that this is a read-only operation, default pagination behavior, how many results it returns, or the ERS API's filtering limitations. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It front-loads the core purpose. However, it could be slightly enhanced without losing brevity—but as written it's appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with only 20% schema coverage, no output schema, and no annotations. The description only explains the tool's general purpose without detailing filter expression syntax, pagination, sorting, or deployment targeting (other than what schema provides). For a search tool with this complexity, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only 'deployment' has a description). The description mentions filter expressions, which relates to the 'filter' parameter, but adds no detail on filter syntax, format, or operators. The page/size/sort params are entirely undocumented in both description and schema, leaving the agent guessing about defaults and semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches/filters SGACLs with ERS filter expressions, matching the name's 'search' verb and sgacl resource. It distinguishes from the list (ise_ers_list_sgacl) and get (ise_ers_get_sgacl) siblings by specifying filter expressions, though it doesn't explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this vs. alternatives. It mentions 'ERS filter expressions' but doesn't clarify when filtering is needed versus plain listing, nor does it reference sibling search tools for other resources. No prerequisites or exclusion conditions are stated.
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 full burden for behavioral disclosure. It reveals this is a read/search operation and uses ERS, but doesn't explain pagination behavior beyond the exposed page/size params, what sort capabilities exist, or what happens when no filter is given (does it behave like list?). No response format is described either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, efficiently worded with no filler. It's appropriately minimal, though it could potentially add a bit more guidance without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters (3 undocumented beyond names), no output schema, and no annotations, the description is thin. It doesn't explain ERS filter expression syntax, sort capabilities, default behavior without a filter, or expected result shape. Significant gaps remain for the agent to successfully invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only 'deployment' has a description). The description mentions 'ERS filter expressions' which adds meaning to the 'filter' parameter, and the deployment param is well documented in the schema itself. However, page, size, and sort have no description and the tool description doesn't elaborate on their semantics or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search/filter TACACS+ Profiles with ERS filter expressions' — clear verb (search/filter) + resource (TACACS+ Profiles) + method (ERS filter expressions). It distinguishes itself from list (ise_ers_list_tacacsprofile) and get (ise_ers_get_tacacsprofile) siblings by the filter/search focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this search tool vs the list or get variants for the same resource. The tool name implies filtering, but the description doesn't clarify scenarios where search is preferred over list, nor does it mention any exclusions or prerequisites.
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 provided, the description carries full responsibility for behavioral disclosure. It mentions 'Returns raw XML' which is useful, but doesn't disclose whether this is a read-only operation, the response format details, rate limits, or auth prerequisites. It adds modest value with the raw-XML note but leaves the safety and behavior profile largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact line that includes the category prefix, the operation, the exact endpoint, and a note on the return type. It wastes no words and front-loads the key purpose. Could arguably be more efficient by dropping the redundant raw endpoint string, but it's reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-returning tool with a good annotation set, this would suffice, but there are no annotations and no output schema. The description tells the agent what it returns (raw XML) but not the pagination, timeout, or error behavior. The startTime/endTime range semantics are implied by the parameter names. Given the complexity is moderate and schema covers parameters, this is adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are documented in the schema. The description adds that the endpoint takes startTime/endTime as path parameters, but this is essentially a repeat of what the schema parameters already state ('Path parameter'). The description provides no additional format, example values, or semantics beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets an Authentication Session List via a specific REST endpoint, and notes it returns raw XML. The verb 'Get' plus resource 'Authentication Session List' clearly indicates the operation. It doesn't explicitly distinguish from siblings, but the '[Sessions]' prefix and 'AuthList' path help orient within the mnt session family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description does not differentiate this from sibling mnt session tools like ise_mnt_active_session_list, ise_mnt_session_by_mac, ise_mnt_session_by_username, etc., nor does it mention why one would choose this over the active session list. The startTime/endTime range parameter implies a time-bounded query, but that's not stated as guidance for selection.
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 disclosure burden. It notes the return is 'raw XML' and the exact REST endpoint, which is useful. However, it doesn't mention whether this is a safe read operation (despite the name suggesting it is), rate limits, or what the count represents semantically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single line citing the endpoint and return format. It is front-loaded and zero-waste, but it omits any meaningful explanation of what a 'profiler count' is, leaving the agent to infer from the name. Concise but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single terse sentence, the description is minimal for a tool. It doesn't explain what the profiler session count represents, how it differs from active/posture session counts among siblings, or what the raw XML looks like. For such a small tool the description should still disambiguate it from the many similar MNT session tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (deployment) has 100% schema coverage with a thorough description explaining accepted formats (name, slug, number) and how to list the choices via ise_list_deployments. The description adds nothing parameter-specific, but the schema already fully describes deployment, so the parameter semantics are adequately handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets the profiler session count via a specific API endpoint and returns raw XML. The verb 'Get' plus resource 'Profiler Count' is clear, though the '[Sessions]' prefix is a bit cryptic. It doesn't differ substantially from the sibling ise_mnt_active_session_count or ise_mnt_posture_session_count in terms of clarifying what distinguishes a 'Profiler' count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 the many sibling session-count/list tools (active_session_count, posture_session_count, auth_session_list). There is no context about typical use cases, prerequisites, or what makes this the right choice among the MNT session tools.
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 behavior. It specifies the endpoint (GET /api/v1/certs/certificate-signing-request) and that it retrieves CSRs from PAN (Policy Administration Node), which adds useful context. However, it doesn't disclose pagination behavior, return format, max result limits, or whether anything is mutated. For a fetch tool this is moderate but still leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line, effectively front-loaded with the purpose. No wasted words. However, it could be argued it's slightly under-specified in terms of behavioral content, but as a structure it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list/fetch tool with 0 required parameters and no output schema, the description provides the essence. The endpoint is documented, the PAN scope is clarified, and the deployment targeting is handled well. However, the pagination params (page/size) are unexplained, and with no annotations and no output schema, the agent gets limited behavioral context about what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, with only the 'deployment' parameter having a description. The page and size parameters lack descriptions entirely, and the description text doesn't explain them either. The deployment parameter description is actually quite good, explaining format choices and pointing to ise_list_deployments. With 1 of 3 parameters helpfully documented, this is slightly above baseline but the page/size semantics remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb+resource: 'Get all Certificate Signing Requests from PAN' with the API endpoint path. The tool name itself (ise_openapi_cert_csr_list) is highly descriptive, and the category prefix '[Certificates]' plus the GET endpoint make purpose clear. It doesn't explicitly distinguish from siblings, but the focused naming and the 'all... list' phrasing differentiate it from get/delete/import variants among cert siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description doesn't explain when to use this list tool versus the other certificate tools (ise_openapi_cert_system_list, ise_openapi_cert_trusted_list) which are the closest alternatives. No exclusions, prerequisites, or context about where CSR listing fits in a workflow are given.
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 provided, so the description carries full burden. It does not disclose that this is a write/update operation with potential side effects on network access policy, whether partial updates are supported, or what gets returned on success/failure. The tool name implies 'update' but behavioral details beyond that are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single-line description with domain context, tool group, and endpoint. Efficient and to the point with zero wasted words. The bracketed context and endpoint reference are useful though could arguably be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a nested object parameter (data). The description provides no guidance on the shape of the request body, no indication of what the response contains, and no mention of how to obtain a valid policy set object for updating. For a write operation on network access policy, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 params. The description itself adds no parameter-level detail beyond what's in the schema. The 'data' param is just 'JSON request body' with no mention that it should contain the full policy set representation for a PUT. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Update a policy set' with the specific resource (Network Access policy set) and HTTP method (PUT). The '[Policy: Network Access]' prefix adds domain context. It doesn't explicitly distinguish from the TACACS policy set update sibling, but the 'Network Access' qualifier implies differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. It doesn't mention prerequisites like fetching an existing policy set first (via ise_openapi_radius_policy_set_get), or warn that a full object is typically required for PUT operations. The deployment parameter hints at multi-deployment context but doesn't explain the selection logic.
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 does not state whether this is a read-only safety operation (presumably it is, since it's a GET/listing), what the response format is, whether pagination is used, or what happens when the repository doesn't exist. The description merely restates the HTTP endpoint without behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the verb, resource, and endpoint. It's appropriately brief with no wasted wording. Slightly more context about the repository concept could help, but the efficiency here is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately simple read/list tool with full schema coverage and no output schema. The description tells the agent what it does but not the behavioral context (read-only nature, return format, error behavior). Given no annotations and no output schema, the description should provide more guidance about what the agent can expect from calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with 'name' documented as 'Path parameter name' and 'deployment' documented with clear format options and fallback behavior. The description itself adds no parameter detail beyond the endpoint URL, but the schema already does the heavy lifting, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get list of files in a repository' with a specific verb (list/get) and resource (files in a repository), and specifies the endpoint GET /api/v1/repository/{name}/files. It distinguishes reasonably from sibling ise_openapi_repo_list (list repositories) and ise_openapi_repo_get (get repository), though it doesn't explicitly contrast them. The '[Repository]' prefix adds domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description doesn't mention when this tool is preferred over alternatives, nor does it state any prerequisites (e.g., repository must exist). The deployment parameter hints at multi-deployment usage, but no exclusions or context on when to omit it vs. specify it is given.
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 reveals this is a read/GET operation via the endpoint path, but doesn't state pagination behavior, return structure, what the command sets represent, or whether this reflects vs. external authentication configuration. For a list tool with no annotation coverage, this is a meaningful gap in safety/behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that clearly states purpose and includes the REST endpoint. No wasted words. The deployment parameter has a well-crafted inline description. It could earn a 5 with a sibling differentiation note, but as written it's efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with no output schema, the description provides the essential purpose and endpoint. It's adequate but not rich: no mention of what fields each item contains, how many command sets typically exist, what specific filtering is available, or relationship to TACACS profiles. Given the sibling ise_ers_list_tacacscommandsets overlaps in purpose, additional context would help disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only deployment has a description, which is rich and helpful). The page and size parameters have types and defaults but no description. The description itself doesn't explain page/size semantics either. However, page/size with defaults of 1 and 100 are relatively self-explanatory for a list endpoint, and deployment is well-documented, so the schema partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Device Admin - Return list of command sets' with an explicit REST endpoint (GET /api/v1/policy/device-admin/command-sets). The verb+resource is clear, and the 'Device Admin' prefix provides policy context. However, it doesn't explicitly differentiate from sibling ise_ers_list_tacacscommandsets, which serves a similar listing purpose through a different API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs the sibling ise_ers_list_tacacscommandsets or other TACACS tools. No exclusions, prerequisites, or alternative recommendations are mentioned. The deployment parameter description does note 'Omit to use the only/default deployment. Call ise_list_deployments to see the choices,' which provides some usage context but nothing about when this tool is preferred.
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 indicates it's a GET operation (safe read) which implies non-destructive behavior, but doesn't describe pagination behavior, whether results are ordered, the structure of returned conditions, or any rate limiting. The raw API endpoint inclusion is helpful transparency, but limited overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one clause stating purpose, one clause with the API endpoint, and the endpoint context. It's front-loaded with the key information. No wasted words, though it could arguably be more information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with 0 required params and no output schema, the description is mostly adequate. It identifies the resource, the API path, and policy domain. However, it lacks detail on pagination return behavior, whether the conditions list is filtered by deployment in any meaningful way, and doesn't describe what fields each condition contains. Given low complexity and a single schema-described param, this is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'deployment' has a description in the schema). The page and size parameters are self-evident from their names and defaults, and their meaning (pagination) is implied. The deployment parameter has a thorough schema description. However, the tool description itself adds nothing beyond what's in the schema, so it doesn't compensate for the 67% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns a list of library conditions for Device Admin policy, with a specific API endpoint (GET /api/v1/policy/device-admin/condition). It's clear it's a list/read operation on TACACS conditions, and the tool name 'tacacs_condition_list' plus '[Policy: Device Admin]' prefix distinguishes it from the radius_condition_list sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the name indicates it's for TACACS Device Admin conditions, the description doesn't point to sibling tools like ise_openapi_radius_condition_list or mention that TACACS condition-specific filtering might exist elsewhere. The deployment parameter hints at targeting a specific ISE deployment but no broader usage context is given.
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 reveals this is a read-only GET operation via the endpoint, but doesn't describe what the response contains, error conditions, auth requirements, or the structure of the returned policy attributes. The GET verb gives some implicit safety signal but nothing explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the category and action. It communicates the purpose efficiently in one sentence plus the endpoint format. No wasted words, though it could perhaps include a touch more behavioral detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-id operation with 100% schema coverage and deployment guidance baked in, this is largely complete. However, without an output schema or any return-value description, an agent doesn't know what fields to expect from the returned policy set attributes. The deployment param guidance is a useful addition that compensates somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (id, deployment) having clear descriptions. The deployment parameter description is notably thorough, explaining the accepted formats (name, slug, number) and cross-referencing ise_list_deployments. The id description is minimal but adequate for a path parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get policy set attributes' with a specific HTTP resource endpoint, which clearly identifies the verb (GET) and resource (TACACS device admin policy set). However, it doesn't differentiate this from sibling tools like ise_openapi_tacacs_policy_set_list or the RADIUS equivalents, though the tool name itself does carry the distinction reasonably well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the list, create, update, or delete siblings. The description only identifies the resource being fetched. There is no mention of preconditions, when a GET is appropriate, or what distinguishes this from other policy set operations.
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. The description only states it returns a list of shell profiles, but gives no information about pagination behavior (despite page/size params), default limits (size default 100), whether results are filtered, or what fields each profile contains. For a read operation with no annotation support, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the endpoint path appended. It's efficient and front-loaded with the resource and action. No wasted prose, though it could arguably include more behavioral detail without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain more. It doesn't describe what a shell profile contains, pagination mechanics, default size behavior, or how this relates to the Device Admin TACACS configuration flow. For a tool with 3 params and no schema coverage on two of them, the description is inadequate for safe, correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'deployment' is documented in the schema). The description itself does not elaborate on 'page' or 'size' semantics beyond what a reasonable agent might infer, nor does it explain the response format. However, page/size are conventional and the deployment param is well-documented in the schema. The description adds no parameter value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (shell profiles) and scope ([Policy: Device Admin] Device Admin), with a clear verb 'Returns list of'. It includes the REST endpoint path, which adds specificity. It distinguishes from siblings like ise_openapi_tacacs_command_sets_list because it explicitly targets shell profiles in the Device Admin policy namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a TACACS deployment), nor does it differentiate from ise_ers_list_tacacsprofile or ise_openapi_tacacs_command_sets_list. The deployment parameter hints 'Target ISE deployment' but doesn't explain the broader selection context.
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 transparency burden. It does not disclose behavior traits such as pagination behavior, whether filtering requires exact column names, how LIMIT interacts with results, or what the output format is. The days_back parameter references 'the view's time column' in the schema but the description doesn't explain the returned data structure or any quirks. For a report tool, it lacks disclosure about default behavior (e.g., does it return all rows if limit is omitted?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is somewhat under-specified - it is essentially just repeating the title and listing columns. The front-loading is fine, but it could include more useful information without much length cost, such as noting it reflects recent configuration changes or how the audit differs from administrator logins.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, no annotations, and the description is minimal. Given the complexity (multiple filter/order/limit parameters), the description should provide more guidance on the semantics of the report (what configuration audit data represents, how it relates to administrator actions) and what the returned rows look like. The column list helps but the lack of behavioral and output context leaves significant gaps for an agent to correctly understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each of the 7 parameters already has a description in the schema. The tool description lists the filterable columns (ID, TIMESTAMP_TIMEZONE, etc.), which is valuable because it tells the agent which columns are valid filter_column/order_by values. The parameter_semantics baseline is therefore 3, and this column list does add some value beyond the schema by enumerating valid filter targets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title '[Report] Change Configuration Audit' combined with the description 'Displays the configuration audit data' clearly identifies this as a report/view tool for viewing configuration audit records. It lists the filterable columns which adds specificity. However, it doesn't strongly distinguish itself from sibling report tools beyond the specific 'Change Configuration Audit' name, though the column list does help differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it displays configuration audit data but gives no explicit guidance on when to use this vs. alternatives. Among the ise_dc_view_* report tools (radius auth, tacacs, endpoints, administrator logins, etc.), the name implies this is for configuration changes specifically, but the description doesn't explicitly call out scenarios or contrast with ise_dc_view's more generic query mechanism. No exclusions or alternative recommendations are provided.
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 full burden of behavioral disclosure. The description is a simple read-ish statement ('Get') with no details about permissions, response shape, pagination, or error behavior. However, the tool name and description clearly indicate a fetch-by-ID operation which is inherently low-risk; still, there is no added behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient. However, the deployment parameter in the schema has detailed documentation while the description adds nothing about it. The sentence is minimal but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-object fetch tool with 1 required parameter (id) documented in the name, the description is arguably sufficient. However, there is no output schema, no annotations, and the description does not clarify what the return value looks like or whether the endpointgroup concept differs from identitygroup (a sibling tool). Given the low complexity, this is borderline adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the id parameter has no description in the schema, and the description does not explain it either. The deployment parameter's meaning is well documented in the schema itself. The description adds nothing about parameter semantics; the id meaning can only be inferred from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single Endpoint Identity Groups object by ID' which conveys a clear verb+resource+scope. It distinguishes from sibling list/search tools (ise_ers_list_endpointgroup, ise_ers_search_endpointgroup) by emphasizing singular fetch-by-ID. It does not name alternatives but the sibling differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use get vs list or search variants. The tool name pattern strongly implies use when you have a known ID, but the description does not explicitly state this or mention alternatives like search_endpointgroup for name-based lookup. Sibling tools exist that could perform similar functions, but no distinctions are drawn.
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. The description only states what the tool does (get by ID) but reveals nothing about response format, error handling for invalid/unknown IDs, authentication requirements, or whether the operation is read-only. For an ERS get operation the safety profile is implied by naming convention, but the description itself adds no behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that fully conveys the tool's purpose. It's compact with no wasted words. However, given the complexity of the deployment parameter and the ambiguity around id semantics, additional brief context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must carry more weight. For a get-by-ID tool, the description should at least note what happens for unknown IDs (error vs empty), and ideally document that SGT gets return the full SGT object. The sibling set includes ise_ers_list_sgt and ise_ers_search_sgt, so clarifying the distinction would improve completeness. The deployment parameter adds complexity that the description doesn't address beyond schema text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the 'id' parameter (string, required) and the 'deployment' parameter with detailed semantics. The description adds the critical meaning of 'id' — it's the SGT ID used to fetch a specific object — and confirms the deployment targeting. Schema description coverage is 50% (deployment is well-described, id is not), and the description helps define what 'id' refers to. The deployment guidance (including referencing ise_list_deployments) is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pattern: 'Get a single Security Group Tags (SGTs) object by ID.' It clearly states the operation (get by ID) and the resource type (SGT). However, it doesn't differentiate from sibling tools like ise_ers_search_sgt or ise_ers_list_sgt, though the 'by ID' qualifier somewhat distinguishes it from list/search variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like ise_ers_search_sgt or ise_ers_list_sgt. Sibling tools include list, search, and get variants for SGTs, but the description doesn't clarify the selection criteria (e.g., 'use this when you have an exact ID'). The deployment parameter schema does mention ise_list_deployments, but that's parameter-level guidance, not tool-level usage context.
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 full burden for behavioral disclosure. It mentions 'Paginated' which is useful, but doesn't state return format, page size defaults/limits, whether this is a safe read operation, authentication needs, or performance implications. For a list operation with no annotations, more behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise two-sentence description with zero waste. It front-loads the primary purpose. However, given the tool's relative simplicity, more behavioral detail could have been packed in without becoming verbose. It's efficient but arguably under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A paginated list tool with no annotations, no output schema, and no pagination parameters documented in the schema (page/size have no descriptions). The description only says 'Paginated' without explaining page/size defaults, max values, or how to page through. Given the tool's simplicity this is borderline adequate but the pagination gap is a real shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (deployment is described, but page and size are not). The description adds the pagination behavior ('Paginated') which gives meaning to page/size, and the deployment param already has a rich schema description. The description partially compensates for the 67% schema gap by signaling pagination semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Internal Users. Paginated.' clearly states the verb (List) and resource (Internal Users), and distinguishes this from sibling tools like ise_ers_get_internaluser (single retrieval) and ise_ers_search_internaluser (filtered search). The pagination note adds scope clarity. However, it doesn't explicitly contrast with search_internaluser to reinforce the 'all' scope versus filtered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling search tool (ise_ers_search_internaluser), get tool, or other list tools. The pagination mention implies large-result scenarios but no explicit exclusions or alternative recommendations. No prerequisites or context given about deployment requirements beyond the 'deployment' param schema description.
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 burden for behavioral disclosure. The description notes pagination behavior ('Paginated') but doesn't disclose whether this is a safe read operation, what the default page size is, or any rate limiting or authentication requirements. The pagination mention is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence - efficient and to the point with no wasted words. However, at only 5 words it borders on under-specification rather than true conciseness. The front-loaded structure is good but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is relatively sparse. A list operation is straightforward, but the description doesn't clarify what fields are returned, whether results are sorted, or how pagination behaves (offset vs page-based). The deployment parameter is well-documented in the schema, which helps. For a simple filtered-list tool this is borderline adequate but thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% - of the 3 parameters (page, size, deployment), only 'deployment' has a description. The description text itself adds no parameter information beyond 'Paginated', which weakly implies the page/size parameters exist. The deployment parameter description is in the schema and is helpful (references ise_list_deployments), but the description doesn't supplement any of it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Portals. Paginated.' clearly identifies the verb (list), resource (Portals), and scope (all). It distinguishes from sibling get_portal and search_portal tools. While concise, it doesn't mention any supporting context beyond pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like ise_ers_get_portal or ise_ers_search_portal. The description provides no context for when listing all is preferable to searching or getting a single portal, though pagination is mentioned.
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 notes 'Returns raw XML', which is helpful behavioral disclosure (format of return), but doesn't mention that this is a read-only operation, whether authentication/permissions are needed, pagination behavior, or the volume/shape of data returned. For a monitoring tool with zero annotation coverage, more disclosure is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (one sentence plus endpoint reference and return-format note). However, the endpoint URL (GET /admin/API/mnt/Session/ActiveList) is arguably structured information an agent doesn't need, while genuinely useful context (when to use vs alternatives) is absent. It earns its length but trades useful detail for a raw endpoint echo.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only list operation with a 100%-covered schema, this is near-minimally viable. The 'Returns raw XML' note provides some useful context, and the deployment parameter is well documented in the schema. However, the description is thin on when this differs from the adjacent session tools (auth_session_list, active_session_count) and doesn't clarify what fields/elements are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is fully documented in the schema. The description itself adds no param information, but the schema already explains the deployment parameter thoroughly, including its 3 accepted forms and a pointer to ise_list_deployments. Baseline 3 is appropriate, nudged to 4 because the schema is exceptionally rich and self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Active Session List' uses a clear verb+resource structure and identifies it as related to sessions. The '[Sessions]' prefix groups it with sibling session tools, though it doesn't explicitly differentiate from ise_mnt_auth_session_list or other session-list tools. It's clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like ise_mnt_active_session_count or ise_mnt_auth_session_list. It only states the API endpoint. No context is given about whether this returns all active sessions or is filtered, or what distinguishes 'active' from other session categories.
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 is a mutation operation (POST import) but does not disclose any behavioral traits: no mention of whether existing certificates get replaced, whether overwrite occurs, password requirements for PKCS12, or what happens on conflict. No output/response behavior described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a trailing API endpoint reference. However, it is essentially a restatement of the endpoint path and name — it adds little beyond what the tool name and title convey. It is compact but sacrifices useful information (purpose beyond 'import', payload details) for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested 'data' object parameter with 100% schema coverage but no schema structure shown for the import payload in the description. There is no output schema, no mutation-behavior disclosure (no annotations), and the description does not explain what the data body must contain for a successful system certificate import. For a security-sensitive write operation, this is significantly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 minimal benefit: 'data' is documented as 'JSON request body' but the description does not explain what fields the import body must contain (e.g., name, cert, privateKey, password, allowOutOfDateCert). The deployment parameter is documented only in the schema. The description does not compensate for the nested-object complexity of the data parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Import system certificate in Cisco ISE') and references the specific API endpoint (POST /api/v1/certs/system-certificate/import). The [Certificates] prefix groups it with other certificate tools, and the name distinguishes it from export/list/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives like ise_openapi_cert_trusted_import or ise_openapi_cert_system_list. The [Certificates] prefix and 'system certificate' wording imply a category, but there is no mention of when to choose system vs trusted certificate import, nor prerequisites (e.g., having a PEM/PKCS12 payload ready).
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. Yet it only states the endpoint and offers no behavior details: no mention that this is a safe read-only operation, no return format, no error cases (e.g., not-found), no authentication requirements. For a GET-style fetch with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse line that captures the endpoint but reads as an auto-generated API label rather than a composed description. It's compact with no waste, but it's arguably under-specified rather than truly concise—there's room for useful content without bloat. Front-loading is fine but the content is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fetch-by-ID tool with no output schema and no annotations, the description should explain what the agent gets back, any error conditions, and relation to list/update/delete siblings. It does none of this. The 100% param coverage helps, but behavioral and output context is entirely absent, making the tool weakly self-describing for an agent navigating a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the two parameters (id, deployment) documented in the schema. The description adds nothing beyond the schema about these parameters. The deployment parameter has a helpful inline explanation in the schema (deployment names/format). Per the baseline rule, a 3 is appropriate since the schema does the heavy lifting and the description contributes no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ([Certificates]), verb (Get), and specific item (Trust Certificate By ID) with the exact API endpoint. It distinguishes itself from sibling cert tools (system/trusted/csr lists and mutations) by being the specific 'get by ID' operation for trusted certificates. However, it doesn't explicitly note what distinguishes it from 'cert_trusted_list' beyond the implied 'by ID' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is essentially an API endpoint label rather than usage guidance. It implies usage (fetch a trusted certificate by ID) but provides no explicit when-to-use vs alternatives, no exclusions, and no context about prerequisites (e.g., needing to know an existing certificate ID first, perhaps from a list call). Without sibling differentiation, the agent must infer context.
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. The description reveals only the HTTP verb (GET) and endpoint path, but does not describe return format, pagination behavior, whether it reflects current vs configured state, or any permissions required. For an unannotated tool this is a significant gap beyond what the name already signals (a read operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise label-plus-path line with no filler. It is appropriately short, front-loads the licensing domain, and adds the endpoint URL which helps mapping to API docs. No redundancy with the function name beyond the domain framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter list/query tool with no output schema and only partial parameter documentation, the description is thin. It does not explain what the connection types are, what fields the response will contain, or how page/size interplay. Sibling tools like ise_openapi_cert_system_list and Radius list operations may share patterns, but the description does not cross-reference or clarify the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 params documented). The deployment parameter has a rich description explaining accepted formats (name, slug, number) and pointing to ise_list_deployments. However, page and size parameters are undocumented in the schema and get no mention in the description, leaving the agent to infer their semantics from defaults. The documents-covered param adds genuine value but the uncovered half is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[Licensing] License - Connection Type (GET /api/v1/license/system/connection-type)' identifies the resource as license connection type and the endpoint path, but does not state what a 'connection type' represents or what information the GET returns. It's not a tautology, but 'License - Connection Type' is merely a label that mirrors the function name with little semantic enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool vs alternatives. There are no sibling license-connection-type tools, but the broader license tool family (smart_state, tier_state, register, eval) exists. No guidance is given on when this query is appropriate or what distinguishes it. It falls to the safe openapi read pattern implied by the name.
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 fails to disclose this is a read-only list operation, whether pagination behavior is relevant, what the response format is, whether it requires any auth/role, or how many repositories one might expect. The page/size parameters imply pagination but the description doesn't state any behavior about it. For a read tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and to the point. The '[Repository]' prefix helps categorize the tool. However, it front-loads minimal information and the endpoint mention is somewhat redundant given the pattern of OpenAPI-derived descriptions. It could use the space more effectively to describe what a repository is and what the list returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description could explain what the returned list contains. The tool is relatively simple (list operation with pagination), so the baseline need is lower, but the description leaves the reader unclear about what repositories are (backup repos?), the shape of the response, and how page/size interact. Adequate for a simple list tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'deployment' has a description). The description compensates well for the two undocumented parameters (page, size) through their defaults in the schema, and adds genuinely helpful semantics for the 'deployment' parameter explaining format options (name, slug, or number) and default behavior. Given the low schema coverage, this is reasonably good compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as repositories list from the ISE deployment repository ([Repository] Get list of repositories) and mentions the GET endpoint. However, it's quite generic and doesn't clarify that this relates to backup repositories specifically (as evidenced by sibling tools like ise_openapi_repo_create/update/delete and backup tools). It doesn't distinguish well from other list operations in the sibling set, and the meaning of 'repository' in the ISE context is left ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'deployment' parameter description offers solid guidance on when to use it: 'Omit to use the only/default deployment. Call ise_list_deployments to see the choices.' However, there's no general guidance on when to use this tool vs other list tools, no stated use cases, and no exclusions or alternatives for listing repositories. The endpoint reference provides partial context but no strategic usage guidance.
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 provided, the description carries the full burden of behavioral disclosure. It mentions 'performance oriented view' which hints at efficiency, but doesn't disclose pagination behavior, result ordering, whether results are capped, or what happens with large result sets. The reference to 'last seven days' is the only behavioral detail, which is a thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a column enumeration, which is reasonably compact. But it front-loads the report label and then crams the entire column list into one run-on phrase. The structural organization is adequate but could be cleaner with bulleted columns or clearer sentence boundaries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex query tool with 7 parameters and no annotations or output schema. The description and schema together are sufficient for an agent to invoke it with reasonable parameters, but the description is thin on behavioral context (pagination, performance limits, result semantics). Given the sibling set includes a nearly identical non-weekly view, more explicit differentiation would help. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are documented in the schema. The description adds the list of filterable columns (ID, TIMESTAMP_TIMEZONE, ISE_NODE, etc.) which helps the agent know valid filter_column values. But the description doesn't go beyond the schema much; the column list is the main added value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a report view containing RADIUS authentication records for the last seven days, and enumerates the filterable columns. The '[Report]' prefix and the 'week' in the name effectively communicate the time scope. However, it doesn't strongly distinguish from siblings like ise_dc_view_radius_authentications (the non-weekly version) beyond the time window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent it's a performance-oriented view for the last seven days, which implies temporal use. But it doesn't explicitly say when to choose this over the non-weekly ise_dc_view_radius_authentications or the summary view sibling, nor does it state exclusions or alternatives. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description ('Get a single object') implies a read operation, but doesn't confirm what is returned, what happens if the ID doesn't exist (error behavior), whether it requires specific permissions, or if there are rate limits or pagination concerns. For an ERS API wrapper, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the purpose without wasted words. It's appropriately concise for a simple GET-by-ID operation. Not a 5 because it lacks any additional useful structure beyond the core purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no output schema, no annotations, and a 50% schema coverage gap on the required 'id' parameter, the description is insufficient. It doesn't describe the return format, clarify the id parameter format, or address error behaviors. Compared to sibling equivalents that likely follow the same minimal pattern, this is consistent but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% - the deployment parameter has a rich description, but the 'id' parameter has none beyond its type. The description doesn't clarify what format the id takes (UUID, URL-encoded, etc.) or where to find it. The deployment parameter guidance is well-covered in the schema itself, so the description adds limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Get' plus resource 'ANC Endpoints object' with 'by ID' is clear and specific. It distinguishes itself from siblings by the 'get by ID' pattern versus list/search siblings like ise_ers_list_ancendpoint and ise_ers_search_ancendpoint. Slight deduction because it doesn't further clarify what an ANC Endpoint is or what the object contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sibling naming convention (get vs list vs search) implicitly conveys when to use this tool versus the list/search variants, but the description provides no explicit guidance on when to choose this over alternatives. The deployment parameter description gives useful context about deployment targeting, but overall usage context is only implied.
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 full burden. It states the get operation but discloses nothing about behavior: no indication this is a read-only/safe operation, no mention of what happens for a non-existent ID (404 vs empty), no authentication/permission requirements, no pagination. For a single-object retrieval tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the action clearly. There's zero waste. It could add a note about the Guest User resource naming, but at 10 words it is appropriately lean given the schema already documents the deployment parameter thoroughly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with 2 params and no output schema, so complexity is low. However, with no annotations, no output schema, and a minimal description, the agent lacks context about what a Guest User object contains, error behavior, or permission requirements. The deployment parameter compensates somewhat via schema, but the overall picture is thin for a tool operating in a system as complex as ISE ERS.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description adds the semantic 'by ID' for the id parameter, which is implied but useful. The deployment parameter is fully documented in the schema itself with rich guidance (name/slug/number, default behavior, which tool to call for choices), so the description needn't add more. The id parameter's meaning is adequately conveyed by the name and description, keeping this at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Guest Users object by ID' uses a specific verb (get), names the resource (Guest Users object), and specifies the accessor (by ID). It clearly distinguishes from the 'list' and 'search' siblings which retrieve multiple objects. However, it doesn't highlight the distinction that guests are named 'Guest Users' (plural) in ERS terminology, which is minor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you already have a guest user's ID, use this to fetch a single object. The sibling set makes clear that 'list' returns all and 'search' queries by attribute, so get-by-id is implicitly different. However, there's no explicit when-to-use vs alternatives, no mention that it requires a known ID (as opposed to search by name), and no guidance distinguishing it from ise_ers_search_guestuser.
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 exist, so the description carries the full burden of behavioral disclosure. The description states only a read action (Get), but doesn't describe what happens if the ID is not found, whether errors occur for invalid IDs, what response format is returned, or any permissions/deployment requirements beyond the deployment parameter hint in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that conveys the core purpose efficiently. No wasted words or repetition. Adequately front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple retrieval tool with no output schema and no annotations. The description is minimal but does state the core operation. However, given the sibling tool family (search vs get vs list), the description could more clearly position this within the retrieval hierarchy and explain what a 'successful' response looks like or how to handle not-found cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (id is undocumented in the schema while deployment has a rich description). The description confirms 'id' is required for lookup, adding minimal meaning, but it doesn't explain what format the id should be in (UUID vs numeric) since schema coverage is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Security Group ACLs (SGACLs) object by ID' uses a specific verb (Get) with a clear resource (SGACL object) and distinct retrieval method (by ID). It differentiates from sibling tools like ise_ers_list_sgacl and ise_ers_search_sgacl, though it doesn't explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by ID' phrasing implies this is for retrieving one specific object, distinguishing it from list/search variants, but there's no explicit statement of when to use this vs ise_ers_search_sgacl or ise_ers_list_sgacl. No exclusions or when-not-to-use guidance provided.
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. 'Paginated' is a meaningful behavioral disclosure indicating the tool returns page-based results controlled by page/size parameters. However, it doesn't disclose return format, error behavior, or what fields each protocol record contains. The pagination note is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two short phrases, but arguably under-specified. 'List all Allowed Protocols. Paginated.' conveys purpose and the pagination mechanism, but given only 33% schema coverage, the description is too thin to fully compensate for undocumented page/size parameters. It's efficient but sacrifices helpfulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list/read tool with pagination, the description covers the core behavior. No output schema exists, and the description doesn't explain the return structure. With zero annotations, the description should disclose more about what 'Allowed Protocols' records include. Adequate but leaves the agent guessing about use cases and return format for a simple list utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the deployment parameter has a description; page and size are bare integers with defaults). The description adds 'Paginated' which clarifies page/size purpose, but adds nothing about the format or units of page/size beyond defaults. The deployment parameter has a rich schema description already, so the description adds marginal value there. Partial compensation for the undocumented page/size params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'List all Allowed Protocols' with a specific verb (List) and resource (Allowed Protocols). It distinguishes itself from get_allowedprotocols and search_allowedprotocols siblings by the 'List' framing, though it could more strongly differentiate itself. The word 'all' clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There's a sibling ise_ers_get_allowedprotocols and ise_ers_search_allowedprotocols, but no explanation of when to choose list over get/search. The deployment parameter references calling ise_list_deployments, which is some implicit guidance, but no when/when-not context.
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 'Paginated' but doesn't describe the return format, default page size behavior, whether pagination uses the size parameter as a hard cap, error handling, or resource limits. For an ERS API tool that performs a network read, this lacks meaningful behavioral detail beyond the annotation-free status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two short sentences with no filler. The acronym expansion is useful and front-loaded. However, it is arguably under-specified rather than lean, so it earns a solid but not top conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and only 33% schema coverage, yet the description is minimal. For a paginated API list operation, the description should note what a response contains or how pagination behaves to help the agent know whether to iterate. The complexity is low, but given zero behavioral disclosure elsewhere, this description is incomplete for reliable automatic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the deployment parameter has a description; page and size are bare integers). The description adds no parameter semantics beyond 'Paginated' which hints at page/size but doesn't explain their exact semantics. Pages start at 1 and size defaults to 100 per schema, but the description doesn't reinforce or clarify these behaviors. With low schema coverage, the description should have compensated more than it does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Downloadable ACLs (dACLs). Paginated.' clearly states the verb (List), resource (Downloadable ACLs), and provides the acronym expansion (dACLs). It distinguishes from sibling tools like ise_ers_get_downloadableacl (single get) and ise_ers_search_downloadableacl (search) since it is the list operation. However, it doesn't explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Paginated' which implies the page/size parameters control result pagination, giving some usage context. The deployment parameter schema itself provides guidance about alternatives. However, no explicit when-to-use-vs-alternatives guidance is provided; the agent must infer from the tool name that this is the bulk-listing operation versus get (specific ID) or search (filtered lookup).
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, but it only states 'Paginated.' which hints at paging behavior without specifics like page size limits, ordering, or error conditions. The deployment selection behavior is documented in the schema param, not the description. It's a safe read operation (List) but gives minimal extra behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two phrases in one line. Every word earns its place, though it's arguably under-specified rather than lean in a way that adds value. It's front-loaded with purpose then the single behavioral note about pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 params, no output schema, and no annotations, so the description carries significant burden. It provides only purpose and pagination note. For a listing tool that returns an array of identity groups, it gives no sense of result count expectations, ordering, or relationship to the deployment parameter. The pagination behavior with page/size is referenced only implicitly. This is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 'deployment' has a description; 'page' and 'size' rely on names/defaults). The description adds nothing beyond the schema; 'Paginated' loosely maps to page/size semantics. With only partial coverage, the description could compensate but doesn't detail page/format expectations, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Identity Groups. Paginated.' uses a specific verb (List) and resource (Identity Groups), clearly indicating the operation. It distinguishes from sibling 'get' and 'search' variants of identitygroup, though it doesn't explicitly contrast with them. It's a clear purpose but could slightly improve with mention of scope/fields returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use list vs the sibling get_identitygroup or search_identitygroup tools, nor when to use list_identitygroup vs list_endpointgroup. The pagination note is implicit, and the deployment parameter guidance lives in the schema, not the description. No explicit when/when-not guidance exists.
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 full burden. The description only discloses pagination behavior but does not state whether this is a read-only operation, what the default page/size behavior entails, whether it returns all fields of profiles or summary data, or any rate limits. For a list operation with zero annotation coverage, it should disclose more behavioral detail about return format and defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. 'List all Profiler Profiles. Paginated.' is efficient and front-loaded. However, it might be too sparse given the missing parameter context and absence of annotations, but for conciseness alone it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a paginated list tool with no output schema, no annotations, and low parameter coverage. It provides the essential purpose but lacks behavioral disclosure about return format, defaults, or what fields are returned. Given sibling tools like ise_dc_view_profiled_endpoints_summary exist and the naming parity with dozens of other list tools, a richer description would help distinguish behavior. The description meets the minimum but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, meaning 2 of 3 parameters (page, size) lack descriptions in the schema. The description adds no parameter-level detail beyond 'Paginated', so page and size semantics are implicit only. The deployment parameter does have a schema description with helpful examples and guidance. The description itself adds marginal value over the schema for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all Profiler Profiles. Paginated.' which clearly identifies the verb (list) and resource (Profiler Profiles) with a scope note about pagination. It distinguishes from sibling tools like ise_ers_get_profilerprofile (single fetch) and ise_ers_search_profilerprofile (search against criteria), though it does not explicitly name these alternatives. The purpose is clear 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Paginated' note implies the tool returns pageable results, giving some usage context. The description does not explicitly state when to use this versus ise_ers_search_profilerprofile or ise_ers_get_profilerprofile. However, the naming convention across siblings (list vs search vs get) is consistent and inferable. No explicit exclusions or alternative guidance is given.
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. The description only states the operation is paginated, but doesn't disclose whether this is a read-only operation, what the response format is, how many items are returned per page by default, or whether there are rate limits or ordering guarantees. For a listing tool that could return large datasets, the pagination behavior is mentioned but not elaborated on (e.g., default page size, how to page through results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste - efficient and front-loaded with the core purpose. It states the action and the pagination trait concisely. However, it's arguably under-specified given the parameter coverage gap and missing behavioral details, so it's not at the highest tier of quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should disclose more behavioral context. The deployment parameter suggests multi-deployment support, but the description doesn't clarify that. It also doesn't mention that a get/search variant exists for more specific retrieval, or describe expected return format. For a multi-deployment, paginated listing tool, richer context would materially help an agent select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33% - only the 'deployment' parameter has a description in the schema, while 'page' and 'size' have none. The tool description itself adds nothing about parameters beyond noting pagination. The deployment parameter is well-documented in the schema with examples and fallback behavior, but page/size semantics (e.g., range, relationship) are entirely absent from both schema and description. With 33% coverage, the description should compensate more for the two undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all REST ID Stores. Paginated.' clearly states the verb (List), resource (REST ID Stores), and scope (all), distinguishing it from the sibling tools like ise_ers_get_restidstore (singular get) and ise_ers_search_restidstore (search). The pagination mention is a helpful extra detail. Though terse, the purpose is unambiguous and effectively separable from sibling tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for enumerating REST ID Stores (as opposed to get for single item or search for filtering), which provides clear context by virtue of sibling naming conventions. However, it doesn't explicitly state when to use this vs alternatives, and doesn't mention that the get version exists for retrieving a specific store. The pagination hint slightly clarifies usage but there's no explicit guidance of when not to use this tool.
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 full burden for behavioral disclosure. It does not state whether this is a read-only operation, how results are paginated, what the default behavior is when no filter is supplied, or what the response structure looks like. For a search tool operating on a resource, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with minimal waste. It front-loads the core purpose and mentions the filtering mechanism. However, given its brevity, it could realistically have packed in more behavioral info without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters but only 20% schema coverage, no output schema, and no annotations, the description does too little. It fails to explain the ERS filter expression format, return shape, pagination defaults, or when deployment is required. Compared to sibling search tools across the suite, this one provides minimal guidance for a resource with moderately complex filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only the 'deployment' parameter is described). The description mentions 'ERS filter expressions' for the filter parameter but doesn't explain ERS filter syntax or the semantics of page/size/sort. The description adds some meaning for the filter parameter but leaves page, size, and sort unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter Allowed Protocols with ERS filter expressions' clearly states a search/filter operation on the Allowed Protocols resource, distinguishing it from sibling list_allowedprotocols (likely a plain list) and get_allowedprotocols (single item). The verb+resource is specific and the ERS filter expression mechanism is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's for filtered searching of Allowed Protocols but doesn't explicitly state when to use it vs ise_ers_list_allowedprotocols. No explicit when/when-not guidance or alternative tool names are given, though the sibling naming convention and mention of 'filter expressions' implies the use case.
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 provided, the description carries full behavioral disclosure burden for a search/mutation operation on a network security appliance. It does not disclose that search results may be paginated (though page/size params exist), any permission requirements, rate limits, or what happens on errors. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single declarative sentence, zero waste, front-loaded with the core action. However, it is under-specifying rather than concise in the best sense—the sentence is short but doesn't carry the helpful detail the tool warrants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search/filter tool with no output schema and only 20% schema coverage, so the description must do substantial explanatory work. It fails to explain ERS filter expression syntax, how pagination works, or how this differs from the generic ise_ers_search tool (which likely also does ERS filtering). For a network admin tool with zero annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (5 params, only deployment described). The description adds that 'filter' takes ERS filter expressions, adding some meaning. However, the critical 'filter' parameter format/syntax is not explained, and page/size/sort semantics are left entirely to schema defaults. The description partially compensates but doesn't fully bridge the low coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter ANC Policies with ERS filter expressions' uses a clear verb (Search/filter) plus resource (ANC Policies) and mechanism (ERS filter expressions). It distinguishes this from sibling list/get tools (ise_ers_list_ancpolicy, ise_ers_get_ancpolicy) by emphasizing filtering, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'filter expressions' implies the filter parameter is the key differentiator, and the deployment parameter guidance (from schema) mentions calling ise_list_deployments for choices. However, the description itself provides no explicit when-to-use vs. alternatives guidance, and 'ERS filter expression' syntax is never explained.
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 provided, the description carries the full burden of behavioral disclosure. It reveals nothing about whether this is a safe read operation, how pagination works (page/size defaults exist), what the filter syntax should look like, or what the response format is. For a search tool with no annotation support, it should disclose more about the filter expression format and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core purpose. It has no wasted words. However, given the tool's complexity (5 params, slice-based pagination, filter syntax), the brevity leaves important information undocumented, so it's not ideal conciseness—it's underspecification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with 5 parameters, no annotations, no output schema, and low schema coverage. The description only states the purpose and mentions filter expressions, but doesn't explain the ERS filter expression syntax, pagination semantics, relationship to list_identitygroup, or sort behavior. For a tool with this parameter complexity and zero annotation/output-schema support, the description is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with only the deployment parameter documented (target deployment name/slug/number). The page, size, sort, and filter parameters have no descriptions in either the schema or the tool description. The description mentions 'ERS filter expressions' for the filter parameter, which adds some semantic value, but the four core parameters remain underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/filter Identity Groups with ERS filter expressions,' which identifies the resource (Identity Groups) and the action (Search/filter via ERS). It clearly distinguishes from the sibling list_identitygroup (list all) and get_identitygroup (single item) tools. However, the name already signals most of this, so the description adds modest value beyond a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for searching/filtering Identity Groups using ERS filter expressions, which conveys it's the targeted-search alternative to the list variant. However, it provides no explicit guidance on when to prefer this over list_identitygroup, get_identitygroup, or the generic ise_ers_search, and no exclusions or alternatives are explicitly named. The usage context is implied but not explicitly stated.
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. The description only states 'Search/filter ISE Nodes with ERS filter expressions' with no mention of pagination behavior, result format, rate limits, error conditions, or whether this is a safe read operation. For a search tool with zero annotation coverage, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that communicates the core purpose efficiently. However, given the low schema coverage and absence of annotations, there is room for a bit more detail without becoming verbose. The brevity is appropriate for the search/filter family of tools, though slightly under-informative given the documentation gaps elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with 5 parameters, 0 required, very low schema coverage, no output schema, and no annotations. The description explains what the tool does but does not compensate for the 'filter' parameter being undocumented (the core ERS filter expression syntax is unhelpful), nor does it clarify return structure or the relationship to sibling search tools. For a tool with this many documentation gaps, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low at 20%, with only the 'deployment' parameter carrying a meaningful description. The 'filter' parameter is the core of the search function but has no explanation of the ERS filter expression syntax or format. The description title mentions 'ERS filter expressions' which gives some context, but the filter parameter semantics are left entirely to the agent's inference. The search-related parameters (page, size, sort, filter) are conventional and the deployment parameter is well-documented, partially compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter ISE Nodes with ERS filter expressions' uses clear verb+resource language identifying it as a search/filter operation on ISE Nodes. It does not explicitly distinguish from siblings like ise_ers_list_node or ise_ers_get_node, but the 'search/filter' language clearly positions it as the filtering variant within the Node family, and the generic ise_ers_search is also present. It clearly states the resource (ISE Nodes) and operation (search/filter), though it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching/filtering ISE nodes but provides no explicit when-to-use guidance or alternatives. The pattern among siblings (list/get/search) is conventional and easy to infer, but no exclusions or alternative pointers are given. The deployment parameter hints at calling ise_list_deployments, giving minor context, but no clear guidance on when to prefer this over generic ise_ers_search or list_node.
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 identifies this as a mutating PUT operation, which is helpful, but doesn't disclose whether it's destructive to unspecified fields (a full PUT replacing the object could overwrite fields not present in the payload), whether it requires specific privileges, what happens on partial payloads, or what the response looks like. For a full-update mutation tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, tightly written, with the key operation (full PUT by ID) front-loaded. The second sentence instructs the payload requirement. There's no wasted prose, though it could arguably add a bit more guidance on which fields are required without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this is a moderately complex operation (4 params, nested data object, large resource enum). The description covers the essential behavioral trait (full PUT = complete payload) but omits the response format, error behavior, and prerequisites. The resource enum at 60+ options creates ambiguity that the sibling ise_ers_resources tool helps with, but the description doesn't clarify which resources actually support PUT vs only GET. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with 4 parameters total. The resource parameter is documented in the schema enum description ('Use ise_ers_resources to see all with their supported operations') and the deployment parameter has a helpful schema description. However, 'id' and 'data' parameters have no inline description in the schema and the tool description adds only 'Provide the complete JSON payload' which clarifies that 'data' must be the full object. The description meaningfully conveys that data must be complete for PUT semantics, adding value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Full update (PUT) of an existing ERS object by ID' with a clear verb (update/PUT), resource (ERS object), and method (by ID). It distinguishes from siblings like ise_ers_create (create), ise_ers_patch (partial update), and ise_ers_delete. It doesn't explicitly differentiate from patch, but the PUT vs PATCH distinction is implied by 'Full update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. It doesn't explain when a full PUT is preferred over patch (ise_ers_patch) or create (ise_ers_create), and doesn't mention prerequisites like whether the object must already exist or how to obtain the ID. The 'Provide the complete JSON payload' hint is a requirement but not a usage guideline.
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 does add one useful behavioral detail — 'Returns raw XML' — which tells the agent the response format. However, it does not disclose whether the session must be active, error behavior when the session is not found, whether the sid must be an active session ID vs a historical one, or any authentication/authorization requirements for this MNT endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight single sentence plus a return-format note. It's front-loaded with the purpose and includes the raw API endpoint path which is helpful. It avoids verbosity. Not a 5 because it could have packed in more behavioral guidance in the same space, but it's efficient with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should carry more weight. The 'Returns raw XML' note is the only behavioral context beyond the schema. It doesn't explain what an active session ID means, what happens for invalid IDs, what outputType options exist, or how this relates to session lifecycle. Given the complexity of the MNT API and zero annotation coverage, this is notably underdeveloped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'sid' and 'outputType' as path parameters and 'deployment' with full explanation. The description adds 'Returns raw XML' which hints at what outputType might control but doesn't specify valid outputType values or format expectations. Since the schema handles parameter documentation well, the baseline of 3 is appropriate; the description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Active Session by Session ID' with the HTTP method (GET) and URL path. It identifies the resource (active session) and lookup method (by session ID), distinguishing it functionally from siblings like ise_mnt_session_by_mac, ise_mnt_session_by_username, and ise_mnt_session_by_ip. It's just slightly below a 5 because it doesn't explicitly note what makes it different from ise_mnt_active_session_list or how the session ID differs from other session lookup keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does (get a session by id) but gives no explicit guidance on when to use it versus alternatives like ise_mnt_session_by_mac, ise_mnt_session_by_ip, or ise_mnt_active_session_list. The '[Sessions]' label provides mild context. There is no 'when-not-to-use' or alternative recommendations, though the sibling naming partially conveys the distinct lookup keys.
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 full behavioral disclosure burden. It doesn't state the impact of scheduling a backup, whether this overwrites an existing schedule, whether it requires admin privileges, whether changes are reversible, or what the API response indicates (task ID, success/failure). For a mutation tool (POST) with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and includes the API endpoint. It's efficient with no wasted words. The category tag and endpoint reference are useful context. It could be slightly longer to add behavioral detail, but as written it's concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a POST (mutation) operation with no annotations, no output schema, and a nested 'data' object. The description provides the API endpoint and category, but fails to explain what the schedule-config-backup body should contain, what the response returns (task tracking via ise_openapi_task_get?), and interactions with sibling backup tools. A mutation tool with no error/return handling context is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters. The description names the tool's purpose but doesn't elaborate on the 'data' JSON body structure or what fields it requires. The deployment parameter is well-described in the schema including format examples. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it schedules the configuration backup on the ISE node via a POST endpoint. It has specific verb+resource ('Schedules the configuration backup') and category tag [Backup & Restore]. It differentiates from siblings by naming the specific operation (schedule-config-backup) and differs from backup_create, backup_cancel, and backup_schedule_update. However, it doesn't explicitly distinguish from backup_schedule_update, which is closely related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The deployment parameter description gives implicit guidance ('Omit to use the only/default deployment. Call ise_list_deployments to see the choices'), which is helpful. However, there's no explicit statement of when to use this tool versus backup_schedule_update or when not to use it. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description must carry the full behavioral burden. 'import' implies a write operation, but nothing discloses side effects (e.g., whether the certificate immediately becomes trusted, whether it overwrites, whether admin/root privileges are required for cert management in ISE). The truststore is a security-sensitive target; the description doesn't warn about impact or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient line with the API endpoint embedded, which is useful. No padding or redundancy. It front-loads the primary purpose clearly. Minor point: the '[Certificates]' prefix is redundant with sibling names but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (import into truststore) with no annotations and no output schema, and the critical 'data' parameter is left as an opaque JSON body. The description explains neither the required certificate payload structure nor side effects. For a security-sensitive certificate operation, this is meaningfully incomplete compared to what a capable agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (data and deployment) have schema descriptions. The 'data' object is opaque ('JSON request body') with no field-level explanation of what must be included for certificate import (e.g., cert contents, format, friendly name). The deployment param is well-documented in the schema, so the description adds nothing beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Add root certificate to the Cisco ISE truststore' with the API endpoint. It clearly distinguishes from siblings like ise_openapi_cert_trusted_list/get/delete. However, it doesn't fully distinguish from the related system-certificate import (ise_openapi_cert_system_import) which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the category ('[Certificates]') and endpoint but provides no explicit when-to-use guidance or mention of alternatives. The deployment parameter references ise_list_deployments for selection, which gives some context. No exclusions or warnings about when NOT to use this tool versus system cert import.
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 transparency. The description only identifies it as an HTTP PUT operation, which implies a full replacement update, but doesn't disclose field-level replace-vs-patch semantics, whether partial updates merge or overwrite, permission requirements, or response behavior. For a mutation tool with zero annotation coverage, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the purpose and includes the endpoint for reference. It's efficient with no wasted words. The endpoint inclusion is marginally useful but slightly redundant with the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (PUT) with no annotations, no output schema, and a nested 'data' object parameter that isn't explained. The description doesn't address what the response contains, whether errors occur when the id doesn't exist, or the prerequisite of fetching the certificate first via trusted_get. For a complex update operation with a nested body, the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minimal parameter context beyond the schema—'id' is a path parameter for which certificate, and 'data' is the JSON body, but the description doesn't clarify what fields are needed in the data body for a trusted certificate update. With full schema coverage, baseline 3 is appropriate, though the description could add value by noting the body format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing trust certificate in the Cisco ISE trust store, naming the specific endpoint (PUT /api/v1/certs/trusted-certificate/{id}). The [Certificates] prefix groups it with cert tools, and the verb 'Update' with resource 'trust certificate' makes the action clear. It distinguishes reasonably from sibling tools like ise_openapi_cert_trusted_delete and ise_openapi_cert_trusted_import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used when a trusted certificate already exists and needs updating ('already present in the trust store'), which subtly differentiates it from import/create flows. However, it doesn't explicitly state when to choose this over import, delete, or get variants, nor does it specify prerequisites (e.g., whether the certificate must be listed via trusted_list first). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It reveals it's a mutation ('install') operation on a live ISE node, which implies potential service impact, but doesn't mention prerequisites (e.g., a hotpatch file must exist/be uploaded first), side effects (node restart?), whether the operation is asynchronous (likely given ISE's task model), or how to check status. For a state-changing operation on network infrastructure, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is a single concise sentence with the endpoint noted. The parameter descriptions are compact and information-dense. No wasted words. Could arguably include a bit more behavioral context, but what's present is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating infrastructure operation with no annotations, no output schema, and a nested 'data' object with zero field documentation, the description is incomplete. It doesn't explain return values/asynchronous task semantics, prerequisites (hotpatch must be uploaded), or the role of the 'data' body. The deployment parameter is well-handled, but the core operation semantics are under-specified. Sibling tools like ise_openapi_task_get exist for task tracking, but this isn't referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The deployment parameter description adds meaningful context ('name, slug, or number', 'Omit to use the only/default deployment', pointing to ise_list_deployments), which goes beyond schema. However, the critical 'data' parameter is only described as 'JSON request body' with no field-level detail about what hotpatch install requires, leaving the agent guessing. Baseline 3 for full coverage, with partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Trigger hotpatch installation') and resource ('on Cisco ISE node'), plus the exact API endpoint. It distinguishes it from sibling tools like ise_openapi_hotpatch_list and ise_openapi_hotpatch_rollback by specifying the 'install' action. The '[Patch]' prefix hints at operational context. It's clear, though it doesn't explicitly contrast with the similar patch_install sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description doesn't state when to use this tool versus alternatives, but the deployment parameter description provides useful context, explaining how to specify the target deployment and pointing to ise_list_deployments for choices. No explicit when-not-to-use guidance is given, and it doesn't clarify how this differs from the sibling ise_openapi_patch_install (hotpatch vs patch) beyond the name.
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. The description only states the endpoint and category tag. It does not describe the return value, whether this is a fetch (GET-like registration info retrieval) or mutation (registering a license), any authorization/permission requirements, or behavior on failure. As a licensing-related tool with no annotations, this is a meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with the category tag and endpoint. It's efficient and front-loaded. It could be considered slightly under-specified rather than verbose, but there's no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a license registration tool with a nested object parameter (data), no output schema, and no annotations. The description provides no explanation of the request/response payload structure, semantics of the operation (register vs view), or any behavioral details. For a tool with these complexity characteristics, the description is too thin to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema. The 'data' parameter is described as 'JSON request body' and 'deployment' has a detailed description with examples and a pointer to ise_list_deployments. The description adds no parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it handles '[Licensing] License - registration information' for the POST /api/v1/license/system/register endpoint. This is a specific verb+resource clearly identifying the operation. However, it mostly echoes the endpoint name without elaborating what 'registration information' entails for the tool, and doesn't distinguish itself from sibling license tools (smart_state, tier_state, eval, connection_type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use vs when-not-to-use guidance. It names the HTTP endpoint and category '[Licensing]', which implies context, but there is no guidance on when to use this vs the other license tools (smart_state_get, tier_state_get, eval_get, connection_type_get) listed as siblings. 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.
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 identifies the HTTP verb (GET) in the title context but doesn't disclose what happens for a non-existent name, authentication requirements, or what dictionary fields will be returned. For a read operation with no annotation coverage, minimal behavioral detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with the endpoint path embedded as reference. It's front-loaded with the purpose and includes the HTTP method. While minimal, every piece serves structure; the deployment parameter description carries the explanatory weight. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters fully documented in schema, no output schema (simple dictionary fetch), and no nested objects, the tool is relatively simple. The description is adequate but lacks detail on return value structure and edge-case behavior (e.g., 404 when dictionary not found). For a simple GET tool this is near-adequate but could clarify what a 'dictionary' entails in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The deployment parameter adds multi-deployment context with example values (name, slug, number) and pointers to ise_list_deployments, going beyond mere schema. This adds meaningful operational semantics beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'GET a dictionary by name' with the endpoint path, which clearly identifies the verb and resource. However, it doesn't distinguish this from its sibling ise_openapi_radius_dictionary_list, and the '[Policy: Network Access]' prefix is context rather than function. The phrase 'GET a dictionary by name' is functional but not rich enough to fully differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this retrieves a single dictionary by name but gives no explicit guidance on when to use this vs. the sibling list tool (ise_openapi_radius_dictionary_list) or when to prefer it over other OpenAPI dict tools. The deployment parameter provides some context but no when/when-not guidance.
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. 'Create' implies mutation, but the description doesn't state whether this requires specific administrative permissions, whether the operation is idempotent, what happens on duplicate policy set names, or what the response contains. For a write operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose and endpoint. It's front-loaded with the action. It doesn't waste words, though it embeds what appears to be raw API documentation text. Efficient, but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description would need to communicate what the response looks like — it doesn't. No annotations cover the safety/mutation profile. The 'data' parameter is a nested object that could benefit from example shape documentation beyond 'JSON request body'. For a create/mutation tool with a free-form nested payload, more contextual guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both 'data' (JSON request body) and 'deployment' (target deployment with format options and pointer to ise_list_deployments) are documented in the schema. The description adds no parameter semantics beyond the schema. Per the rubric, baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new policy set' with the specific resource (Network Access policy set) and HTTP method (POST). It clearly identifies the action and target. However, it doesn't distinguish itself from sibling create tools like ise_openapi_radius_policy_set_update or the tacacs_policy_set_create, though the 'radius' and 'Network Access' scoping provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via the REST endpoint path but provides no explicit when-to-use guidance or alternatives. It doesn't mention prerequisites, when a policy set should be created vs updated, or note that the data field requires a specific JSON structure. The deployment parameter guidance is helpful but that's in the schema, not the description.
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. The description states it's a 'GET' operation (read-only), which is useful, but provides no detail about error cases (e.g., invalid/nonexistent policy set ID), authentication requirements, rate limits, or what the returned attributes actually contain. For a read operation, this is a moderate gap but not severe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the endpoint path embedded. It's efficient but very terse—it reads more like an auto-generated stub ('[Policy: Network Access] Network Access - Get policy set attributes') than a thoughtfully written description. It's short enough to be scannable but misses opportunities to add value in that short space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with a simple GET-by-ID pattern, code coverage is 100% on parameters and there's no output schema requirement. The description is adequate for basic usage (fetch a policy set by ID), but given the absence of annotations and the complexity of picking the right RADIUS policy tool among many siblings (list, create, update, delete, get), the description could do more to orient the agent about which policy set type and context is targeted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (id as path parameter, deployment as target ISE deployment selector). The description adds essentially nothing beyond the schema for parameters. The deployment parameter has a rich schema description explaining name/slug/number options and pointing to ise_list_deployments. Baseline 3 is appropriate since the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[Policy: Network Access] Network Access - Get policy set attributes' with the HTTP verb 'GET' and target resource 'policy-set/{id}'. It clearly indicates a read operation for a specific policy set by ID. It doesn't explicitly differentiate from sibling tools like ise_openapi_radius_policy_set_list, but the GET-by-ID semantics are reasonably clear from the endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Get policy set attributes' which implies fetching a specific policy set's details, and the choice of '{id}' in the path implies you need a known ID (which would come from the list call). However, there's no explicit statement about when to use this vs. list/get alternatives, nor any exclusion guidance or context about when this specific API should be preferred.
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 full behavioral disclosure burden. It reveals it's a PUT update (implying mutation/overwrite), but doesn't state whether it fully replaces the existing definition, what partial vs full updates mean for omitted fields, whether permissions are required, or what happens on nonexistent names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, no wasted words. The [Repository] prefix categories the tool type. Could perhaps include more behavioral detail but is appropriately concise for what it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a nested 'data' object whose structure is undocumented. The description doesn't explain return behavior, error conditions, or whether update is full-replace vs merge. Sibling tools (create/delete/get) exist, making update semantics especially important to clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents name, data, and deployment params. The description adds the HTTP method and endpoint path for context. However, the critical 'data' parameter is only described as 'JSON request body' with no explanation of its expected structure or fields, which is a gap given this tool updates a repo definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it updates a specific repository via PUT /api/v1/repository/{name}. The verb 'update' plus 'definition of a specific repository' is specific. However, it doesn't differentiate from ise_openapi_repo_get or ise_openapi_repo_create beyond the verb, though the update intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for updating an existing repository definition but gives no explicit when-to-use vs alternatives (create/delete/get), no prerequisites (e.g., repo must exist), and no guidance on when to use this over other openapi repo 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals this is a POST (create) operation, which implies mutating state. However, it doesn't disclose the response format (no output schema), whether this is asynchronous, what happens on duplicate policy sets, or any authorization requirements. The HTTP method implied by 'POST' does convey the mutating nature, but richer behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description line is concise at one sentence, and the schema includes helpful detail for the deployment parameter. The parenthetical '[Policy: Device Admin]' is a small bit of categorization. The structure is efficient with no waste, though the parameter descriptions owe slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a nested object parameter (data) with no documented structure, no output schema, and no annotations. For a creation tool that lacks documentation of the required JSON body structure, the description is insufficient. The agent cannot know what fields the 'data' object needs without external knowledge. Sibling tools like radius_policy_set_create exist, but there's no guidance distinguishing them. More detail on the data payload and expected response is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (data and deployment) are documented in the schema. The deployment parameter has a helpful multi-value description ('name, slug, or number') and references ise_list_deployments. However, the 'data' parameter description ('JSON request body') is quite thin — it doesn't explain what the JSON body should contain, required fields, or structure for a TACACS policy set. The description itself adds no parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Device Admin - Create a new policy set' with the specific HTTP endpoint (POST /api/v1/policy/device-admin/policy-set). The verb 'Create' plus 'policy set' clearly identifies the action and resource, and while the name already says 'create' and 'policy_set', the '[Policy: Device Admin]' prefix and endpoint URL add useful context. It doesn't explicitly distinguish from sibling tacacs tools (like update/list/get) but the create verb is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. There's no mention of prerequisites, when creation is appropriate, or any exclusions. However, the deployment parameter description does explain when to omit it ('Omit to use the only/default deployment'), which offers some contextual usage guidance for that specific parameter. Overall, no when/when-not guidance 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states the operation (list) and endpoint but doesn't describe pagination behavior, response format, rate limits, or whether this returns all policy sets across deployments. The 'deployment' parameter behavior is only hinted at via the schema, not explained behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line stating purpose and endpoint. It's efficient and front-loaded, though it could be slightly more informative without bloat. Minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema to compensate for absence of return-value documentation. The tool is a list operation with 3 params but provides no information about what the response contains, how results are paginated, or what filters beyond page/size are available. For a policy set listing tool in a complex domain (TACACS/Device Admin), more detail would help the agent understand what it's retrieving.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'deployment' has a description; 'page' and 'size' lack descriptions). The description itself doesn't add parameter information. However, 'page', 'size', and 'deployment' are fairly self-explanatory given typical list APIs, and the deployment parameter has a solid schema description. Baseline 3 is reasonable but it doesn't compensate for the two undocumented params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Device Admin - List of policy sets' with the HTTP GET endpoint. It clearly identifies the verb (List) and resource (TACACS policy sets under Device Admin). It distinguishes from siblings like radius_policy_set_list by the 'TACACS' and 'Device Admin' scoping, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the API path but provides no guidance on when to use this vs the radius policy set list or the ERS-based tools. Usage context is implied by the name (TACACS vs RADIUS) but not explicitly stated. No exclusions or alternative recommendations are given.
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. The description states this is a mutating/setting operation, suggesting a state change, but doesn't disclose whether this persists across sessions, affects other callers, is reversible, or what the return/response looks like. For a state-mutation tool with zero annotation coverage, more behavioral detail would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the core purpose. Zero waste, no redundant restating of the tool name, and the sentence earns its place by adding the key qualifier about unnamed tool calls.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple state-setter with one parameter and no output schema. The description adequately covers the primary function. However, it could benefit from noting whether this is a per-session or persistent setting, which would matter given the absence of annotations. Still, for a single-parameter tool, the description covers the essential purpose reasonably well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter ('deployment' - Name, slug, or number to make the default). The description adds the semantic context that this parameter identifies the deployment to change. However, it doesn't clarify what formats are acceptable (name vs slug vs number) or how to reference the current default. The schema baseline of 3 applies since schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting which deployment is used by default when a tool call doesn't name one. This distinguishes it from related deployment tools (add/update/remove/list) and test_deployment. However, it doesn't explicitly state the resource target (e.g., 'sets the default deployment for this session/connection') or contrast with siblings like ise_add_deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It doesn't explain when one would set a default deployment versus passing an explicit deployment per call, nor does it reference sibling tools like ise_list_deployments or ise_test_deployment for context. The phrase 'used when a tool call does not name one' implies usage context but provides no explicit recommendations or exclusions.
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. It identifies this as a read/report tool ('[Report]'), implicitly signaling non-destructive behavior. However, it doesn't disclose return format, pagination behavior, or any read-time side effects. The report marker plus filterable-columns note adds moderate transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence followed by a column list. It's efficient and front-loaded with the report tag and purpose. The column enumeration is useful and earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report tool with a fully documented schema, the description is reasonably complete. It lists the filterable columns and declares the report purpose. However, it doesn't mention what output format to expect given there's no output schema, and doesn't clarify whether this represents a live or historical view. Adequate for the tool's simplicity but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are documented in the schema itself. The description mentions the filterable columns (ID, TIMESTAMP, USERNAME, etc.) which maps to what filter_column accepts, adding some context. However, it doesn't add semantics beyond the schema's own parameter descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a [Report] tracking accepted and denied AUP connections and lists filterable columns. The purpose is specific (verb 'Track' + resource 'AUP connections'). It doesn't explicitly distinguish from sibling report tools like ise_dc_view_radius_authentications, but the resource and title make the domain distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. It doesn't mention alternatives or exclusion conditions. Context implies it's a report view for AUP data, but no when-to-use guidance is provided for selecting it over other ise_dc_view_* report tools.
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 full burden. However, it doesn't disclose key behavioral traits: pagination defaults, whether this is read-only (implied by 'Report' but not stated), the meaning of 'view's time column' for days_back, or the relationship between filter_column/filter_value/filter_op. For a read tool with no annotations, this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose and then lists filterable columns, which is useful. However, the column list is somewhat long and would be better placed in the filter_column/filter_value parameter descriptions rather than the main description. The format is compact but mixes report-purpose detail with schema-redundant column enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 0 required, no output schema, and no annotations, the description does the minimum viable job. It lists filterable columns and explains the report scope, but for a data-reporting tool it doesn't describe return structure, row count limits, or the deployment targeting semantics clearly-enough beyond what the schema says. It's adequate but not fully self-sufficient for a complex query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all 7 parameters well with types, defaults, and descriptions. The description adds value by listing the actual filterable column names (ENDPOINT_POLICY_ID, MATCHED_POLICY_ID, etc.), which goes beyond what the schema's generic filter_column field conveys. This compensates well for otherwise generic parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a report tool for endpoint data collected by ISE, listing filterable columns. It distinguishes from siblings by the '[Report]' prefix and 'Endpoints Data' title, though it doesn't explicitly differentiate from the closely related ise_dc_view_registered_endpoints or ise_dc_view_profiled_endpoints_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool implies usage for querying endpoint data but provides no explicit guidance on when to use this vs. the many DC view sibling tools (registered_endpoints, profiled_endpoints_summary, endpoint_identity_groups). The deployment parameter does reference calling ise_list_deployments, which is helpful context, but there's no when/when-not guidance.
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 doesn't state whether this is a read-only operation, whether it requires specific deployment context, whether results are paginated by default, or what the output format is (columns, rows). There's no reference to the deployment parameter behavior that could affect results. For a query-style report tool with no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with a useful list of filterable columns. It's front-loaded with the purpose and avoids unnecessary prose. Could be slightly more structured but is appropriately compact for a report tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report/read tool with 100% schema coverage and no output schema, the description covers the core purpose and filter columns. However, it doesn't explain the relationship to deployments (the deployment parameter exists but no guidance on when it matters), nor does it clarify expected output shape. Given the tool's complexity (7 parameters, deployment targeting), a bit more context about result format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters well. The description adds value by listing the filterable columns (ID, NAME, IP_MASK, PROFILE_NAME, LOCATION, TYPE) which correspond to filter_column choices. However, the description doesn't add meaning beyond the schema for parameters like limit, order_by, days_back — the schema descriptions cover those. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a report tool that gives network device information configured in ISE, and lists the filterable columns. The verb 'Gives' with the resource 'network device information' is clear, and the implicit reference to 'network devices' differentiates it reasonably from siblings. However, it could be more explicit that this returns a list/report of devices and how it differs from ise_dc_view or ise_ers_list_networkdevice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's a reporting/view tool for network device inventory, which fits with the ise_dc_view_* family naming. It lists filterable columns which gives some usage context. However, it doesn't explicitly say when to use this vs alternatives like ise_ers_list_networkdevice or ise_ers_get_networkdevice (which also relate to network devices), nor does it mention exclusions or when-not-to-use.
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. The description is purely declarative about what's returned ('details of all the radius accounting records') and lists columns, but does not disclose the security/read-only nature, any quirks about record volume, deduplication, pagination, or how this differs from the '_week' variant. For a report tool with no annotations, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the [Report] classification and the resource name. The column list is dense but useful. No wasted words, though it could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description carries a heavier burden, but it does list the filterable columns and functions as a view/report tool with rich schema param descriptions. The main gap is the absence of any return-format or row-scope detail (e.g., whether all records or a bounded window), which is significant for a 'details of all' report. Decent but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters already have descriptions in the schema. The tool description adds the list of filterable columns (TIMESTAMP, VN, AUTHORIZATION_POLICY, FAILURE_REASON, etc.), which is genuinely useful for choosing filter_column values—this supplements the schema. However, this is baseline credit for high coverage; the description mostly repeats import already carried by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[Report] RADIUS Accounting' and states it provides details of all the radius accounting records, listing filterable columns. This clearly indicates a view/report tool returning accounting records. It doesn't explicitly distinguish from ise_dc_view_radius_accounting_week or radius_authentications siblings, but the resource ('radius accounting') and the [Report] tag are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a report/query tool but provides no explicit when-to-use guidance or exclusions vs. alternatives. It doesn't mention the related ise_dc_view_radius_accounting_week (which would be the natural comparison), nor when one should prefer this over the authentications or tacacs accounting tools. The [Report] tag gives mild context but no actionable guidance.
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 mentions 'performance oriented view' which hints at behavior but doesn't disclose what data is excluded/included, whether rows are aggregated, pagination behavior, or performance characteristics. For a data-view tool with no annotations, more behavioral context is needed beyond a vague 'performance oriented' tag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that conveys the report nature, time window, and filterable columns. It's reasonably front-loaded with the '[Report] RADIUS Accounting Week' tag. No wasted words, though the column list adds bulk that could arguably live in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-view query tool with 100% schema coverage and no output schema, the description provides a decent foundation: it names the report, states the 7-day window, and lists filterable columns. However, it doesn't explain return value shape/page size, distinguish from the non-week variant, or clarify time-based semantics (is 'week' rolling 7 days or calendar week). The complexity is moderate but the description leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 7 parameters (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column). The description lists the filterable columns which adds moderate value by informing which columns can be used with filter_column. However, the description doesn't explain column value formats (e.g., ACCT_STATUS_TYPE enum values, octet formats), so it doesn't go beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a Report view containing RADIUS accounting records for the last seven days, with a specific verb ('[Report]') and resource (RADIUS Accounting Week view). It lists the filterable columns. However, it doesn't distinguish itself from sibling ise_dc_view_radius_accounting (the non-weekly version), so there's some ambiguity about what 'week' adds beyond the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing/querying RADIUS accounting records from the last 7 days, and the schema documents filter/order/limit params well. However, it does not explicitly state when to use this over ise_dc_view_radius_accounting or the authentication views, nor does it state any exclusion criteria or alternatives.
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 lists filterable columns but does not mention whether this is a read-only operation, what the return format looks like, pagination behavior, or the max limit constraint (though 'limit' schema notes max 10000). For a report/query tool with zero annotation coverage, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact — a single sentence stating purpose and then a list of filterable columns. It's efficient and doesn't waste words. Could arguably be more structured (e.g., front-loading limit behavior), but as written it's appropriately sized and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report-view query tool with 100% schema coverage but no output schema and no annotations, the description covers the essential purpose and filterable columns. However, it lacks information about default behavior (e.g., what happens with no filters), the sort column default, and doesn't explain how filter_value/filter_column/filter_op interact together — though those are in schema. It's adequate but has clear gaps for a 7-parameter report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters already have descriptions in the schema. The main description adds the list of filterable columns (ORIG_CALLING_STATION_ID, CHECKSUM, TIMESTAMP, etc.), which maps meaningfully to filter_column usage. However, it doesn't add much beyond this — the schema already covers limit, order_by, deployment, and filter semantics. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[Report] RADIUS Authentications: This provides details of all the radius authentication records' with a clear verb (provides details) and resource (radius authentication records). It distinguishes from siblings like ise_dc_view_radius_authentications_week (weekly variant) and ise_dc_view_radius_authentication_summary (summary variant), though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the 'all records' report variant among several radius authentication tools, but doesn't explicitly state when to use this vs the _week or _summary siblings. The deployment parameter hints at multi-deployment handling ('Omit to use the only/default deployment'), but the main description body offers no clear guidance on when this tool is preferred over alternatives.
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 behavior. It labels this as a '[Report]' (implying read-only) and lists filterable columns, but does not disclose how results are returned, whether there are limits, whether the 'LEARNED_FROM' implies multi-source data, or any pagination/ordering behavior. For a data-view tool with no annotation safety hints, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-part statement (purpose + filterable columns) with no wasted words. It front-loads the purpose and immediately gives actionable column names. Concise and to the point, though slightly sparse in behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a fairly simple flat list tool, the description provides the core purpose and filterable columns but omits return format, ordering defaults, and interaction with days_back/limit semantics. For a moderately simple 7-param query tool this is adequate-verging-on-adequate; the missing behavioral detail slightly undercuts completeness but the column list is genuinely useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 7 parameters. The description adds the filterable column list (NAME, SGT_DEC, SGT_HEX, DESCRIPTION, LEARNED_FROM) which helps an agent know what to pass as filter_column. However, with full schema coverage the baseline is 3, and the description's added value beyond the schema's parameter docs is modest, so 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List and details of security groups' with a [Report] prefix, using specific verb+resource. It lists filterable columns (NAME, SGT_DEC, SGT_HEX, DESCRIPTION, LEARNED_FROM), which clarifies scope. It doesn't explicitly distinguish from sibling tools, but the dedicated view name plus column list reasonably differentiates it among the many ise_dc_view_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [Report] label implies it's a read-only data view, and the description gives filterable columns as usage hints. However, it doesn't explicitly state when to use this vs the generic ise_dc_view or ise_dc_query, nor when to prefer this over ise_ers_list_sgt/search_sgt for security group info. Usage context is implied but not explicitly compared to alternatives.
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 provided, the description carries the full burden of behavioral disclosure. It does not mention whether create is destructive/hazardous, whether it overwrites existing resources, what error conditions occur (e.g., duplicate resource names), or what the response format looks like. For a create/mutation operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with useful cross-references to ise_ers_get and the deployment listing tool. The description is efficient with no wasted words, though it could be structured slightly better by separating the main action from the guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description would need to explain return values, but it doesn't. The tool has a large enum of 70+ resource types and nested object parameters, making it complex. The description points to ise_ers_get for an example and acknowledges the data must match the resource schema, which partially compensates for the complexity, but a mutation tool with no annotations and no output schema should convey more about outcomes and risks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (data, resource, deployment) are documented in the schema. The description adds the helpful hint to provide JSON matching the resource schema, but otherwise the parameters are well-covered by the schema's own descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pattern: 'Create a new ERS object', which clearly states the action. It distinguishes from update/patch/delete siblings via the 'Create' verb, though it doesn't explicitly name the alternatives. The purpose is clear but relies on the tool name and sibling context rather than spelling out differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use ise_ers_get first to see an example payload, which is useful guidance for the create flow. However, it doesn't explicitly state when NOT to use this tool or name alternatives (ise_openapi_* create tools). The deployment parameter references ise_list_deployments, but overall when-to-use guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (get by ID) without describing any side effects, required permissions, error behaviors, or whether this is a safe read-only operation. For a tool in a security-focused ISE product, the lack of permission/auth context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero wasted words. It is front-loaded and immediately communicates the tool's purpose with no verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 'get by ID' resource tool, the description is minimally adequate. The tool is straightforward (2 params, 1 required, no output schema, no nesting), so the bare description covers the core use case. However, given the large sibling family of ERS tools with list/search/get variants, a brief note distinguishing this from list/search alternatives would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (the id parameter lacks a description). However, the tool name and description clearly indicate 'id' is the ANC policy ID to fetch, which the description adds meaning to. The deployment parameter benefits from a rich schema description. The description meaningfully orients the id parameter toward the ANC policy resource context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single ANC Policies object by ID' uses a clear verb-resource pattern and specifies the retrieval mechanism (by ID). It clearly distinguishes from sibling get tools targeting other resource types like downloadableacl or guesttype, but doesn't explicitly differentiate from the generic ise_ers_get or sibling ise_ers_get_ancendpoint beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives. The siblings include ise_ers_list_ancpolicy, ise_ers_search_ancpolicy, and generic ise_ers_get for the same ANC policy resource, but the description doesn't explain when to choose this specific 'get by ID' variant over the search or list alternatives.
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. 'Get' implies a read operation, which is reasonable. However, it doesn't disclose whether authentication/credentials are required, what happens if the ID doesn't exist (error vs null), or any pagination/result shape for a GET that returns a single object. It's a minimal but not misleading behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence. It's efficient and front-loads the key action. However, it could have used a bit more space to explain the id parameter format, but as-is it is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-object getter with 2 params and no output schema. The description conveys the core purpose adequately. Missing context: no information about how to obtain the ID (from list/search), and no mention of the returned object format. However, for a straightforward getter tool, the description is near-minimum-viable but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The deployment parameter is well-documented in the schema with valid formats and a reference to ise_list_deployments. However, the 'id' parameter has no description in the schema, and the tool description doesn't explain what format the ID takes or how to obtain it (e.g., from a list/search call). Given partial coverage, the description adds nothing beyond naming the param in purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Identity Groups object by ID' uses a specific verb (Get) plus a specific resource (Identity Groups object) scoped by ID. It clearly distinguishes from the list_identitygroup and search_identitygroup siblings, though it doesn't explicitly compare to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives like ise_ers_search_identitygroup or ise_ers_get_by_name. It doesn't state when you'd have an ID vs name to look up, or mention prerequisites. The schema's deployment param references ise_list_deployments, but the description itself offers no usage context.
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 full burden of behavioral disclosure. It only states 'List all ANC Policies. Paginated.' and doesn't describe what the response looks like, whether results are filtered/sorted, how pagination behaves (total counts, max pages), or side effects. For a read/list operation, the lack of response format or pagination semantics detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a lean two-sentence construction with zero wasted words. It's front-loaded with the core purpose. However, it's arguably under-specified rather than elegantly concise, but for a simple list operation the brevity is still acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple paginated list tool with 3 optional parameters and no output schema. The description covers the essence ('List all ANC Policies', paginated). Given its simplicity and self-explanatory params, the description is reasonably complete, though it could mention what fields/resource shape ANC policies return and whether filtering is supported beyond pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33%, meaning only the deployment parameter is documented in the schema. The description adds no parameter details; page and size are unnamed in the description. However, page/size are self-explanatory for a paginated list and deployment is well-documented in schema, so the description adds marginal value but doesn't severely hinder parameter understanding given the simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all ANC Policies. Paginated.' uses a clear verb+resource ('List ANC Policies') and notes pagination. It distinguishes from get/search variants among siblings (ise_ers_get_ancpolicy, ise_ers_search_ancpolicy) through the 'List' verb, though it doesn't explicitly contrast them. Slightly terse but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a list operation but provides no explicit when-to-use guidance or exclusions versus get/search siblings. Among siblings, ise_ers_get_ancpolicy and ise_ers_search_ancpolicy exist but no guidance differentiates when to use list vs get vs search. The deployment parameter schema hints at target selection but description doesn't elaborate usage context.
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 full behavioral disclosure burden. The description only mentions 'Paginated' but does not disclose what the response looks like, whether it returns all fields for every node, what the default page size behavior implies, or whether this is a read-only operation. For a list tool with zero annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. The description is front-loaded with the primary purpose followed by the pagination note. It is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 optional parameters and no output schema, the description is adequate but could be richer. The deployment parameter logic is well-documented in the schema itself, and pagination is noted. However, given the complexity of the ISE deployment concept (name/slug/number forms), the description relies heavily on the schema for deployment meaning, and there's no disclosure of result shape or potential large datasets beyond 'Paginated'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only the deployment parameter has a description). The deployment parameter has rich semantics in the schema itself. However, 'page' and 'size' parameters have no description beyond their defaults, and the description text does not add meaning to them beyond 'Paginated' in the description. Given that schema covers deployment well but only 1 of 3 params, the description adds minimal compensation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all ISE Nodes' with the verb 'List' and resource 'ISE Nodes'. It distinguishes from sibling list tools by the specific resource (node vs endpoint, downloadableacl, etc.), though it doesn't explicitly contrast with ise_ers_get_node or ise_ers_search_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Paginated' which implies usage context for large result sets. The deployment parameter description provides usage guidance about the target deployment and how to discover choices via ise_list_deployments. However, no explicit guidance on when to use this vs get_node or search_node is given.
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 does disclose that the tool 'Returns raw XML', which is a useful behavioral trait (the output format). However, it doesn't disclose whether this is a read-only operation, auth requirements, or what 'raw XML' means in terms of parsing expectations. The raw XML disclosure is creditable but the overall behavioral profile is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the category tag, verb, resource, and endpoint. The 'Returns raw XML' clause adds useful output context in minimal space. It's efficient with no filler, though slightly telegraphic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, 100% schema coverage, and no output schema, the description is somewhat adequate. The raw XML return note is useful since there's no output schema. However, for a monitoring/telemetry tool with no annotations, it could note that this is a read-only status call and clarify how the XML count is structured. It doesn't fully describe behavior but is not severely lacking for a simple parameterless-ish tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single deployment parameter, which handles the baseline. The description itself adds no extra detail about the deployment parameter, but the schema already documents it thoroughly including name/slug/number options and the call to ise_list_deployments. The description's mention of 'raw XML' hints at output, not parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the active session count for posture via a specific GET endpoint ('[Sessions] Get Active Session Count (GET /admin/API/mnt/Session/PostureCount)'). The verb 'Get' plus the specific resource 'Active Session Count' and the [Sessions] category make the purpose clear. It distinguishes from siblings like ise_mnt_posture_session_count vs ise_mnt_active_session_count, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description does not contrast this posture session count with sibling ise_mnt_active_session_count or ise_mnt_profiler_session_count to help an agent choose among the session-count tools. The deployment parameter is well explained in the schema, but no usage context or alternatives are given in the description itself.
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 provided, the description carries the full burden of behavioral disclosure. It does note it returns 'raw XML,' which is useful. However, it doesn't disclose that this is a read-only operation, that a MNT (monitoring) deployment may need to be configured/selected, or what the response structure looks like (e.g., session list format, field names). The XML disclosure is a plus but insufficient coverage overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys scope, endpoint, and return format. It's front-loaded with the tool's purpose. Slight waste: the 'GET /admin/API/mnt/Session/EndPointIPAddress/{ip}' is redundant with the endpoint reference but does provide useful locator info, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read-only query tool with no output schema, so the description should convey something about the expected result. The 'Returns raw XML' note is the main completeness element. With no annotations and no output schema, the description could more richly describe what a returned session record contains or potential error states, but for a straightforward data-fetch MNT tool, the current description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (ip and deployment) are documented in the schema, which sets a baseline of 3. The description adds the 'returns raw XML' context but adds no additional meaning about the parameters beyond what the schema provides. The deployment parameter's rich semantics (name/slug/number forms, default behavior) are already well-described in the schema, so the description doesn't need to repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the verb ('Get'), the resource ('full session details for an endpoint IP address'), the HTTP method/endpoint, and that it returns raw XML. It distinguishes reasonably well from the sibling tools ise_mnt_active_session_list and ise_mnt_session_by_mac/by_username/by_ip, though it doesn't explicitly differentiate from the very similar ise_mnt_session_by_ip which may be confusing to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies what this tool queries (an endpoint IP) but provides no explicit when-to-use vs alternatives guidance. Given the proximity of sibling tools ise_mnt_session_by_ip, ise_mnt_session_by_mac, and ise_mnt_session_by_username, it's clear this is the endpoint-IP variant, but the description does not explicitly state the distinction or when to prefer this over siblings.
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 states this is a GET (read) operation and that it returns raw XML, which is useful. However, it doesn't disclose whether invalid IP addresses cause errors, what the returned XML structure contains, rate limits, auth requirements, or any other behavioral traits beyond the raw-XML note. For a session-lookup read tool this is a modest gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the tool's purpose, the exact API endpoint, and the return format. It's efficient and front-loaded with the verb and resource. Minor waste is the 'Get Full SD' phrasing which is somewhat awkward but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple session-lookup tool with good schema coverage and no output schema, the description covers the essentials: what it does, the endpoint, and return format. However, no annotations exist, no output schema exists, and it doesn't clarify what 'Full SD' means or what the raw XML contains. It's adequate but leaves gaps around result interpretation and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (ipaddress and deployment) are documented in the input schema. The description adds no additional parameter semantics beyond what the schema provides—no format hints, examples, or syntax details for the IP address value. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full SD IPAddress Information via a specific API endpoint (GET /admin/API/mnt/Session/IPAddress/{ipaddress}) and returns raw XML. The '[Sessions]' prefix groups it with session tools, and the resource (IP address session data) is explicit. It's a specific verb+resource but doesn't distinguish it from siblings like ise_mnt_session_by_mac or ise_mnt_session_by_username beyond the IP address parameter in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for looking up session information by IP address, which distinguishes it from sibling session tools keyed by MAC, username, endpoint IP, or ID. However, there's no explicit when-to-use guidance, no exclusions, and no mention of alternatives. The deployment parameter does note calling ise_list_deployments for options, which is helpful context.
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 provided, the description carries the full behavioral disclosure burden. It does not say whether the tool requires an in-progress backup (error if none running), whether cancellation is immediately effective or asynchronous, what happens to partially-written backup files, or what the response contains. As a mutating operation with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that names the action, category, and underlying endpoint. It's front-loaded and has zero waste. Losing a point only because it could add brief behavioral context (e.g., error conditions) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutating action tool with no annotations and no output schema, the description is somewhat thin. The deployment parameter delegation to ise_list_deployments is a helpful pointer. However, for a cancel operation, critical context is missing: what happens if no backup is running, how to confirm cancellation success, and the contents of the required 'data' body. The tool is simple enough that this isn't severely deficient, but it leaves important behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the two parameters (data, deployment) are documented in the schema. The description adds no additional meaning about the 'data' field format or what the cancel operation requires in the request body. The deployment parameter is well-described in the schema itself. Baseline 3 is appropriate given high schema coverage, but the description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Cancel the running backup' via POST /api/v1/backup-restore/config/cancel-backup. It's distinct from sibling backup tools (backup_create, backup_restore, backup_last_status) by targeting a running backup operation. The [Backup & Restore] tag adds category context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies when to use it (to cancel a running backup), which is distinct from backup_create and backup_restore siblings. However, it doesn't explicitly state when NOT to use it or whether it requires an active backup to be present, nor does it reference checking backup_last_status first to confirm a backup is running. Guidance is implicit rather than explicit.
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 does state it's asynchronous (returns task ID, use task status API) which is useful behavioral context. However, it doesn't disclose that this is a mutation/creation operation with potential side effects (writes to backup store), that the encryption key is sensitive, whether the operation is destructive to existing backups, or idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that packs in purpose, required inputs, return value, and follow-up guidance. Efficient use of space with the endpoint reference appended. Not overly verbose, though it could benefit from line breaks for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, it reasonably covers the purpose, required inputs, and async workflow. The endpoint reference and task-status handoff advice add operational value. However, it lacks details on the exact data body schema, error/validation behaviors, and security implications of handling encryption keys, which is notable for a backup operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'data' parameter (JSON request body) and 'deployment' (target ISE deployment). The description indicates backup name, repository name, and encryption key are expected inside the data body, adding meaning beyond the generic schema. However, it doesn't specify the exact JSON structure/field names for these items in the data object, leaving some ambiguity about nested content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it takes a config DB backup now, specifying the required inputs (backup name, repository name, encryption key) and that it returns a task ID. The verb 'Take...backup' is specific and identifies the resource. It doesn't explicitly distinguish from sibling backup tools like ise_openapi_backup_schedule_create or ise_openapi_backup_restore, but 'config backup now' differentiates from scheduling/restore reasonably.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies immediate backup creation vs. scheduled backups (sibling ise_openapi_backup_schedule_create), and points to the Task Service status API for polling. However, it doesn't explicitly state when to use vs. not use this tool, prerequisites (repository must exist), or alternatives. Some guidance given via the POST endpoint reference but no explicit exclusions.
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 full burden. It's a read operation but this isn't explicitly disclosed, nor is it stated as non-destructive. There's no mention of whether it requires authentication, what happens if no backup exists, or whether results are cached. The endpoint path hints at the operation but doesn't disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line with a domain prefix and endpoint. It's front-loaded with the category label. However, it's slightly under-specified — it could benefit from one clarifying sentence about the response meaning or param behavior without being padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-read tool with no output schema and few params, the description adequately conveys the core action. It lacks explicit non-destructive framing, pagination semantics, and when-to-use guidance relative to backup siblings. Given the moderate complexity of the Backup & Restore tool family, it's borderline adequate but has clear documentation gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate for the page, size, and deployment params. The deployment parameter has rich schema documentation (name/slug/number, omit for default). However, page and size params have no schema descriptions and the tool description doesn't explain their role either — a gap. The deployment description is strong enough to mostly compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gives the last backup status via the explicit GET endpoint. The [Backup & Restore] prefix and endpoint path add domain context. It distinguishes from backup-related siblings like create/cancel/restore by focusing on reading status, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking the most recent backup status but doesn't explicitly say when to use vs. alternatives. There's no guidance on exclusions or when not to use it. Siblings like ise_openapi_backup_create and ise_openapi_backup_cancel suggest a workflow relationship that isn't stated.
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 full burden for behavioral disclosure. However, it says nothing about mutation vs. read-only, pagination behavior, return format, or any side effects. The tool name ending in '_list' and the description's 'Get list' wording imply a read operation, but that assumption is not explicitly stated, and no details about result size limits, paging defaults, or output structure are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the prefix and endpoint reference. It front-loads the essential purpose. It's efficient with no filler, though it errs on the side of being too terse given the other gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain more. It's a relatively simple list operation with 3 free parameters and no required fields, so the complexity is low. The description is arguably adequate for a list operation but deserves more given zero annotations and zero output schema, particularly around pagination and return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, with only the deployment parameter having a description (which is rich and helpful, including name/slug/number formats and a pointer to ise_list_deployments). The page and size parameters have no descriptions. Description adds nothing beyond the schema for page/size. Baseline is 3 given partial coverage; the deployment param is well-documented in the schema itself, and the description adds no additional param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get list of all trusted certificates' with a specific resource (trusted certificates) and a clear verb (get list). It includes the API endpoint path. While it doesn't explicitly distinguish from sibling tools, the '[Certificates]' prefix and 'trusted' qualifier differentiate it from other cert tools like ise_openapi_cert_system_list and ise_openapi_cert_csr_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only listing use case (get list of trusted certificates), but provides no explicit guidance on when to use it vs. the trusted_get/delete/update/import siblings. No exclusions or alternatives are named. The purpose context is fairly clear that this is the listing operation among the trusted-cert cert family, but no explicit direction is given.
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 does not disclose that this is a safe read-only operation, what the response structure looks like, pagination behavior beyond the existence of page/size params, or any potential errors. For a list tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose efficiently with no fluff. The endpoint URL is useful reference. It's appropriately sized for a simple list operation, though the deployment parameter guidance lives in the schema rather than the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description provides minimal behavioral context but is adequate for a straightforward read operation. The 33% schema coverage means the page/size parameters lack documentation. The tool is relatively simple (list operation, no required params), which lowers complexity, but it could benefit from mentioning pagination or filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — only 'deployment' has a description. That parameter description is genuinely helpful, explaining the accepted formats (name, slug, number) and the default behavior. However, 'page' and 'size' have no description, and the tool description adds nothing about them beyond their existence in the schema. The description partially compensates but doesn't fully cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve the list of all the node groups' uses a clear verb+resource, indicating a list/read operation on node groups within a deployment. The '[Deployment]' prefix and endpoint URL add helpful scoping. It is somewhat distinguishable from siblings like ise_openapi_deployment_node_list, though it doesn't explicitly differentiate between node groups and nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read/list context but provides no when-to-use guidance or exclusions. There are no alternatives named. The parameter description for 'deployment' does add useful selection guidance (omit for default, call ise_list_deployments for choices), which helps with usage, but the tool-level description itself lacks explicit usage context.
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 full burden for behavioral disclosure. The 'Create' action implies mutation, but the description doesn't disclose whether this is safe, what gets affected, whether it's reversible, or authentication requirements. It only provides the HTTP endpoint. For a write operation with zero annotation coverage, this is insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the category prefix [Policy: Network Access] and endpoint reference. It's efficient and the deployment parameter in the schema provides useful front-loaded guidance. Very little waste, though the endpoint URL formatting is a bit verbose for the tool name that already conveys this.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a nested 'data' object parameter (no output schema, no annotations), the description could do more. The 'data' parameter is just 'JSON request body' which is vague — what fields does an authentication rule require? The nested object nature of data means the agent would need additional context to construct a valid request. The category prefix and policy context help, but the data structure is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters (id as path param, data as JSON body, deployment for target). The deployment parameter gets additional useful context in the schema itself (explaining name/slug/number formats and pointing to ise_list_deployments). However, the description adds no param semantics beyond the endpoint path showing that {id} is the policy set id. The schema already carries the weight here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create authentication rule' with the endpoint POST /api/v1/policy/network-access/policy-set/{id}/authentication, which clearly identifies the verb+resource+action. It distinguishes from siblings like ise_openapi_radius_authentication_list (which lists) and ise_openapi_radius_authentication_create (creates). However, it doesn't elaborate on what constitutes an authentication rule beyond the basic endpoint reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear (creation within a policy set), and the path parameter {id} implicitly indicates the policy set context. However, there's no explicit guidance on when to use this vs alternatives, no prerequisites mentioned (e.g., needing to find the policy set id first via ise_openapi_radius_policy_set_list), nor any exclusions or warnings. Usage is implied but not directly stated.
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 reveals this is a GET/read operation but doesn't describe the response shape, pagination, whether an empty rule set is possible, or the relationship/cascade behavior between local exceptions and their parent policy set. For a read operation with no annotations and no output schema, more behavioral context would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with useful metadata prefix and endpoint path. No wasted words. It could be slightly more informative but remains appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a straightforward GET retrieval tool with 2 well-documented parameters and no output schema, the description is adequate but thin. It doesn't describe the response data, and given the sibling tool for global exceptions exists, a brief note on how local vs global exceptions differ would improve completeness for proper tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters ('id' as path parameter, 'deployment' with helpful guidance on formats). The description itself adds nothing beyond the schema for parameters, which is acceptable since the schema is complete. The deployment parameter's format hint (name/slug/number) and fallback to default is genuinely useful context in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get local exception rules' with a specific verb and resource, and includes the exact API endpoint (GET /api/v1/policy/network-access/policy-set/{id}/exception). It distinguishes 'local exception rules' from the sibling tool 'ise_openapi_radius_global_exception_list' through the 'local' qualifier, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes this is for '[Policy: Network Access]' and the tool name indicates RADIUS exception listing. It implies when to use it (to get local exception rules for a specific policy set) but doesn't explicitly state when NOT to use it versus the global exception list sibling or any alternatives. The deployment parameter guidance is good but that's schema helper text.
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 behavioral burden. While the '[Report]' tag implies read-only, the description does not explicitly state it's non-mutating, nor does it describe pagination/limit behavior, default filtering semantics, deployment targeting requirements, or how the days_back time column works. The deployment parameter's behavior is only explained in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, a single sentence that states purpose, and the column list is useful. It is efficiently sized. Slight improvement possible by being more explicit about read-only nature and sibling differentiation, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with good schema coverage and no output schema, the description provides the filterable columns which is valuable. However, the tool is one of many endpoint-identity-related sibling tools, and the description doesn't clarify what distinguishes this report view from the ERS identity group tools or from ise_dc_view_endpoints_data. The behavioral transparency gap (no explicit read-only statement, deployment targeting ambiguity) also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 7 parameters thoroughly (limit defaults, filter operators, deployment name/slug/number format). The description adds the list of filterable columns (ID, NAME, DESCRIPTION, CREATED_BY, CREATE_TIME, UPDATE_TIME, STATUS), which is genuinely useful beyond the schema by telling the user which columns exist and can be filtered/sorted. This adds meaning the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a report tool that provides details of endpoint identity groups, and lists the filterable columns. It identifies the resource (endpoint identity groups) and mode (report/view). However, it does not explicitly distinguish this from siblings like ise_ers_list_identitygroup or ise_dc_view_endpoints_data, though the '[Report]' prefix and view naming partially separate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description signals this is a read/report operation and lists filterable columns, implying it's for querying endpoint identity groups. However, it does not explicitly state when to use this versus the ERS-based identity group tools (ise_ers_list_identitygroup, ise_ers_get_identitygroup) or other DC view tools. 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.
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 lists the filterable columns and parameter defaults (limit 100), which gives some behavioral context. However, it doesn't disclose pagination behavior beyond the limit default, what happens on empty results, or any performance implications of querying a system-health view. The '[Report]' prefix hints at read-only behavior, but this is weak given zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a column enumeration, which is compact and efficient. It front-loads the purpose and provides the key filterable fields in a compact list. No wasted words or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report/view tool with a simple parameter set and no output schema, the description is moderately complete. The health-metric scope, filterable columns, and deployment targeting are covered. However, for a tool with zero annotations, it could benefit from stating this is a read-only monitoring query, clarifying what the output rows represent (per-node timestamped snapshots), and any limitations. It's adequate but not rich given the absence of annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are already documented. The description adds value by listing the filterable columns (TIMESTAMP, ISE_NODE, CPU_UTILIZATION, etc.), which directly informs how filter_column could be used. For the deployment parameter, the description tells users to call ise_list_deployments to see choices. The description names the data domain but doesn't extend parameter semantics much beyond what the schema provides, though the column list is a useful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'System Summary' report tool displaying system health information like CPU utilization, storage utilization, CPU count. The '[Report]' prefix and explicit list of filterable columns make the purpose clear. It doesn't explicitly distinguish itself from sibling dc_view tools, but the '[Report] System Summary' framing and explicit health-metric focus makes the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is framed as a '[Report]' and provides the health-metric context, implying this is for monitoring system state. However, it doesn't explicitly state when to use this vs alternatives (e.g., other dc_view_* tools for authentication/accounting data), nor does it mention exclusions. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It's a read operation (get), but the description doesn't state what happens if the ID doesn't exist, whether deployment targeting requires the deployment param, or any default behavior. It adds minimal behavioral context beyond the fact that it retrieves a single object. There is no contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. It names the tool's function clearly and compactly. Nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-object get operation with only 2 parameters (one required), the description is reasonably adequate. However, without annotations and no output schema, it could add value by noting error behavior or typical response structure. The deployment parameter is well-documented in the schema, which contributes to completeness. Overall it's adequate but leaves some behavioral gaps around error handling and the undocumented id parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% - the id parameter is undocumented in the schema while deployment is well-described. The description itself identifies 'id' as the lookup key ('by ID') which adds some meaning. However, with one parameter completely undocumented in both schema and description, the tool doesn't fully compensate. The description adds the crucial semantic that 'id' is the object identifier for lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single LDAP Identity Sources object by ID' clearly states the verb (get), the resource (LDAP Identity Sources object), and the selection mechanism (by ID). It distinguishes from siblings like ise_ers_search_ldap and ise_ers_list_ldap through the explicit 'by ID' qualifier. It's concise and specific, though it doesn't mention the deployment parameter dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (fetching one specific LDAP identity source when you know its ID) but doesn't explicitly contrast with the 'search' variant for when you don't know the ID, nor does it note when to use list vs get. The schema's deployment parameter does provide context on targeting specific deployments, but no exclusions or alternatives are stated in the description itself.
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. The description states the read operation but doesn't disclose what happens with an invalid/nonexistent ID (does it 404? raise an error?), whether the response format is consistent across node types, or any specifics about what fields are returned. For a get operation with no annotation coverage, this is notably thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys purpose without excess. The deployment parameter's detailed explanation lives in the schema where it belongs. No wasted words, appropriately minimal for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-resource get with 2 params and no output schema, the description is reasonably adequate. However, the lack of behavior specification (error handling, response shapes) given zero annotations and no output schema means the agent has limited expectations about what will happen. The deployment parameter guidance compensates partially, making this acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% - the 'deployment' parameter is well documented with name/slug/number examples and instruction to call ise_list_deployments. The 'id' parameter has no schema description but 'by ID' in the tool description gives basic context. The deployment parameter is thoroughly explained, adding substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single ISE Nodes object by ID' clearly states the verb (get), resource (ISE Nodes object), and the identifier key (by ID). It distinguishes from siblings like ise_ers_list_node (which fetches all nodes) and ise_ers_search_node (which searches), though it does not explicitly name those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single node by ID, but provides no explicit guidance on when to prefer this over ise_ers_list_node or ise_ers_search_node. The deployment parameter description does add useful context ('Omit to use the only/default deployment. Call ise_list_deployments to see the choices'), but overall the when-to-use vs alternatives is only implied, not explicit.
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 full burden for behavioral disclosure. "Paginated" hints at paging behavior via page/size, but the description doesn't disclose whether this is a read-only operation, whether results are ordered/deduplicated, what fields are returned in each item, or how the API handles edge cases like zero results or oversized pages. For a resource-listing tool with zero annotation coverage, this is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste. Every word earns its place—"List", "all Active Directory", and "Paginated" all convey distinct, useful information. No fluff, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a resource-listing tool with a simple signature and no output schema, the description is reasonably adequate but could go further. It's a list operation likely returning straightforward data, so it doesn't strictly need extensive behavioral detail. However, given zero annotations and the presence of a deployment parameter affecting which ISE instance is queried, slightly more context (e.g., default deployment behavior) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, meaning two of the three parameters (page, size) have no descriptions in the schema. However, their names are self-explanatory (page number, page size), and the description's "Paginated" note reinforces their purpose. The deployment parameter is well documented in the schema. Given the parameters are simple and conventional, the marginal value added by the description is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List all Active Directory. Paginated." has a specific verb (list), specific resource (Active Directory), and notes pagination. It's clear what it does. However, it doesn't explicitly distinguish itself from sibling tools like ise_ers_get_activedirectory or ise_ers_search_activedirectory, though the list vs get vs search naming convention provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or alternatives. However, the naming convention (list vs search vs get) and the deployment parameter description partially guide usage. The deployment parameter's description references ise_list_deployments as an alternative/supporting call, but there's no explicit statement of when to prefer list over get/search for Active Directory specifically.
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. It discloses the pagination behavior ('Paginated') which is useful, but doesn't mention the 'all' semantics beyond that, default page/size behavior, or what the response structure looks like. The deployment parameter behavior is explained in the schema, not the description. Reasonable minimal transparency for a read/list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded: 'List all Security Group ACLs (SGACLs). Paginated.' Every word earns its place with the acronym expansion being useful. Efficient but perhaps too terse—no wasted words, but also could have added a sentence on usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema and no annotations. For a complex ecosystem with 100+ sibling tools, the description is adequate but minimal. The pagination hint and resource scope are the key details. The absence of any mention of deployment behavior (beyond schema), filtering options, or result ordering leaves some gaps, but for a straightforward list operation the completeness is borderline acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (deployment is documented, page and size are not). The description adds the 'Paginated' framing which implies page/size usage. However, the description itself doesn't explain page/size semantics (defaults of 1 and 100 are in schema but with no description). The deployment parameter has a thorough schema description. The description adds marginal value but doesn't fully compensate for the undocumented page/size parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Security Group ACLs (SGACLs). Paginated.' with a specific verb (List), specific resource (Security Group ACLs), and a key scope qualifier (all + paginated). It doesn't explicitly distinguish from sibling tools, though the sibling set has a separate ise_get_sgacl and ise_search_sgacl which contextually differentiates list from get/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides 'Paginated' as a usage hint but offers no guidance on when to use this tool vs alternatives. With many sibling tools available (ise_ers_list_*, ise_ers_search_*, ise_ers_get_*), there's no explicit statement about when to choose this over ise_ers_search_sgacl or generic ise_ers_list. No exclusions or alternative tool mentions.
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 is a search operation implied to be read-only, but the description does not state pagination behavior, return format, whether filter expressions are validated, or what happens on no results. For a search tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It is appropriately sized for its purpose, though it could add a brief note on filter expression format without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a filtered-list search tool with 5 parameters, no output schema, and no annotations. The description is minimal but covers the essential purpose. It does not explain the ERS filter expression syntax, which is a meaningful gap for a search tool, nor does it describe what the result set looks like. For a moderately complex tool this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate. The description mentions 'filter expressions' generally but does not detail the filter parameter syntax or the other params (page, size, sort). However, the deployment parameter in the schema is well documented with concrete examples ('RADIUS Only', 'radius-only', '1'), which handles that portion. The overall semantic clarity is adequate but the filter expression details are left to the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search/filter REST ID Stores with ERS filter expressions' uses a specific verb (Search/filter) and names the resource (REST ID Stores), clearly distinguishing it from sibling list/get variants (ise_ers_list_restidstore, ise_ers_get_restidstore). It lacks a bit of detail about what a REST ID Store is, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching/filtering rather than listing all or getting a single item, which differentiates it from siblings. However, it does not explicitly state when to use this vs list/get, nor explain the filter expression syntax or format. The schema does document the deployment parameter with helpful usage guidance (naming formats, omitting for default).
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 full burden. It doesn't disclose what the export returns (file? base64? format like PEM/PKCS12?), whether a passphrase is required for private keys, authentication requirements, or side effects. The endpoint path is given but behavioral details about the export output format are absent, which is significant for an export operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the operation and endpoint. It's front-loaded with the purpose. No wasted words, though it could be slightly more generous with behavioral detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex operation: a POST export with a nested 'data' object and deployment targeting. There's no output schema to explain return format, no annotations, and the nested 'data' object is opaque. Given the sibling set includes related cert operations (get, list, delete, import), the description could clarify what distinguishes an export from a get, and what artifact the user receives. The deployment logic adds complexity that the description handles, but the overall completeness for a write/export operation with unknown output format is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for both data (JSON request body) and deployment (target deployment with examples). The deployment parameter is well-explained with format examples and a reference to ise_list_deployments. However, the 'data' parameter that presumably contains the certificate ID is just described as 'JSON request body' with no schema of its fields, so the description adds no detail about what goes inside it. The description mentions 'certificate ID' but the parameter semantics for the crucial data object remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('export a system certificate') with a specific resource (system certificate) and the endpoint (POST /api/v1/certs/system-certificate/export). The [Certificates] prefix helps categorize it among siblings. It doesn't explicitly distinguish from siblings like import/list/get/delete, but the verb 'export' and resource scope are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to export a system certificate by ID. The deployment parameter description provides useful guidance on how to select a target deployment and references ise_list_deployments for choices. However, it doesn't explicitly state when NOT to use this tool versus alternatives like ise_openapi_cert_system_get (which retrieves but doesn't export), nor what format the export produces.
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. The description only mentions the HTTP method (GET) and endpoint, but says nothing about what the returned data contains, error behavior for non-existent repos, permissions/authentication requirements, or whether the 'deployment' parameter affects behavior. This is a read operation but that's not even explicitly stated beyond the GET verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence in the description is efficient. The deployment parameter's schema description is detailed but appropriate. No fluff or redundancy. The '[Repository]' prefix adds organizational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-name tool with two parameters and 100% schema coverage, this is reasonably complete. The schema's deployment parameter guidance is thorough. However, without annotations or an output schema, the description could add more value by mentioning what data is returned. Given the tool's simplicity, it's borderline adequate but could benefit from noting error/not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description's name parameter ('Path parameter name') and deployment parameter (with detailed guidance referencing ise_list_deployments) are actually quite helpful. The 'deployment' parameter description in the schema is rich and well-written, covering how to specify a deployment and pointing to a sibling tool for choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a specific repository' with a clear verb (Get), resource (repository), and the HTTP endpoint. It distinguishes from sibling ise_openapi_repo_list (which would list all) by using 'specific'. However, it doesn't clarify what a 'repository' is in the ISE context or what distinguishes it from the many other Get* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clearly a single-item retrieval by name, which is implied by the tool name and 'Get a specific'. However, no explicit when-to-use vs alternatives guidance is given, and no mention of when to use list vs get. The sibling ise_openapi_repo_list provides an implicit alternative but no explicit direction.
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. The description lists the exact filterable columns, which is useful. However, it doesn't disclose the report's time scope behavior, whether results are limited, ordering, or pagination characteristics beyond what the parameters already imply. The column list provides transparency but behavioral details (return limits, paging) are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a column enumeration. It's front-loaded with the purpose and efficiently lists the data columns. The column list is somewhat long but useful and not redundant. No padding or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a view/query tool with 7 parameters and no output schema. The description lists available columns and provides the 'Report' framing, which is helpful. However, it doesn't explain what a default query returns (e.g., default filtering, sort order, whether it returns recent logins only), nor typical use case. The days_back parameter references 'the view's time column' without clarity on which column that is. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 names the filterable columns, which adds value by telling the agent what columns are available to filter/order on. However, it doesn't add semantics beyond what parameters already document — the columns list helps but is supplementary. No additional parameter context like valid values or example formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a report giving data about administrator logins to ISE, and lists the specific columns available. It identifies itself as a '[Report]' which helps distinguish it from other ise_dc_* views. However, it doesn't explicitly contrast with sibling tools like ise_dc_view_change_configuration_audit or other views, so the differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies this as a report of admin login data but doesn't specify when to choose it over alternatives. There's no guidance on typical use cases (e.g., security auditing) or distinctions from other view tools. The '[Report]' prefix gives some context but no explicit when/when-not guidance.
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 reveals this is a report of CoA log events but does not explain pagination behavior beyond schema defaults, whether the deployment parameter can select among multiple ISE deployments, output shape, or any side effects (though read-only is implied by '[Report]'). The deployment parameter behavior (name/slug/number, fallback to default) is described only in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose and then lists filterable columns efficiently. No wasted words, but the column list could arguably be trimmed since they map to filter_column enumerated values. Still, the format is appropriately sized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered report view tool with 100% schema coverage and 7 parameters (0 required), the description covers the core concept adequately. However, since there is no output schema and no annotations, the description could do more to describe what COA events represent, how they differ from threat events (sibling tool), and typical troubleshooting use cases. It's sufficient but not rich, given no annotations and no output schema to lean on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are documented in the schema. The description adds value by listing the filterable columns (LOGGED_AT, COA_EVENT_ID, etc.) that map to filter_column choices, and by noting the input source ('threat events from various adapters'). However, it doesn't clarify format details for filter_value or order_by values beyond the schema, so this is at the schema-heavy-work baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Log of change of authorization issued based on threat events received from various adapters' which specifies the verb (view/report), resource (CoA events), and domain. It lists the filterable columns that make it distinguishable from other ise_dc_view_* sibling tools. The '[Report]' prefix reinforces it's a read-oriented data center view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists filterable columns which implicitly tells agents which columns can be used for filtering, and the 'various adapters' context helps. However, it does not explicitly state when to use this tool vs alternatives like ise_dc_view_threat_events or ise_dc_view_radius_authentications, nor does it give exclusions or clear use-case guidance.
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 disclosure burden. It properly labels the tool as a read-only '[Report]' and indicates the 'aggregate view' nature. However, it doesn't disclose what 'aggregate' means in terms of grouping/behavior, whether results are limited, or pagination/return behavior. The report classification and aggregate characterization give moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that identifies the tool type ([Report]), its purpose, and lists filterable columns. It's front-loaded with the verb phrase and report categorization. No wasted words, though the column enumeration is somewhat lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered-report tool with no annotations and no output schema, the description is adequate but not rich. It explains the purpose, available columns, and implicitly the filtering capability via the listed columns. However, it doesn't describe the output/return format, what the 'aggregate' grouping looks like, or how this relates to the sibling weekly/non-summary RADIUS view tools. The 7 parameters are well-documented in schema, which compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 itself adds no parameter-specific meaning beyond listing filterable columns, but the schema fully describes all 7 parameters (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column). The deployment parameter description is notably rich, explaining name/slug/number formats and pointing to ise_list_deployments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays an aggregate view of RADIUS authentications and lists the filterable columns. It's marked as a [Report], distinguishing it as a read-only aggregate view. It distinguishes itself from sibling tools like ise_dc_view_radius_authentications by indicating this is a 'summary' aggregate, though it could more explicitly contrast with the non-summary RADIUS views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing RADIUS authentication summaries with filtering, but it doesn't explicitly state when to choose this over sibling tools like ise_dc_view_radius_authentications, ise_dc_view_radius_authentications_week, or ise_openapi_radius_authentication_list. The 'aggregate view' phrasing hints at distinction but doesn't name alternatives or exclusions explicitly.
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 provided, so the description carries the burden. 'Returns raw XML' is a useful behavioral disclosure indicating the output format. However, it doesn't state whether this is a read-only operation, what happens for unknown MAC addresses, whether it requires special privileges, or whether the returned XML structure varies. For a read operation with no annotations, some disclosure exists ('raw XML') but richer context (e.g., behavior on miss, volume/size of response) would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single compact sentence with category prefix, endpoint path, and output format disclosure. No filler or redundancy. The category [Sessions] is front-loaded, and the REST path provides precision. Could add a sentence on when to use it but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read tool with 2 params (both in schema at 100% coverage), the description is mostly adequate. But with no output schema, no annotations, and no description of return structure beyond 'raw XML', the agent gets limited sense of what to do with the response. MAC format expectations and behavior on unknown addresses are missing. Adequate but not rich for a session-inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters. The description adds no parameter-level semantics beyond the schema — it doesn't clarify MAC format expectations (e.g., with/without separators, case), which would be genuinely useful for a mac parameter. With full schema coverage, baseline is 3, and the description doesn't push beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Get Full Session Information for MAC Address' with explicit REST endpoint and category prefix '[Sessions]'. Distinguishes from siblings like ise_mnt_session_by_username/by_ip/by_endpoint_ip by specifying MAC Address lookup. Loses a point because 'Full Session Information' is somewhat ambiguous about what data is returned beyond the raw XML disclosure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [Sessions] category and MAC-address-specific name imply usage but no explicit when-to-use guidance or exclusions are given. The deployment parameter references ise_list_deployments for choosing deployments, which is helpful context. However, there's no differentiation from sibling session tools like ise_mnt_session_delete_by_mac, ise_mnt_session_by_username, or ise_mnt_active_session_list beyond the name itself.
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 and schema carry the burden. The description marks it [DESTRUCTIVE] and the schema elaborates on the confirm flag and server-side operator requirement, which provides meaningful behavioral disclosure. However, it doesn't state irreversibility, side effects on related session data, or what happens on failure, so depth is somewhat limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single-sentence description backed by a rich, well-structured schema with descriptive parameter text. The [DESTRUCTIVE] and [Sessions] tags front-load key context efficiently. No wasted words, though it could arguably add a note on irreversibility without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation with no output schema, so the description should compensate. It names the endpoint and return format (raw XML) but doesn't describe the response structure per success/failure, nor side effects on related session records. The confirm/deployment parameters are thoroughly documented in schema, and sibling deletion by MAC exists but isn't cross-referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are documented in the schema itself. The description adds the endpoint context and return format. The confirm parameter's semantics are well described in the schema (requires true for destructive op, operator allowlist). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it deletes a session record by Session ID, names the exact HTTP endpoint, and notes it returns raw XML. It's specific about verb+resource+scope. However, it doesn't explicitly distinguish from the sibling ise_mnt_session_delete_by_mac beyond the identifier type implied in the name, but the Session ID path parameter in the endpoint URL makes the resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies destructive usage via the [DESTRUCTIVE] tag and the schema adds strong guidance about the confirm flag and operator-level allowlist (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). But the description itself doesn't provide explicit when-to-use or when-not-to-use context beyond the destructive indicator, and doesn't reference alternatives like ise_mnt_session_delete_by_mac for MAC-based deletion.
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 should carry the behavioral burden. The description names the HTTP endpoint (GET /api/v1/certs/system-certificate/{hostName}/{id}) which is transparent about the operation. However, it doesn't disclose what the response looks like, whether it returns the full cert chain, or any security/permission requirements for accessing system certs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that packs the resource scope, the specific verb, and the endpoint. It's efficient with zero filler. The '[Certificates]' category prefix helps with navigation. Slightly more context could be warranted but nothing extraneous is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-item GET with 100% schema coverage and no output schema, the description is mostly adequate. However, it lacks any note about return format, what the certificate data contains, or relationship to the delete/import/export sibling tools. Given the simplicity of the tool, this is acceptable but leaves room for more helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond the schema—it references hostName and id in the endpoint path, and the deployment parameter has rich schema guidance (pointing to ise_list_deployments). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get system certificate of a particular node by ID' with the specific verb (Get) and resource (system certificate of a node). It's distinguished from siblings by the '[Certificates]' prefix and 'system-certificate' specificity, though it doesn't explicitly differentiate from ise_openapi_cert_system_list/delete/import/export siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (GET a specific certificate by ID on a host), and the schema's deployment parameter adds guidance by referencing ise_list_deployments. However, there's no explicit when-to-use vs alternatives statement, no exclusion criteria, and no mention of when to use the list tool instead of this get 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. It is a read operation (list/get) which is implicitly clear from the verb and endpoint. It doesn't describe return format, pagination behavior, or whether a particular node is required to be a specific type (e.g., PSN vs PAN). For a simple GET list operation, the behavioral traits are reasonably inferable, though more detail on output would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact—a single sentence with the endpoint reference and category tag. It's front-loaded with the core purpose. No waste, though it could arguably be slightly expanded on usage without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter and full schema coverage, the description covers the essentials: what it does, the resource type, and the required node context. It lacks note on return format (array of certificate details), which would aid an agent, but given no output schema and the read-only nature, it's reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The hostName parameter is described only as 'Path parameter hostName' in the schema, and the description contextualizes it as the node whose system certificates are listed. The deployment parameter is well-documented in the schema with concrete examples and guidance to call ise_list_deployments. The description adds the node-scoping context for hostName beyond the schema's terse path-parameter note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all system certificates for a particular node, with a specific verb (list/get) and resource (system certificates by host). It names the exact endpoint and requires a hostName. It doesn't explicitly distinguish from siblings like ise_openapi_cert_system_get, though the 'list' vs 'get' wording and 'particular node' scoping help, and the '[Certificates]' tag groups it appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it lists certificates for a specific node, implying you need to know the hostName first. There's no explicit guidance on when to use this vs ise_openapi_cert_system_get (for a single cert) or ise_openapi_cert_trusted_list (for trusted certs). The deployment parameter description does reference calling ise_list_deployments for choices, which is helpful context, but the main description lacks alternative-tool guidance.
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 states this is a read/list operation (safe) but doesn't disclose pagination behavior, ordering, whether the response includes all node details, or any auth requirements. For a tool with no annotation coverage, the description adds limited behavioral context beyond the basic 'list all nodes' claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the endpoint reference. It's appropriately brief and front-loaded with the purpose. No wasted words, though it could add minimal value with pagination notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-type tool with no output schema and no annotations, the description is minimal. It states what it does but does not describe return format, pagination, ordering, or clarify what 'nodes' means in the deployment context. The deployment parameter documentation helps, but overall this is a thin description for a tool that would benefit from more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the deployment parameter has a description; page and size have none). The description itself adds nothing about parameters. The deployment parameter is well documented in the schema with format examples and disambiguation guidance, but page/size semantics and defaults are not explained anywhere - the schema has defaults (1 and 100) but no description. This partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Retrieve the list of all the nodes that are deployed in the cluster' with the endpoint (GET /api/v1/deployment/node). It distinguishes 'list' from sibling 'ise_openapi_deployment_node_get' (retrieve single node) and 'node_group_list'. However, the [Deployment] label and endpoint reference are useful; purpose is clear but not exhaustive about the distinction from node_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for listing deployed cluster nodes, and the sibling set includes ise_openapi_deployment_node_get for single-node retrieval and ise_openapi_deployment_node_group_list for groups, giving implicit differentiation. The deployment parameter description also explains when to omit it (use only/default deployment) and directs to ise_list_deployments for choices, providing clear context for 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?
No annotations are provided, so the description carries the full burden. It implies a read-only GET operation via the HTTP verb in the endpoint path, which conveys non-destructive behavior. However, it doesn't describe the return format, pagination, error behavior, or whether the ID is a policy-set UUID. The read intent is inferable but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with an attached endpoint specifier. It earns its place with the domain tag, the verb+resource, and the REST path, with no filler or redundancy. Slightly sparse but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on return payload structure (no output schema compensates), the distinction between this and the closely-related radius_authentication_list tool, and any note that TACACS authentication rules require a specific policy set context. For a tool with no output schema and no annotations, this is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds the REST path showing id is a path parameter, which slightly enriches understanding. The description doesn't add format or semantics details for the id beyond what the schema provides, so it stays at the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets Device Admin authentication rules via a specific REST endpoint, which is a clear verb+resource statement. However, it describes itself as a 'list' tool but the endpoint is GET for authentication rules under a policy set, and the name says 'tacacs_authentication_list' while the domain is Device Admin. The description doesn't distinguish it from sibling tools like ise_openapi_tacacs_authorization_list or ise_openapi_radius_authentication_list explicitly, though the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the REST path with the {id} placeholder, implicitly communicating it needs a policy set ID to retrieve authentication rules. It doesn't explicitly state when to use this vs. the radius_authentication_list or tacacs_authorization_list siblings, nor does it explain what 'Device Admin' means in context. No exclusions are given.
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 behavioral disclosure. It indicates this is a read/list operation ('Get authorization rules') which implies non-destructive behavior, and it reveals the underlying HTTP GET method. However, it does not describe the return format, pagination, error handling, or what the authorization list structure looks like. For a GET/list operation with no annotations, this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence plus the endpoint path reference. It efficiently conveys policy domain, resource, and operation. The REST URL adds precise targeting without bloat. No wasted words, though it could have added a sentence on usage without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 could provide more context about the return structure (the list of authorization rules format). However, with only 2 parameters both fully documented in the schema, and the endpoint URL revealing the API contract, the description is reasonably complete for a straightforward list operation. The 'id' parameter's origin (from policy set creation/list) could be clarified but is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters (id, deployment) have descriptions in the schema. The schema describes 'id' as a path parameter and 'deployment' with detailed selection guidance referencing ise_list_deployments. The description adds negligible parameter meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves authorization rules for Device Admin policy sets, specifying the exact REST endpoint (GET /api/v1/policy/device-admin/policy-set/{id}/authorization). It clearly names the resource (authorization rules), the scope (device-admin policy set), and the operation (get). It distinguishes itself from siblings like ise_openapi_radius_authorization_list which target RADIUS rather than TACACS/Device Admin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for Device Admin/TACACS authorization listing, and sibling names clarify this is the TACACS variant vs RADIUS. However, there is no explicit when-to-use vs alternative guidance, no mention of prerequisites (e.g., needing the policy set id from ise_openapi_tacacs_policy_set_list), and no exclusions stated. The schema's deployment parameter does offer some usage direction but that's schema, not description.
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. The '[DESTRUCTIVE]' tag and the confirm parameter description meaningfully disclose the destructive behavior and required confirmation gate, including the server-side operator toggle (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). This is genuine added context beyond the schema. However, it doesn't state what happens to dependent objects/conditions or whether deletion is permanent once confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the DESTRUCTIVE marker and policy scope, then identifies the specific resource and endpoint. No wasted words. It's appropriately concise for a delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a confirm gate and no output schema, the description plus well-documented parameters covers the essential safety and invocation concerns. However, it's a short one-liner; a bit more context about irreversible consequences or validation behavior would strengthen it given this is a destructive tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the confirm and deployment parameters well-described in the schema itself. The description doesn't add much beyond the schema because all three parameters are already documented in the input schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a policy set' for Device Admin, targeting the specific REST endpoint. It distinguishes from siblings like ise_openapi_tacacs_policy_set_get/create/update/list. However, the description carries the HTTP method inferred from the endpoint path and the '[DESTRUCTIVE]' marker rather than a full prose purpose statement, though the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the policy area ('Device Admin') and the HTTP endpoint, which provides context. It doesn't explicitly state when to use this vs. alternatives (e.g., when to use list/get vs delete, or note that deletion is permanent and irreversible), though the DESTRUCTIVE marker and confirm parameter convey some usage context. No explicit exclusions or alternatives named.
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. It is a GET/monitoring call (read-only implication from the HTTP verb in the endpoint), which is somewhat transparent. However, it does not disclose what fields/states are returned, whether the task may be long-running, error behaviors, or whether repeated polling carries rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a leading bracketed label indicating the action and the endpoint. It's tightly scoped and front-loaded. It's minimal but not wasteful; no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple monitored GET tool with 2 params (1 required), full schema coverage, and no output schema, the description is reasonably adequate. However, it lacks behavioral details like what the status response contains or how to interpret result states, which would help the agent decide whether to poll again or proceed. Given no annotations and no output schema, a bit more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 the deployment parameter's selection semantics (name/slug/number + default deployment behavior) in the schema itself. The description text adds no parameter detail beyond what the schema already documents, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Monitor task status') and resource ('task/{id}'), clearly indicating this polls/checks the state of an asynchronous task. It's distinguishable from siblings since most siblings are ERS/OpenAPI resource CRUD or listing tools, and this uniquely addresses task status polling. However, it doesn't differentiate itself from potential task-related sibling patterns (like a task create/cancel) beyond the endpoint shown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during task monitoring but gives no explicit when-to-use guidance or alternative references. The deployment parameter description does point to calling ise_list_deployments to see choices, which is a useful cross-reference, but there's no guidance about when this tool is needed (e.g., after launching an async operation) versus alternatives.
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. It does disclose that credentials are destroyed ('and its stored credentials') and the confirm=true requirement, which are meaningful irreversible-mutation details. However, it doesn't state whether the action is reversible, whether it only affects local config vs remote, or what happens to other deployments referencing this one. The core destructive behavior and its guard are disclosed, so a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence front-loading the primary action and the critical safety requirement. Every word earns its place. It could arguably be more expansive, but for a destructive confirmation-gated tool this is appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description covers the essential safety measures (confirm gate, credential destruction) and both parameters are documented in the schema. It's slightly light on what happens after removal (return values/confirmation) and edge cases, but for a 2-param tool with complete schema coverage, this is adequate if not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (deployment: 'Name, slug, or number...'; confirm: 'Must be true to actually remove it.'). The description adds the confirm=true requirement which reinforces the confirm parameter's semantics. With full schema coverage, baseline is 3 and the description adds marginal value consistent with that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a deployment from the registry') with a specific verb+resource, and adds the notable detail that it also removes stored credentials. It doesn't explicitly distinguish from sibling tools like ise_add_deployment or ise_update_deployment, though the verb 'remove' is self-evident against its siblings, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description requires confirm=true, which is the key usage gate. However, it doesn't provide when-to-use guidance or alternatives (e.g., what to use to deactivate a deployment without removing credentials, or that this is distinct from ise_update_deployment). The confirm requirement is clear context but no exclusions or alternatives are given.
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. 'Get' implies a read operation and the tool is clearly a single-object fetch, but the description doesn't disclose return format, whether a 404 is returned for missing IDs, or any auth/permission requirements. For a read-only getter this is minimal-but-acceptable, though richer context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the purpose. There is nothing extraneous; it is concise and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-object getter with 2 params and no output schema, the description is relatively complete. However, given the large sibling set and the absence of annotations, it could benefit from noting eligible ID sources (e.g., from a list call) or the relationship to search_activedirectory. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with 2 parameters (id, deployment). The id parameter has no description in the schema, and the description doesn't add meaning for it. The deployment parameter is well-documented in the schema itself. The description adds no parameter-level insight beyond what the schema provides, so the baseline of 3 applies since coverage is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Active Directory object by ID' clearly states the verb (get), resource (Active Directory object), and method (by ID). It distinguishes from siblings like ise_ers_list_activedirectory (list) and ise_ers_search_activedirectory (search by criteria). However, it doesn't explicitly call out the differentiation from the generic get tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a single object when you have its ID, which is a natural read. However, it doesn't explicitly say when to prefer this over search_activedirectory or list_activedirectory, nor provide any exclusion guidance. The name pattern (get_*) is the primary signal for when to use it.
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 transparency burden. It states this is a read-only 'Retrieve' operation, which implies safety. It also discloses the constraint that not all resources support this operation. However, it doesn't describe error behavior (what happens for unsupported resources or missing names), response format, or pagination. The parenthetical about supported resources is the main behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that compresses the core purpose and constraint into minimal words. No filler, no redundancy. This is exemplary conciseness for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fetch-by-name tool with a 100%-covered schema and 3 parameters, the description is reasonably complete. The main gap is that with no output schema and no annotations, the agent doesn't know the return format or error semantics. It's a well-contained tool but the absence of behavioral detail (query failure for unsupported resources, whether name is case-sensitive, etc.) leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (name, resource, deployment). The description adds the key semantic that 'name' maps to the /name/<name> URL pattern, which is useful. The resource param references ise_ers_resources for discovering supported operations. The deployment param is well-explained in the schema with concrete examples. The description adds marginal value but doesn't fully orient the agent on parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Retrieve a single ERS object by its name'. It clearly indicates operational scope ('for resources that support /name/<name>'). While it's clear, it doesn't explicitly distinguish from sibling tools like ise_ers_get (which retrieves by ID) or ise_ers_search (which searches), so it relies on the reader to infer differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'for resources that support /name/<name>' hints at a constraint on which resources work. However, it doesn't explicitly say when NOT to use it, nor mention alternatives like ise_ers_get (by ID) or ise_ers_search. The deployment parameter references ise_list_deployments, which is helpful. There's implicit context but no clear exclusions or alternative references.
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 implicitly indicates mutation (PATCH/update) but doesn't state what happens on partial field omission, whether it returns the updated object, validation behavior, or error handling for non-existent IDs. For a mutation tool with zero annotation coverage, this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the operation type, scope, and a key usage instruction. Zero waste, all content is load-bearing for the purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a dangerous mutation operation with 4 parameters, no output schema, and no annotations. The description adequately communicates the core purpose and partial-update guidance, but for a write operation of this breadth (60+ resource types), more behavior disclosure would be warranted. The description is adequate but modest given the tool's complexity and risk profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with 'data' and 'deployment' having descriptions and 'resource' having a description plus enum. The description's 'Provide only the fields to change' clause adds meaning to the 'data' parameter beyond its bare 'Fields to change' schema text by emphasizing the partial-update semantics. However, 'id' has no schema description, and the description doesn't add format or constraint detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'Partial update (PATCH) of an existing ERS object by ID,' specifying the verb (PATCH/update), resource (ERS object), scope (single object by ID), and the ISE version constraint (ISE 3.x). This clearly distinguishes it from siblings like ise_ers_create (full create), ise_ers_update (full update), and ise_ers_get (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Provide only the fields to change,' which gives useful guidance on how to use the tool (partial vs full update). However, it doesn't explicitly distinguish when to use PATCH vs the sibling ise_ers_update tool, nor does it mention any prerequisites like needing to fetch the existing object first. The ISE 3.x version constraint is mentioned but not elaborated.
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. The description explains that it uses ERS filter and sort expressions, which is meaningful behavioral info about query semantics. However, it doesn't disclose pagination behavior (page/size defaults exist in schema), what happens when filter syntax is invalid, whether results span deployments, or return format expectations. Moderate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single crisp sentence that efficiently conveys the tool's purpose and the two key syntaxes (filter and sort expressions). Every word earns its place with concrete examples deferred to the schema. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic search with 6 parameters, no output schema, and no annotations. The description covers the core search/filter/sort semantics but omits return format, pagination behavior, and interplay with deployment scoping. There are numerous sibling per-resource search tools that could serve as alternatives, but the description doesn't clarify when the generic version is preferred. Adequate for a common pattern but leaves gaps on return values and pagination defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 of 6 params have descriptions: size, sort, filter, resource, deployment all have descriptions actually — page lacks one and sort/filter have short ones). The description adds the key semantic value by explaining the filter/sort expression format ('field.OP.value' and '+field'/'-field'), which the schema examples reinforce. The resource param description already points to ise_ers_resources. The description doesn't add meaning for page or deployment beyond schema. Adequate but does not exceed schema coverage meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches/filters ERS objects using ERS filter expressions and sort expressions. It specifies the verb (search/filter), resource (ERS objects), and the expression format. However, it doesn't explicitly distinguish itself from sibling tools like ise_ers_list or ise_ers_search_* per-resource tools, though the generic nature is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the filter and sort expression syntax explicitly with examples, which is helpful usage context. However, it doesn't state when to use this generic search vs. the many per-resource search tools (ise_ers_search_endpoint, ise_ers_search_sgt, etc.), nor does it mention the resource parameter pointing to ise_ers_resources for guidance. No exclusions or alternatives are provided.
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. It discloses that it returns 'raw XML' (useful behavioral info about response format), confirms it's read-only GET operation. However, it doesn't describe response structure, whether the count includes all session types, or potential error conditions. The 'raw XML' detail is helpful but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences that convey the core purpose, endpoint, and output format. Efficient and front-loaded. It could add a bit more usage context, but for a simple count GET tool, the brevity is reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count endpoint with one optional parameter, the combination of description (endpoint URL + raw XML output) and schema coverage (100%) is reasonably adequate. However, it doesn't explain what 'Active Session' means in the ISE context, whether there are filters possible, or how the count differs from other count tools (posture, profiler). No output schema exists so return structure is unspecified beyond 'raw XML'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter (deployment) is thoroughly documented in the schema itself, including format examples ('RADIUS Only', 'radius-only', '1') and a reference to ise_list_deployments. The description adds the endpoint context but the schema does the heavy lifting for the parameter. With just one well-documented parameter, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ([Sessions]), verb (Get), and specific endpoint (GET /admin/API/mnt/Session/ActiveCount). The name 'ise_mnt_active_session_count' clearly distinguishes it from siblings like ise_mnt_active_session_list (list vs. count) and ise_mnt_posture_session_count / ise_mnt_profiler_session_count (different count types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the endpoint but doesn't explicitly say WHEN to use this vs alternatives like ise_mnt_active_session_list. It doesn't mention that this returns a simple count, which would differentiate it from the session list tool. The deployment parameter helps with target selection but not tool selection.
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 full responsibility for behavioral disclosure. It states that it 'Returns raw XML', which is useful behavioral information about the return type. However, it doesn't disclose auth requirements, error behavior, or what 'reauthentication status' semantically means in terms of output, for a MNT API call with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus the endpoint reference plus the XML return note. Every part earns its place. It's compact and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple status-lookup tool with no output schema and full param coverage. The description conveys the purpose, the endpoint, and the return format (raw XML). However, for a tool returning raw XML with no output schema, an agent might benefit from knowing what fields appear in the response or typical structure, which is absent. Still, given the simplicity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds the '[CoA]' context and the endpoint path underscore to show how node/mac/type map to path parameters. The deployment parameter's meaning is well documented in the schema itself, so the description doesn't need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get CoA reauthentication status') with a specific resource ([CoA]) and even includes the underlying GET endpoint. It's clear this is a read operation tied to the MNT API family. It doesn't explicitly distinguish from sibling tools like ise_mnt_coa_disconnect, but the verb 'Get ... status' makes it a read vs. the sibling's mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a status lookup tied to a specific node/mac/type triple, and the deployment parameter mentions ov to use the default deployment and calls ise_list_deployments to see choices. However, it doesn't explicitly state when to use this vs alternative tools (e.g., session lookup tools, coa disconnect), nor does it state prerequisites (e.g., an active session). Context is implied but not explicitly bounded.
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 provided, the description carries full burden for behavioral disclosure. It states the operation is a GET (read-only), which is some transparency, but doesn't disclose whether the node must be active/registered, what happens for invalid hostnames, error behavior, or the response format details for a deployment node retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that front-loads the purpose ('Retrieve details of a deployed node') before the endpoint reference. The deployment param guidance is embedded where it belongs (in schema, not bloating the description). Minimal waste, though the GET path is somewhat technical noise for an agent deciding tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-hostname tool with 2 params (100% schema coverage) and no output schema, the description is mostly adequate. However, with no annotations and no output schema, the description doesn't explain what node properties are returned, which could matter for an agent deciding whether this tool satisfies a query. The deployment param handling is well-covered but returns are unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, so both parameters have descriptions in the schema. The 'deployment' parameter description is notably rich: it explains the three accepted formats (name, slug, number), includes an example, and even references ise_list_deployments for discovering choices. This exceeds typical schema descriptions and adds genuine decision-relevant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve details of a deployed node' with the specific verb 'Retrieve' and resource 'deployed node', and includes the exact REST endpoint. It distinguishes from the sibling ise_openapi_deployment_node_list which is the list operation, though it doesn't explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for getting a single node's details (contrasted with the list tool) but provides no explicit 'when to use vs alternatives' guidance. The endpoint verb 'GET' implies read-only, and the presence of the list sibling weakly signals this is the detail retrieval tool, but no exclusions or alternatives are named.
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 behavioral disclosure. The description indicates this is a GET/read operation that lists hot patches, which implies a non-destructive read. However, it doesn't state whether pagination is applied, what the response format looks like, or how many results are returned by default. The description provides only minimal behavioral context for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the purpose efficiently: 'List installed hot patches (GET /api/v1/hotpatch)'. The endpoint reference is useful operational context, and the '[Patch]' prefix appears to be a category label. Zero wasted words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with 0 required parameters and no output schema, this description is reasonably complete for the core purpose. However, given the existence of ise_openapi_patch_list sibling, the description could clarify the distinction between regular patches and hot patches. The pagination behavior via page/size params is implied but not elaborated, and the default size of 100 isn't mentioned. It's adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (1 of 3 params documented). The 'deployment' parameter has a rich description explaining how to specify deployment (name, slug, or number) and even cross-references ise_list_deployments. However, 'page' and 'size' parameters have no description, relying on their names - 'page' implies pagination and 'size' implies page size, but format/behavior isn't explained. The description itself doesn't elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List installed hot patches' with the verb 'List' and resource 'hot patches', which is specific and clear. The '[Patch]' prefix signals it's a read-only list operation on the hot patch endpoint, distinguishing it from related siblings like ise_openapi_hotpatch_install/rollback. It identifies the resource clearly but could be marginally better about scope (all vs filtered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the HTTP endpoint (GET /api/v1/hotpatch) which is useful context, but there's no explicit when-to-use guidance versus alternatives like ise_openapi_patch_list (regular patches vs hot patches). The sibling ise_openapi_patch_list exists and would compete for the same use case; the description doesn't clarify when to choose hotpatch vs patch listing. No exclusions are stated.
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 labels the tool as a 'Report' (implying read-only safety) but never explicitly states it performs a safe read, doesn't describe return format, pagination behavior beyond the limit parameter, or time-filtering semantics of days_back. For a report/data-viewing tool with zero annotation coverage, key behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and then enumerates the columns. It's compact with no filler or repetition. Slight room for improvement in that it could add one more clause about usage decisions, but the current structure is clean and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations. The description is adequate for a filtered report-viewing tool: it names the columns, implies filtering, and the schema documents all params. However, it doesn't mention what the returned data looks like (since there's no output schema), pagination defaults, or how days_back interacts with time columns. For a report tool, this is acceptable but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters already have descriptions in the schema. The description adds meaningful context by enumerating the filterable columns (which map conceptually to filter_column and order_by choices), providing value beyond the raw schema. The parameters themselves (limit, order_by, days_back, filter_op, deployment, filter_value, filter_column) are self-explanatory and well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly labels this as a [Report] for TACACS Authorization records and explicitly lists all filterable columns (ID, GENERATED_TIME, LOGGED_TIME, ISE_NODE, ATTRIBUTES, EXECUTION_STEPS, STATUS, EVENT). The verb 'provides details of' plus the resource and column scope makes the purpose specific and distinct from sibling report tools like tacacs_authentication and tacacs_accounting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading TACACS authorization records but provides no when-to-use guidance or exclusions versus alternatives. There are related sibling tools (ise_dc_view_tacacs_authentication, ise_dc_view_tacacs_accounting, ise_openapi_tacacs_authorization_list) that could be confused, but the description doesn't clarify when to pick this one over them. The 'Report' prefix hints at read-only reporting, but no explicit guidance is given.
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 were provided, so the description carries the burden. The description reveals this is a read/fetch operation ('Get') implying no destructive side effects, which is the key behavioral trait. However, it doesn't disclose what happens for invalid/nonexistent IDs (error response behavior), pagination characteristics, or whether 404s are returned, though for a simple get-by-id these are minor 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Get a single Authorization Profiles object by ID.' Zero waste, front-loaded with the action verb 'Get' and resource. It is appropriately minimal for a straightforward get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with only one required parameter and no output schema requirement, the description is adequate to explain return-value framing. However, it doesn't specify that the returned object schema (fields of an Authorization Profile) could be large/unexpected, and doesn't guide the agent on how IDs are obtained (list vs search). Given the simplicity, this is a complete-enough definition but leaves minor gaps around obtaining IDs and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the deployment parameter has a thorough description in the schema naming formats (name, slug, number) and points to ise_list_deployments. The 'id' parameter relies on the description's statement that it retrieves by ID. The parameter meanings are adequately conveyed between schema and description, with the description adding the notion that 'id' identifies the Authorization Profile object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource combination: 'Get a single Authorization Profiles object by ID.' This clearly distinguishes it from sibling list/search tools (ise_ers_list_authorizationprofile, ise_ers_search_authorizationprofile). However, it doesn't explicitly contrast with the get-by-name variant or note that 'id' is a specific ERS resource identifier, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool is to be used to fetch a single Authorization Profile given its ID. The description implicitly distinguishes this from list (all objects) and search (filtered query) siblings by naming 'single... by ID.' However, it provides no explicit when-to-use vs alternatives guidance, no exclusion notes, and doesn't mention how to obtain the id (e.g., via list/search).
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 provided, so the description carries the full burden. It discloses pagination behavior ('Paginated') and that it returns ALL endpoints (no filtering mentioned), which is useful. However, it doesn't disclose what the response format looks like, whether there are rate limits, or whether this operation touches any system state. The absence of an output schema and the terse nature leaves the behavioral profile under-specified for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately minimal at two sentences, front-loading the core purpose. The 'Paginated' note is efficient. It gets 4 rather than 5 because the parameter descriptions in the schema carry most of the explanatory weight, and the description doesn't add meaningful behavioral detail beyond the minimal statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 optional parameters and no output schema, this is adequate but thin. The pagination behavior is noted, and the deployment targeting question is handled well. However, with no output schema and no description of the response format (which is significant for a paginated list potentially spanning many endpoints), the agent has no way to know what fields to expect or how to iterate pages. This is a meaningful gap for a complex enterprise tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% - only the deployment parameter has a description. The page and size parameters are self-explanatory with defaults, but the deployment parameter gets a thorough description in the schema itself, not in the tool description. The description's 'Paginated' tag adds minimal value beyond what the page/size parameters already imply. Neither the description nor schema explains the size limits or page semantics beyond defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Endpoints with pagination. The verb-resource combination (list + Endpoints) is specific and unambiguous. However, it doesn't distinguish itself from sibling list tools beyond the resource type, which is somewhat inherent in the naming convention used across all ise_ers_list_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all endpoints, which is clear context. The deployment parameter explanation does give guidance on when to use it ('Omit to use the only/default deployment') and points to ise_list_deployments for alternatives. However, it doesn't explicitly distinguish from search_endpoint or get_endpoint alternatives when a user needs a specific endpoint.
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 behavioral transparency burden. It discloses pagination behavior but doesn't reveal return format, ordering, field selection, or the size limits. For a read-only list operation the risk profile is lower, but with zero annotations the description provides only minimal behavioral context about what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. The deployment parameter description is embedded richly within the schema rather than cluttering the description. Efficient and minimal waste, though marginally could state the purpose more completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with no output schema, the description is moderately complete. It covers purpose, pagination, and deployment targeting. However, it lacks guidance on result size expectations, sorting, or how the listing differs from ise_ers_list_ldap's get/search counterparts, and the page/size parameters are left entirely to schema defaults without behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% - the description covers the deployment parameter in detail (with concrete name/slug/number examples and pointer to ise_list_deployments) but says nothing about page/size semantics beyond the schema's defaults. This partially compensates for the schema gap but not fully, as the page and size parameters lack behavioral guidance in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all LDAP Identity Sources with pagination. The verb+resource (list LDAP identity sources) is specific and unambiguous. It distinguishes from get/search_ldap siblings (which retrieve specific items), though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions pagination, indicating it returns paginated results. The deployment parameter documentation is detailed (name/slug/number examples given). However, it doesn't explicitly state when to use this vs the get/search alternatives, and the pagination guidance is minimal without explaining how to navigate pages.
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 does flag '[DESTRUCTIVE]' in the description and the confirm parameter documents that the server requires destructive tools enabled (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). However, it doesn't describe reverting effects, that a restore may overwrite existing config, or the potential for service disruption during restore.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a useful follow-up pointer to the Task Service status API. It's front-loaded with the [DESTRUCTIVE] warning tag. It's efficient with no wasted words, though it leans on tags for structure rather than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive, state-changing operation with no output schema and no annotations. The format is a simple task-based workflow (submit backup name, get task ID, poll task). While the description explains the basic flow and points to task status checking, it lacks details about what the restore modifies, whether it's reversible, potential downtime, or the structure of the required 'data' body. For a destructive tool, more behavioral context would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all three parameters. The description adds some meaning by clarifying the restore requires a backup file name, repo, and encryption key, but the 'data' nested object's exact structure/schema is not explained in the description. The deployment parameter is well-explained in the schema itself. Description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Restore a config DB backup by giving the name of the backup file, repository name and encryption key.' It specifies the input requirements and mentions the returned task ID. It doesn't explicitly distinguish itself from siblings like ise_openapi_backup_create or ise_openapi_backup_cancel, but the 'restore' action is inherently distinct from backup creation/cancellation within the backup-restore family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: name the backup file, repository, and encryption key, then use the Task Service status API to track progress. It points to a specific related tool (Task Service). However, it doesn't explicitly state when NOT to use this vs alternatives or mention prerequisites like backup existence.
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 behavioral disclosure. It marks [DESTRUCTIVE] and [Patch] inline and notes it's a rollback operation. However, it doesn't state what exactly gets reverted, whether the node restarts, session impact, or reversibility. The confirm param elaboration (server requires ALLOW_DESTRUCTIVE env var) adds real transparency value, but that's in the schema, not the description text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact line with the endpoint, plus the [DESTRUCTIVE]/[Patch] tags leading. It's efficient. The confirm and deployment param descriptions do meaningful work. Slight redundancy since [DESTRUCTIVE] appears in both description and confirm schema, but the tags are useful for safety signaling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, the description plus enriched param schemas give good coverage. The confirm flag's dual requirement (user true + server-side env var) is well explained. For a 3-param destructive tool, this is reasonably complete, though the absence of behavioral details on node impact and reversibility keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the confirm param has rich explanation (must be true, server-side env var requirement). The deployment param (name/slug/number) is well-specified with a fallback default and pointer to ise_list_deployments. The 'data' param is noted as the JSON body with an example endpoint. Since schema already covers everything at 100%, baseline is 3, and the confirm/deployment detail pushes it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Rollback hotpatch from the Cisco ISE node' and includes the REST endpoint. It clearly indicates a destructive patch operation. It distinguishes from siblings like ise_openapi_patch_rollback and ise_openapi_hotpatch_install by specifying hotpatch rollback specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself doesn't state when to use this tool vs alternatives, though the [DESTRUCTIVE] flag and the confirm param schema hint at the safety requirement. The deployment param schema directs to ise_list_deployments but the main description lacks explicit when-to-use guidance. The confirm-required and environment-var requirement are in the schema description, not the main description.
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 of behavioral disclosure. The description reveals the HTTP method (GET) which implies read-only behavior, and it shows the endpoint URL. However, it doesn't describe what the response format is, whether pagination is meaningful here, or what 'tier state' data actually contains. For a non-destructive read operation, the GET method disclosure is helpful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that conveys the resource, domain, and endpoint. It's appropriately terse for a simple read operation. The deployment parameter description in the schema is also well-structured and informative. No wasted words or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET operation with only 3 parameters (0 required), the description plus the deployment parameter guidance covers the essentials. The deployment parameter description is especially helpful given the multi-deployment aspect of ISE. Without an output schema and with no annotations, it could benefit from a brief note on what tier-state data contains or how pagination applies, but the description is adequate for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the deployment parameter has a description in the schema, and it's quite detailed (explains name/slug/number options, default behavior, and references ise_list_deployments). The page and size parameters lack descriptions (0% schema coverage for those). The deployment parameter's schema description is thorough, adding real semantic value. Since one of the three parameters is well-documented and the others are simple pagination controls, this is reasonably handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets 'tier state information' for licensing, with a specific API endpoint (GET /api/v1/license/system/tier-state). The verb is clear (get) and resource is specific (license tier state). While there are sibling license tools (license_smart_state_get, license_register, license_eval_get), the '[Licensing]' prefix and 'tier-state' resource distinguish it adequately, though it could be more explicit about what tier state means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use vs alternatives guidance. It doesn't explain when to prefer this over other license tools like license_eval_get or license_smart_state_get. However, the deployment parameter documentation does give useful context about when deployment selection matters and points to ise_list_deployments. There's no explicit '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.
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 pagination behavior ('Paginated') and implies a read-only retrieval, but doesn't state default page size, what fields are returned, rate limits, or authorization requirements. For a listing tool, stating pagination is helpful but minimal behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At just two sentences ('List all Endpoint Identity Groups. Paginated.'), every word earns its place. It's front-loaded with the core purpose and adds one essential behavioral trait (pagination) without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with 3 optional parameters, no output schema, and no nested objects. The description correctly identifies the resource and pagination. While it could mention default page/size values (100 items by default) and noting it retrieves the full collection, the complexity is low and the description is adequate 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — only 'deployment' has a description in the schema; 'page' and 'size' are bare. However, their names are largely self-documenting given the 'Paginated' note. The description's mention of pagination adds context to the 'page' and 'size' params, and the deployment description is rich. The description compensates reasonably despite low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all Endpoint Identity Groups. Paginated.' This clearly identifies the verb (List), resource (Endpoint Identity Groups), and scope (all). It distinguishes from sibling list tools like ise_ers_list_networkdevice or ise_ers_list_sgt by naming the specific resource. However, it doesn't explicitly differentiate from closely related siblings like ise_ers_list_identitygroup or ise_dc_view_endpoint_identity_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The pagination mention implies a listing context, but there's no explicit 'use when' guidance. It doesn't contrast against alternatives like ise_ers_search_endpointgroup (for filtered lookup) or ise_ers_get_endpointgroup (for single fetch). The deployment parameter references ise_list_deployments, offering indirect guidance, but no explicit when-to-use vs. alternatives is provided.
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. It states the read-only nature (lists resources) clearly. It doesn't disclose whether this contacts the live deployment, whether it requires auth, or whether it's cached. For a read-only listing tool, this is modest but acceptable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the core verb and purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with one optional parameter and no output schema, the description adequately covers what happens. It could mention whether output varies by deployment, but the tool is simple enough that this level of detail is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'deployment' parameter is well documented in the schema itself, including format options and reference to ise_list_deployments. The description adds no additional parameter detail but the schema is self-sufficient, so the baseline 3 with good schema justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ERS resources with API paths and supported operations. It uses specific verb 'list' + resource 'ERS resources'. While it distinguishes from per-resource tools like ise_ers_list_endpoint, it doesn't explicitly contrast with ise_ers_list or other sibling generic tools like ise_route/capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a discovery/enumeration tool for understanding what ERS resources exist before calling resource-specific tools. However, it doesn't explicitly state when to use this versus alternatives like ise_ers_list, ise_route, or ise_capabilities, nor does it mention it as a prerequisite step.
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 burden of behavioral disclosure. It does note it returns 'raw XML' and it's a 'System' Get operation, implying a safe read. However, it doesn't disclose what happens on unsupported deployments, error shapes, or whether the XML structure is consistent. The read operation nature is inferable from 'Get' though not explicitly stated as non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single bracketed system line plus endpoint and return format. Zero wasted words, adequately front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-param simple system query with an output note (raw XML), the description is fairly complete. It lacks details about pagination, error handling, or content of the XML version payload, but for a version lookup these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single deployment parameter well documented including name/slug/number formats and an explicit pointer to ise_list_deployments. No params means baseline 4 for this simple 0-required-param tool; the description itself adds the raw XML format note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), resource (Product Version), and the exact API endpoint (GET /admin/API/mnt/Version). It also notes the return format (raw XML). It doesn't explicitly distinguish from sibling tools by name, but as a version/health query it's reasonably distinct among the ise_mnt_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is terse but implies usage as a basic system-version retrieval tool. There's no explicit when/when-not guidance or alternative tool mention, though the tool is fairly self-evident. The deployment param guidance (in schema) helps but isn't part of the description.
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?
The [DESTRUCTIVE] tag and description clearly flag this as a destructive operation, and it discloses that a server-side operator toggle (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1) is required, which adds real behavioral context beyond the schema. No annotations are provided, so the description carries the full burden and does disclose the destructive nature and returns raw XML. However, it doesn't describe what happens on failure (e.g., when no session matches the MAC) or side effects beyond record deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that packs the essential information: destructive flag, resource type, action verb, endpoint path, and return format. Zero waste, front-loaded with the destructive warning. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 params (all documented), no output schema, and no annotations. The description covers purpose, destructive nature, endpoint, and return format. It's reasonably complete for a simple delete operation, but lacks detail on edge-case behavior (no matching session, output format specifics). Given the destructive nature and the existence of a sibling delete-by-id tool, slightly more context would strengthen it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters. The description itself adds the confirm-required-for-destructive context and deployment target details via schema descriptions. The description adds modest value (confirm semantics, deployment resolution) beyond the raw schema, but this is mostly carried by the schema fields. Baseline 3 applies since coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource+scope: 'Delete session record by MAC address' with the exact endpoint path and return format (raw XML). It clearly distinguishes from sibling tools like ise_mnt_session_delete_by_id (by ID) and read-only session tools. Loses a point because it doesn't explicitly contrast with the by-ID deletion sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [DESTRUCTIVE] tag and the confirm parameter explanation give clear context on when/how to invoke. The description effectively states the precondition (confirm=true, and operator must enable destructive tools). However, it doesn't explicitly say when NOT to use this vs. the by-ID variant, though the by-MAC naming is fairly self-explanatory.
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?
While no annotations are provided, the description explicitly marks this as DESTRUCTIVE and prominently describes the confirm=true requirement and the operator-level enablement (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). This is substantial behavioral disclosure about the safety gate beyond what the raw schema reveals, genuinely useful for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact — a single line plus effective schema param descriptions. The confirm param explanation is thorough without being verbose. Front-loaded with the DESTRUCTIVE tag. Slight redundancy: '[DESTRUCTIVE]' tag plus the confirm language is repeated across schema and description, but it's warranted given the stakes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation with no annotations and no output schema, so the description carries a heavier burden. It adequately covers the safety gate, the endpoint path, and deployment targeting. It doesn't mention what happens to associated files or whether deletion is reversible, and doesn't describe the response, but for a simple repo deletion the core safety and targeting context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds significant value beyond the schema on the confirm parameter by explaining the two-layered protection (caller must set true AND operator must enable destructive mode) and on deployment by giving concrete formats ('RADIUS Only', 'radius-only', '1') and pointing to ise_list_deployments. The name param is minimally documented but self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a specific repository' with the DELETE endpoint, which is a clear verb+resource. However, 'repository' is a somewhat generic term and the description doesn't differentiate this from the many sibling delete tools (e.g., ise_ers_delete, ise_openapi_cert_system_delete). The scope is clear but sibling distinction depends on the '[Repository]' tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the '[DESTRUCTIVE]' tag and shows the HTTP endpoint, but doesn't explicitly state when to use this vs alternatives like ise_openapi_repo_list/get/update. No when-not-to-use guidance, no prerequisites mentioned beyond the confirm requirement which is actually in the schema.
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 provided, the description carries the full burden of behavioral disclosure. It identifies this as a read/report tool ('[Report]') but does not state that it is non-destructive, whether it needs specific permissions, pagination behavior beyond the 'limit' parameter, or what happens on empty results. The listing of filterable columns adds some useful context but not behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states purpose, the second enumerates usable columns. It is front-loaded with the tool type and resource, then lists the actionable filter surface. Appropriate density for a reporting tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only filtering tool with 100% schema coverage and no output schema, the description is reasonably complete. However, given the large sibling family (many ise_dc_view_* report tools with similar filter semantics), a bit more differentiation of what makes threat events unique would improve completeness. The listing of filterable columns partially compensates for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are documented in the schema. Yet the description adds value by listing the actual column names (LOGGED_AT, MAC_ADDRESS, etc.) that map to filter_column, which the schema alone doesn't enumerate. The description also mentions the '[Report]' nature and filtering capability, supplementing the schema-level parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '[Report] Threat Events: Log of threat events received from various sources' with a specific verb (view/report) and explicit resource (threat events log). It lists filterable columns and is clearly distinguished from siblings: it's one of the ise_dc_view_* family but uniquely targets threat events, differentiating from radius/tacacs/endpoint view tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a reporting tool ('[Report]', filterable columns) but does not explicitly state when to use this vs alternatives. It names the supported filters which helps contextualize usage, but provides no exclusions or explicit alternative tools. The '[Report]' prefix and the view-tool family context give reasonable implied guidance but not explicit when/when-not direction.
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 full burden. It explicitly marks the [DESTRUCTIVE] nature, and the confirm parameter's schema discloses that an operator must enable destructive tools via environment variable CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1 or the call is refused. This is substantial behavioral context for a destructive operation, revealing the confirmation gate and the operator-level toggle requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short sentence. It front-loads the destructive warning. It is appropriately sized for a tool fully documented via its schema. No wasted words, though it could arguably include one line about irreversibility given it's a delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a destructive mutation with high schema coverage (75%) and no output schema (delete typically returns minimal), the description plus schema adequately cover id, resource selection, confirm gating, and deployment targeting. The main gaps are: no explicit warning that deletion is irreversible/lossy, and no mention of return/response behavior. Given the confirm gate and resource pointer, this is reasonably complete for its class.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, which is high. The description itself says 'by ID' clarifying the id parameter's role. The confirm parameter's schema adds behavioral semantics (must be true to execute, env var gate). The resource parameter schema points to ise_ers_resources for enumeration. The description does not add detail on id format (e.g., UUID vs name), but with 75% coverage the schema carries the burden; description adds modest value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete an ERS object by ID" clearly states the verb (delete), resource type (ERS object), and key qualifier (by ID). This clearly differentiates it from sibling tools like ise_ers_get (retrieve) and ise_ers_create (create). The [DESTRUCTIVE] prefix adds emphasis. However, it doesn't explicitly distinguish it from ise_ers_patch/update beyond the naming, though purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when deleting by ID, and the resource parameter explicitly points to ise_ers_resources for supported operations. The confirm parameter schema explains the destructive activation requirement (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). However, it doesn't explicitly state when NOT to use it or mention alternatives (e.g., ise_ers_patch for partial updates), nor warn against deleting protected resources.
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 of behavioral disclosure. The description states it is a read ('Get') operation but provides no detail on return format, error behavior, or requirements. For a non-destructive GET by ID, the ambiguity is moderate but acceptable given the read-only nature implied by the name and description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the tool's action and resource clearly with zero wasted words. Front-loaded with the verb 'Get' and identifies the resource (Admin Users object) and scope (by ID).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID GET tool with no output schema, the description covers the essential purpose. The deployment parameter is documented in the schema. The tool is straightforward: retrieve one object by ID. No output schema exists, so the description doesn't need to describe return values beyond what's implied by 'Get a single object'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'deployment' param is fully documented with examples and alternatives, while 'id' lacks a description. The description's core purpose is to retrieve an Admin Users object by ID, which explains the primary parameter's role despite the schema gap on 'id'. The description adds no new param detail beyond the schema, but the schema already handles the more complex deployment param well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('Admin Users object'), and the mechanism ('by ID'). It clearly distinguishes from sibling tools like ise_ers_search_adminuser (search) and ise_ers_list_adminuser (list all). The purpose is unambiguously a single-object retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are given. The description does not mention when to choose this over ise_ers_search_adminuser or ise_ers_list_adminuser. Usage context must be inferred from the tool name pattern and the 'by ID' qualifier, which distinguishes it from list/search siblings implicitly, but no explicit exclusions or alternative references are provided.
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?
While no annotations are provided, the description does disclose the return format ('Returns raw XML'), which is a useful behavioral trait. It could elaborate on whether the endpoint errors if the username has no active session or what 'Full SD username information' contains, but noting raw XML output is meaningful. The 'GET' and endpoint path imply read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys purpose, endpoint, and return format. It's front-loaded with the purpose. It could potentially mention alternatives for contrast, but there's no waste or redundancy in the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 100% schema coverage, full endpoint documentation, return format disclosure, and clear parameter help, the description is reasonably complete. It could benefit from noting error behavior when no session exists and what the 'full information' includes, but given the tool's simplicity and rich schema, it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters. The description adds value by specifying the endpoint path demonstrates username is a path parameter, and the deployment parameter guidance is fully explained in the schema. The description itself doesn't add much beyond the schema, but at 100% coverage the baseline 3 applies; the endpoint disclosure slightly enriches the username semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets 'Full SD username Information' via a specific endpoint (GET /admin/API/mnt/Session/UserName/{username}). The verb 'Get' plus resource 'Full SD username Information' makes the purpose clear. It is distinguishable from siblings like ise_mnt_session_by_mac, ise_mnt_session_by_ip, and ise_mnt_session_by_id, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions this is for 'Sessions' and by 'username', which implies when to use it versus sibling session tools. However, it doesn't explicitly state when to use this instead of session_by_mac, session_by_ip, or session_by_id, nor contrast with ise_mnt_active_session_list. Usage context is implied but not explicit.
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 explains the destructive nature, the confirm=true requirement, and the server-side operator gate (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1) that must be enabled or the call is refused. This is substantial behavioral context for a mutation tool — covers safety gate, prerequisites, and failure condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with clear tags. The schema text is well-structured and front-loaded with the destructive confirmation requirement first. Efficient use of space with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive patch rollback with a nested data object and confirm flag, the description plus schema fully cover the prerequisites (operator flag, confirm), safety (destructive warning), and target selection (deployment param with list reference). No output schema exists, but for a rollback operation the return value is likely a task reference — a minor omission but adequate given the symmetric hotpatch sibling and the [Patch] tag context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 3 parameters. The deployment parameter description in the schema is already rich (name/slug/number formats, default behavior, reference to ise_list_deployments). The confirm parameter schema text fully explains the destructive gate. Little extra needed from the description since the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (removes patch), resource (from Cisco ISE node), and gives the HTTP endpoint (POST /api/v1/patch/rollback). It distinguishes from sibling ise_openapi_patch_install and ise_openapi_hotpatch_rollback by the [Patch] prefix. Not a perfect 5 since it doesn't elaborate on what 'removes patch' means functionally beyond the literal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [DESTRUCTIVE] tag and confirm parameter explain that this is a destructive rollback operation requiring explicit confirmation. The deployment parameter references calling ise_list_deployments to see choices. However, no when/not-when guidance is given — e.g., when to use this vs ise_openapi_hotpatch_rollback or ise_openapi_patch_install. The distinction is implied by naming but not stated.
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?
The description prominently marks this as [DESTRUCTIVE], which is critical behavioral disclosure. While no annotations are provided (so the description carries the full burden), the confirm parameter and deployment parameters add meaningful context about the destructive nature, the operator-level requirement (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1), and target deployment selection. This is strong transparency for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise description - a single line that includes the destructive warning, policy scope, verb+resource, and the HTTP endpoint. Every element serves a purpose and it's front-loaded with the most critical information ([DESTRUCTIVE]).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, this description does a solid job: it flags destructiveness, explains the safety gating (confirm + operator flag), and covers deployment targeting. The main gap is that it doesn't warn about irreversibility or cascading effects (e.g., what happens to authentication policies tied to the deleted policy set). But given the richness of the schema parameters covering confirm and deployment, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (id, confirm, deployment). The description adds value by explaining the confirm parameter's destructive requirement and the deployment parameter's format options, which goes somewhat beyond the schema. However, the description doesn't explain the id parameter format or what makes a valid policy set id. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a policy set for Network Access via the DELETE endpoint, with a specific RESTful verb and path. However, it doesn't differentiate from the analogous ise_openapi_tacacs_policy_set_delete sibling (Network Access vs TACACS is implied but not explicit), though the '[Policy: Network Access]' prefix provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (deleting a Network Access policy set) but provides no explicit guidance on when NOT to use it or alternatives. The deployment parameter description references ise_list_deployments, which is helpful context. However, no exclusions or alternatives (like the ERS delete or TACACS variant) 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. The description indicates it's a read-only inspection operation ('Get the column details...'), which implies non-destructive behavior. However, it doesn't state what happens if the view doesn't exist, whether there are access requirements on the deployment, or the exact return format beyond listing the fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in a single sentence. It efficiently names what is returned and the target resource. Slightly short given it could mention the deployment parameter, but the schema handles that. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 params, one required, no output schema, no nested objects). The description plus a fully-covering schema adequately covers the purpose. The schema references sibling tools for enumeration (ise_dc_list_views, ise_list_deployments), adding useful context. For a metadata inspection tool, this is reasonably complete, though it could note the relationship to querying views afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The view parameter has a helpful note about using ise_dc_list_views, and deployment has detailed guidance on name/slug/number formats. The description itself adds minimal param detail but the schema fully documents both. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get), the resource (Data Connect view), and the specific output (column details: name, type, description, and time column). This distinguishes it from siblings like ise_dc_list_views (which lists views), ise_dc_view, and ise_dc_query, giving it a distinct and specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies an exploratory/inspection use case (examining schema before querying), and the input schema references sibling tools (ise_dc_list_views for view names, ise_list_deployments for deployment). While this context is present in schema descriptions rather than the tool description, it does guide when to use this tool. No explicit exclusion criteria or alternatives are named in the description itself.
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 exist, so the description carries the burden. It states this is a list operation (read-only implied by 'List...views') and notes it exposes data not available elsewhere. However, it doesn't disclose pagination behavior, whether all views are returned in one call, caching, or performance characteristics. For a list tool this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. Front-loaded with the verb and resource, followed by return content and usage context. The 'Starting point' phrase conveys more meaning than several longer sentences would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional fully-documented parameter, no output schema, and no nested objects, the description is complete. It covers what's returned, when to use it, and the deployment parameter is fully handled by the schema. No output schema means the return-content note (descriptions, column counts, time columns) is valuable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single optional 'deployment' parameter is fully described in the schema including how to reference deployments (name/slug/number) and that omitting it uses the default. The description adds no parameter-specific semantics beyond what the schema provides, which is the appropriate baseline given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'List all Data Connect database views' with return content specified (descriptions, column counts, time columns). The 'Starting point for reporting/historical/aggregate questions' phrase contextualizes purpose. Distinguishes from siblings like ise_dc_view (single view) and ise_dc_describe (schema description).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames this as a starting point for reporting/historical/aggregate questions and notes data no higher surface exposes. Doesn't explicitly name alternative tools or provide when-not-to-use guidance, but 'Starting point' implies it precedes ise_dc_view/ise_dc_query. Could name specific sibling alternatives more explicitly.
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 behavioral disclosure burden. It does disclose that this is a read-only list operation ('List') and that it returns live configuration (not report data), and pagination is mentioned. However, it doesn't describe the response format, what happens with oversized or unavailable resource types, or whether authentication/permission requirements vary by resource. The live-vs-report distinction is genuinely useful behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence plus a short parenthetical that adds real value (the live-vs-report distinction and pointer to ise_ers_resources via the schema). Zero waste, front-loaded with the core purpose. Perfectly proportional to the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward paginated list tool with well-documented schema parameters (75% coverage), this is complete. It conveys the essential distinction from report tools, notes pagination, and the schema enum of ~100 resources plus the deployment selector is well-documented in the schema itself. With no output schema and no annotations, the description could add a bit more on return format, but overall this adequately handles the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the schema already provides descriptions for size ('Page size (max 100)'), resource ('ERS resource name. Use ise_ers_resources to see all with their supported operations.'), and deployment ('Target ISE deployment...'). The description adds only the pagination and live vs report context, but the schema handles parameter documentation adequately. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'List all objects of an ERS resource type (paginated).' It uses a specific verb (list) plus a specific resource type (ERS resource), and crucially distinguishes itself from the ise_dc_* report tools by noting ERS = live configuration, which aligns with the purpose. The description differentiates from siblings nicely since there are numerous ise_ers_list_<specific> tools and ise_dc_* 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes 'for reports use ise_dc_* (Data Connect)', giving a clear alternative for a different use case. It announces pagination behavior. However, it doesn't explicitly state when NOT to use this (e.g., when a type-specific ise_ers_list_<resource> tool would be better), though the parenthetical hint partially covers the alternative 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. The [DESTRUCTIVE] tag and the confirm parameter description clearly disclose that this is an irreversible operation requiring explicit confirmation and an environment variable (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1). This is strong behavioral disclosure for a destructive tool, though it doesn't detail what the response returns or downstream impact of deleting a cert.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single line with clear tags and endpoint reference. Compact and front-loaded with the DESTRUCTIVE warning. No wasted words, though it conflates multiple pieces of info without line breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity is moderate (3 params, 1 required, no nested objects, no output schema). The description plus schema covers the purpose, destructive nature, confirmation gate, and deployment targeting. Given no output schema and a destructive operation, slightly more detail on result/return would help but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all three params. The description itself doesn't add parameter meaning, but the schema descriptions are rich, especially for confirm (explaining the destructive gate and env var) and deployment (multiple accepted formats and pointer to ise_list_deployments). The id param is minimal (just 'Path parameter'), which could be improved but is understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), resource (trusted certificate), and identifies by ID with the HTTP endpoint shown. The [Certificates] tag distinguishes it from system/csr cert operations, though the sibling set includes several cert tools, so the scope distinction is somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the exact resource type and ID-based selection. The confirm requirement and deployment targeting are explained in the schema descriptions. However, there's no explicit when-to-use vs alternatives (e.g., when to delete vs update a trusted cert), no mention that deletion is irreversible beyond the [DESTRUCTIVE] tag, and no statement of when not to use this 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?
There are no annotations provided, but the description adds some behavioral context: the tool queries views with read semantics, and the 'days_back' behavior (using the view's time column) is disclosed in the parameter description rather than the main description. The description does not clarify rate limits, pagination behavior, query timeout, or what happens on invalid view names. For a query tool with no safety annotations, the description carries more burden, and while not misleading, it's fairly thin on behavioral details beyond 'query'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that packs purpose and usage guidance without fluff. It front-loads the core action ('Query any Data Connect view') and follows with options and usage differentiation. It could arguably be a 5, but the description relies on the schema heavily and doesn't summarize the view enumeration or deployment parameter, slightly extending the ambiguity of an already complex tool with 70+ enum values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description is reasonably complete. It covers the core function, the optional filtering capabilities, and the key differentiation from sibling tools. The 100% schema coverage compensates for parameter documentation, and the cross-references to ise_dc_list_views and ise_list_deployments add completeness. However, it does not describe the return format/shape of results (though no output schema exists), and for a tool with 70+ enum view options some guidance on which views map to which data would help. The complexity is moderate given the schema handles parameter semantics well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters well (e.g., limit default/max, filter_op enum semantics, deployment resolution order). The description adds general context that filter/sort/limit/days_back are supported but relays on the schema for specifics. The reference to ise_dc_list_views for the enumeration and ise_list_deployments for deployment choices is useful cross-tool guidance. Given complete schema coverage, the baseline of 3 is appropriate; the description adds modest supplementary guidance via cross-tool references.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') with a specific resource ('any Data Connect view') and scope ('with optional filter/sort/limit/days_back'). It clearly states the purpose: retrieving reporting/historical/aggregate data from Data Connect views. The description also distinguishes this from siblings by explicitly saying 'for current configuration state prefer Open API/ERS', differentiating it from the many ise_ers_* and ise_openapi_* 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use for reporting/historical/aggregate data, and an explicit 'when not to use' instruction ('for current configuration state prefer Open API/ERS'). This clearly delineates when this tool should be selected over the numerous sibling tools like ise_ers_search_networkdevice or ise_openapi_radius_* tools. The differentiation between historical/reporting data (this tool) and current config state (Open API/ERS) is exactly the kind of guidance that prevents mis-selection.
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?
The description explicitly documents the destructive nature and the confirm-flag requirement, including the server-side environment variable gate (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1) and the refusal behavior when not enabled. While no annotations are provided, the description carries its burden well by disclosing the two-step safety confirmation required for execution. The deployment targeting behavior is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with a clear destructive warning prefix, endpoint path, and resource type. The param-level details are appropriately placed in the schema. It's efficient, but the front-loaded [DESTRUCTIVE] tag and endpoint string are slightly dense; still, nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and no annotations, the description effectively covers the identification of the resource (ID + hostname), the safety requirements (confirm flag + env variable), and deployment targeting. The main gap is that it doesn't describe what happens on success/failure or whether the operation is reversible, but for a delete operation the destructive framing already sets expectations. The nested 'data' object param is unexplained in the description, but the schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds value on the 'confirm' parameter by explaining the destructive-operation requirement and environment variable gate beyond its basic boolean default. The 'deployment' parameter also gets useful context about name/slug/number formats and the sibling list tool. However, core path parameters (id, hostName) get no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete System Certificate by ID and hostname' with the specific HTTP endpoint and resource type labeled 'System Certificate'. The verb (Delete) + resource (System Certificate) + identifying parameters (ID, hostname) are all explicit, and the endpoint path is provided for precision. It distinguishes itself from sibling cert tools (trusted certs, CSR) by specifying 'System Certificate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [DESTRUCTIVE] tag clearly flags when this should be used cautiously, and the confirm parameter documentation explains that it must be set to true and that destructive tools must be enabled at the server level. However, it doesn't explicitly contrast with the import/export/list/get sibling cert tools or explain when one would choose deletion vs other cert operations, though the destructive framing implies prudent use.
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?
The description goes beyond annotations (which are absent entirely) by prominently marking the tool as [DESTRUCTIVE] and explaining the confirm=true requirement plus the CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1 server-side gate. This is strong disclosure of the destructive operation behavior and the confirm mechanism requirements. It doesn't detail error handling or response format, but the destructive safety profile is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the [DESTRUCTIVE] warning, which is appropriately prioritized. It packs purpose, usage scope, example, and spec reference into two sentences without fluff. Slightly more behavioral detail about execution preconditions would be beneficial but the structure is sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw passthrough tool with no output schema, the description conveys the essential context: it's a generic escape hatch, requires method+path, and needs an example. The confirm field and deployment guidance are documented in the schema. It's complete enough for an agent to invoke this correctly, though it could note that responses follow OpenAPI spec conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so most parameters (path, method, confirm, deployment) are already documented in the schema. The description adds the confirm requirement detail and deployment semantics in the schema. The description text itself adds the example path format ('/api/v1/certs/system-certificate/<host>') which aids understanding. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Raw Open API passthrough — call ANY /api/ endpoint not covered by a typed tool.' It specifies the verb (call), resource (any /api/ endpoint), and the key scoping that distinguishes it from the many typed sibling tools. The example path and live spec URL further clarify intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames this as the fallback for endpoints 'not covered by a typed tool,' which is clear usage guidance. It names the deployment selection option and points to ise_list_deployments. It does not explicitly list when NOT to use it or name specific alternatives, but the sibling set (typed ise_openapi_* tools) makes the distinction reasonably inferable.
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 full behavioral burden. It discloses that probe is read-only ('read-only live connection'), spells out the exact probe actions (ERS GET + Data Connect 'SELECT 1'), and states the reporting behavior (EVERY missing field/credential at once with exact fix command). This is strong disclosure for a tool with no annotations, though it stops short of describing return format or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose (check config + credentials, report all missing at once) and packs behavioral detail efficiently. It's longer than a pure one-liner but every clause carries distinct information; no filler or redundancy. Could arguably be split into two sentences for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with only 2 params, no output schema, and no annotations, the description explains the trigger conditions (probe default), the side effects (read-only live connection), and the exhaustive-reporting behavior. This is reasonably complete given the tool's moderate complexity, though it doesn't describe what the output looks like (e.g., a summary of found vs missing) since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — both parameters (probe, deployment) have descriptions in the input schema. The description adds detail to 'probe' by specifying the read-only nature and concrete probe actions, and to 'deployment' via the omit-for-default note. The description's added value over the schema is modest but real, aligning with the baseline-3 expectation for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Check') plus resource ('deployment's configuration and credentials'), and clearly states distinct behaviors: reporting missing fields/credentials with exact fix commands, and conditional live probe. This clearly differentiates it from siblings like ise_list_deployments (listing only), ise_add_deployment, or ise_ers_get_* tools which fetch specific ERS 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when it performs a live probe (when nothing is missing AND probe is true) and that probe=true is the default. However, it doesn't explicitly state when NOT to use it or contrast with alternatives like ise_capabilities or ise_list_deployments. The deployment parameter guidance ('Omit for the only/default deployment') provides useful context, aligning with ise_set_default_deployment sibling semantics.
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 full behavioral burden. It clearly discloses 'Red-only — does NOT modify the cache,' which is critical for agents to know this is a safe read operation. It also discloses the network dependency for 'dc' (re-scraping Cisco DevNet), which is valuable behavioral context. It doesn't detail output format or failure modes, but the safety disclosure is the most important element and is well handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently packed. The first sentence states the purpose and behavior precisely, and the second sentence provides the critical read-only safety disclosure plus the network caveat. Zero wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diff tool with 1 optional param, fully documented schema, and a clear read-only disclosure, the description is largely complete. It explains what catalogs can be checked, what it produces (added/removed/changed entries), its non-destructive nature, and its network requirement. It could elaborate on the return/report format, but given the tool's simplicity this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'only' parameter ('Comma list of catalogs to check: ers,dc,openapi') and its default. The description of the tool does not add further parameter-level detail beyond what the schema provides, which meets the baseline of 3 for full schema coverage. The parameter semantics are adequately served by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Check the local catalog cache against the current upstream sources... and report added/removed/changed entries.' It clearly distinguishes this from siblings like ise_catalog_info (which presumably shows catalog content, not diffs) and the many resource-list tools. The scope is precise and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it (to diff local cache vs upstream) and notes that 'dc' requires network access. It doesn't explicitly name alternative tools to use instead, though siblings like ise_catalog_info are implied competitors. The network-requirement caveat for 'dc' provides useful context on when NOT to run it (offline).
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 of behavioral disclosure. The description indicates this is a read-only operation ('Show cached catalog provenance'), which is good. However, it doesn't disclose what happens if no catalog is cached (error vs empty output), whether it triggers any refresh, or the format of the output. The word 'cached' is useful, implying no network call. But for a zero-parameter info tool, the behavioral disclosure is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that conveys complete information with zero wasted words. It lists exactly the four data points the tool returns (version, source URLs, generation time, per-surface entry counts) in an efficient, front-loaded manner. No redundancy, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter info tool with no output schema, the description gives a thorough preview of the return contents (four distinct data categories). The tool is conceptually simple (show provenance metadata), so the description covers the key expectations. It could note whether the tool requires a deployment to be set/selected, but given the simplicity of the tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (trivially, since there are no parameters). Per the rubric, 0 params = baseline 4. The description adds meaningful context about what information the tool returns (version, URLs, generation time, entry counts), which helps the agent understand what output to expect even without an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Show cached catalog provenance' with specific details (target ISE version, source URLs, generation time, per-surface entry counts). This is a strong verb+resource pair that clearly differentiates it from siblings like ise_catalog_diff (which compares catalogs) and ise_ers_resources (which lists ERS resources). The term 'catalog' plus 'provenance' makes the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description effectively communicates when to use this tool: when you need to inspect cached catalog provenance metadata. It implies use for debugging catalog state, version checking, and audit. However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., 'use ise_catalog_diff to compare versions'), though the sibling context makes the distinctions relatively clear. No exclusions are stated.
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 behavioral burden. It discloses that the return includes credential status ('whether credentials are set'), which is a useful safety-relevant detail. However, it doesn't disclose whether this read operation could fail, whether credentials are actually shown or just a boolean flag, or any pagination/limits. Given it's a simple list operation, the transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, compact and informative. The first sentence states the purpose and return fields; the second explains downstream usage. Slightly verbose example text ('e.g. List RADIUS policy sets on Deployment 1') but otherwise efficient. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema listing tool, the description covers the essential value: what it lists, what fields are returned, and how to use the results. It's a simple enumeration operation, so the description is reasonably complete. It could mention whether it sorts or filters, but for a plain list tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so semantic explanation of parameters is moot. The description uses the space to clarify how the tool's output (number/name) becomes a parameter value for other tools, which effectively serves the same purpose as parameter documentation by explaining the tool's role in the broader invocation flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List every configured ISE deployment') and clearly enumerates what fields are returned (number, name, slug, host, credentials set). It differentiates from siblings by establishing this as the enumeration tool for deployments, distinct from the individual getter tools (ise_get_deployment) and the setup tools (ise_set_default_deployment, ise_add_deployment, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool: 'Call this to see what is available.' It also instructs the agent to use the returned number/name in any tool's 'deployment' argument, directly showing how the output feeds into other tool invocations. This makes the usage context and downstream relevance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description itself carries the [DESTRUCTIVE] marker and the confirm parameter schema explicitly explains that the server requires destructive tool enabling (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1) plus confirm=true. This is excellent disclosure of mutation behavior, auth requirements, and failure-refusal conditions beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence that packs the destructive warning, raw-passthrough nature, coverage scope, and a concrete path example. Zero wasted words, all high-value information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic passthrough tool with no output schema and 6 params (2 required), the description plus rich schema adequately covers semantics: path convention, safety requirements, deployment targeting. The confirm/deployment/params/data semantics are all covered by the schema. Returns are not documented, but for a raw passthrough that's acceptable since response shape is inherently tool-dependent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83% and the schema already thoroughly documents each parameter (path example, method enum, data, params, confirm safety semantics, deployment selection). The description adds the relative-to-host-root detail for path semantics. With such high schema coverage, baseline 3 is appropriate; the description works with the schema rather than needing to compensate heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'Raw ERS passthrough' for action sub-paths not covered by typed tools, with a concrete example ('POST ers/config/endpoint/{id}/deregister') and specifies the path is relative to host root. This clearly differentiates it from the many typed ise_ers_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's for 'action sub-paths not covered by a typed tool' (e.g. deregister), which tells the agent when to use it versus the typed alternatives. However, it doesn't explicitly list when NOT to use it (e.g., prefer typed tools when they exist), though this is strongly implied by the sibling naming pattern.
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 provided, the description carries the full burden. It discloses that the tool returns a summary of the four API surfaces, their precedence, and the cached catalog version. It does not describe return format or what errors might occur, but for an informational read-only capability tool, this is reasonably complete. The precedence resolution rule is behaviorally useful context not available elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that packs in the four surfaces, their precedence order, the fallback logic, and an explicit when-to-call instruction. It is front-loaded and dense without padding. Slightly long as one sentence but earns its length with substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema, informational tool, the description covers the essential points: what it summarizes, the precedence order, fallback semantics, and when to call it. Given the tool's simplicity and lack of annotations, this is complete for its intended purpose. It could theoretically mention what the cached catalog version is used for, but the sibling ise_catalog_info/ise_catalog_diff tools presumably handle those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema fully reflects this (100% coverage with no fields). Per guidance, 0 parameters gives a baseline of 4. The description's value lies entirely in explaining what the no-arg call returns, which it does well: the four surfaces, precedence, and cached catalog version.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes the four Cisco ISE API surfaces, their precedence order, and the cached catalog version. It specifies a concrete verb+resource (summarize ISE API surfaces + catalogs) and its scope, distinguishing it from sibling tools like ise_ers_get or ise_openapi_* which perform specific operations on individual surfaces. The description makes clear it's a meta/capabilities tool, distinct from substantive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first when unsure which tool family to use,' providing direct guidance on when to invoke it. It also encodes the fallback logic (use the highest precedence surface, fall back on failure), which is a concrete usage rule for the agent. This is an explicit when-to-use instruction that effectively differentiates this from the operation-specific sibling tools.
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 provided, so description carries full burden. It discloses passwords are NEVER passed here, that it returns terminal command(s) for setting passwords afterward, and reports every missing/invalid field at once. It doesn't state whether the operation is reversible (could be removed via ise_remove_deployment) or whether it requires special auth, but the key behavioral traits (secrets handling, batch validation, return format) are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a leading summary sentence, then a GUIDED FLOW block with numbered decision prompts. Each sentence earns its place. Slightly over the line in length given the guided-flow detail, but the structure (summary + numbered guide) aids quick scanning and is arguably necessary given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very complex tool (20 params, 2 required, no output schema) yet coverable via description: the return format is specified (terminal commands for password), the validation behavior is stated, the certification decision tree is fully enumerated. The only minor gap is no explicit statement about whether this is idempotent or what happens on duplicate name, but overall this is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, and several params have rich descriptions (ca_cert_path explaining certifi/OS trust behavior, verify_ssl explaining MITM implications, dataconnect_os_trust explaining cert handling). The description adds critical cross-parameter context about dataconnect_cert_path vs dataconnect_os_trust tradeoffs and dataconnect_host-by-default behavior not fully in the schema. Description complements rather than duplicates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Add a new ISE deployment to the registry'. Distinctly differentiates from siblings (ise_list_deployments, ise_update_deployment, ise_remove_deployment, ise_set_default_deployment) by establishing it's the creation operation. Also clarifies it handles non-secret fields and returns password-setting commands, which no sibling mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit GUIDED FLOW section telling the agent to gather optional surfaces by asking the user rather than assuming. Gives concrete decision branches (Data Connect vs ERS API, same node vs separate MnT, self-signed vs CA-signed cert, MAPI vs DC preference). This is exemplary guidance on when and how to use vs alternative options like monitoring_enabled vs dataconnect.
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 full burden. It transparently discloses that it returns a primary_surface plus a fallback_order, and explains the decision logic based on operation type. It doesn't detail edge cases or failure behavior (e.g., ambiguous requests, ties), but for a recommendation tool the decision criteria are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all substantive, front-loaded with the core purpose. Every sentence earns its place: purpose, precedence rule, surface mapping rules, and output format. Slightly dense but no waste and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a router/orchestration tool with a single free-text param and no output schema. The description fully explains the routing logic, the surface precedence hierarchy, when to pick each surface, and what it returns. Given the tool's complexity (needs to disambiguate across dozens of sibling tools), this is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'query' parameter is fully covered at 100% schema coverage, so the schema already documents it. The description clarifies the expected input format ('natural-language request') and contextually explains what the query should express, adding meaning about the query's role in the routing decision.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: recommends which ISE surface and concrete tools to use given a natural-language request. It specifies distinct verbs (recommend, honor) and resource (ISE surface selection), and clearly differentiates itself from the many concrete ise_* sibling tools since it's the routing/orchestration tool rather than an individual operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent when/when-not guidance. It explicitly defines precedence (Open API > ERS > Data Connect > Monitor API), provides concrete routing rules for each surface (current config/state → Open API/ERS; reporting/historical/aggregate/audit → Data Connect; legacy live session/CoA → Monitor API), and names the exact tool prefixes (ise_dc_*, ise_mnt_*) to choose among.
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 full burden. It discloses key behaviors: partial updates ('Only the fields you pass change; everything else is preserved'), the reslug identity-change side effect ('moves its stored credentials'), and details about password preservation. It also explains TLS/CA trust behavior for ca_cert_path. Strong behavioral disclosure, though it doesn't cover every parameter's runtime 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed but every sentence earns its place. Each sentence delivers a distinct piece of guidance: what it does, partial-update semantics, reslug behavior, password exclusion and alternative, and error reporting. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 21 parameters, no output schema, and zero annotations. The description addresses the key risks: partial updates, reslug/rename behavior, password handling, and TLS/CA behavior. It doesn't explain return value or error format fully ('Reports any remaining gaps' hints at output), but given the complexity, the description covers the most critical behavioral gaps well. Some param interactions (dataconnect variants) could be richer but the description is solid for the risk profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description itself adds semantic value for several params: the reslug interplay with name change, ca_cert_path's explanation of httpx certifi behavior and the '' clear pattern, dataconnect_host's fallback behavior, dataconnect_os_trust's CA-store validation. The description adds meaning beyond the schema for many parameters, though the 33% uncovered params (dataconnect_sid, dataconnect_wallet_path, etc.) aren't explained in the description either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Modify an EXISTING deployment's non-secret settings.' It clearly states the verb (modify/update), the resource (deployment), and scope (non-secret settings). It distinguishes from siblings by noting this is for existing deployments, complementing ise_add_deployment, and it explicitly differentiates from set-credential for password handling. Strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: fixing typos (wrong host) or adding information later (enable Data Connect). It explicitly says when NOT to use it for passwords ('Passwords are NEVER set here') and points to the alternative (terminal command). It also explains the reslug requirement clearly with guidance on what happens if not satisfied ('rejected with guidance'). This is exemplary usage 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?
With no annotations provided, the description carries the full transparency burden. It does well: declares read-only, discloses that SQL comments are rejected, and states the FROM/JOIN target constraint. However, it doesn't disclose behavior for invalid SQL (error format), row-limit enforcement, or performance characteristics beyond the row-limiting advice, though the constraint warnings add meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, zero filler. Every sentence conveys a distinct operational constraint: purpose, target/view restrictions, and row-limiting requirement. Front-loaded with the primary purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw query tool with 100% schema coverage, 2 params, and no output schema, the description covers purpose, constraints, valid targets, and deployment selection. The sibling context of ise_dc_list_views/ise_dc_describe further reduces the need to enumerate all views inline. Complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the `deployment` param semantics beyond the schema (name/slug/number formats) and cross-references ise_list_deployments. For the `sql` param, the description reinforces the single-SELECT and row-limit constraints, adding operational meaning to the example schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Run a custom read-only SELECT against Data Connect (advanced)'. It establishes this as a raw/advanced query tool distinct from the many specialized ise_dc_view_* siblings, which provide pre-built canned views of the same underlying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent guidance: states restrictions explicitly (single SELECT only, SQL comments rejected, every FROM/JOIN must be a Data Connect catalog view), advises row limiting (FETCH FIRST n ROWS ONLY), and cross-references ise_dc_list_views for valid targets. It also distinguishes it implicitly as the 'advanced' raw option alongside the structured view tools.
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 full burden. It flags '[DESTRUCTIVE]' in the description itself, discloses that the server requires an operator to enable destructive tools (CISCO_ISE_MCP_ALLOW_DESTRUCTIVE=1), and notes it 'Returns raw XML.' However, it could further clarify what operations are destructive vs. read-only (e.g., a GET passthrough vs. a DELETE), though the confirm-flag mechanism partially covers this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste, front-loaded with the critical DESTRUCTIVE warning and primary purpose. Every sentence earns its place: what it does, an example, and the legacy alternative guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw passthrough tool with 5 params and high schema coverage, the description provides complete guidance. It covers the destructive nature, the confirmation mechanism, the deployment targeting, and the reporting alternative. The absence of an output schema is partially mitigated by 'Returns raw XML.' Given its passthrough nature and rich schema, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (high), so baseline is 3. The description adds value beyond the schema by explaining the confirm parameter's destructive requirement and dual-layer enforcement (tool-level confirm plus environment variable). It also clarifies deployment param semantics (name/slug/number, omit for default, reference to ise_list_deployments). The params param and method enum benefit from the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Raw Monitoring (MnT) passthrough — call ANY /admin/API/mnt/ endpoint not covered by a typed tool.' It provides an example endpoint and explicitly distinguishes it from typed tools (ise_mnt_*, ise_dc_*) that already cover specific endpoints, making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'call ANY /admin/API/mnt/ endpoint not covered by a typed tool'. It also gives a clear exclusion and alternative: 'MnT is legacy; prefer Data Connect (ise_dc_*) for reporting.' This distinguishes it from the many typed ise_mnt_* and ise_dc_* sibling tools.
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:

[![cisco-ise-mcp MCP server](https://glama.ai/mcp/servers/TheOtherBrad/cisco-ise-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TheOtherBrad/cisco-ise-mcp)

Score Badge

Copy to your README.md:

[![cisco-ise-mcp MCP server](https://glama.ai/mcp/servers/TheOtherBrad/cisco-ise-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TheOtherBrad/cisco-ise-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/TheOtherBrad/cisco-ise-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server