ise_route

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.

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.

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.

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.

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.

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.