ise_openapi_radius_exception_list

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.

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.

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.

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.

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.

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.