ise_ers_search_tacacsprofile

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.

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.

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.

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.

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.

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.