ise_ers_search_guestuser

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.

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.

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.

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.

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.

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.