ise_ers_list

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.

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.

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.

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.

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.

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.