rsc_get_sla_domains

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true already covering the safety profile, the description still adds real behavioral detail: the is_retention_locked filter is applied client-side after fetching, and `count` reflects the server-side total before that filter — a footgun an agent would otherwise trip on. It also discloses the default/max limit, which the schema does not. Missing: any auth/permission or rate-limit notes.

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?

Front-loaded with purpose, then structured Identity/Objects/Coverage/Retention/Frequency/Archival/Replication and Args/Returns blocks — no filler and every section maps to caller-relevant information. It is longer than a typical description, but that length is justified by the 0% schema coverage; only the per-field result bullet list pushes slightly past what a caller needs before invoking.

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?

There is no output schema, and the description compensates by documenting the return envelope (count, returned, truncated flag) plus the contents of each sla_domains record, including the ambiguity that count is pre-client-filter. Combined with full per-argument semantics, an agent has everything needed to call this correctly and interpret the result.

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 0%, so the description carries the entire burden and does: name_contains is labeled server-side, object_type is given concrete SlaObjectType enum examples (including K8S_OBJECT_TYPE, which the prose flags as supported), cluster_id is scoped to cluster-associated SLAs, is_retention_locked has tri-state semantics (True/False/omit), and limit states default 50 and max 200 beyond the schema's bare default.

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?

Names a specific verb+resource ("List SLA Domains (protection policies) configured in RSC") and immediately defines the domain in the product's own vocabulary. It also enumerates the concrete question types it answers (counting, protecting a workload type, retention-locked SLAs, replication/archival configs), which makes it unmistakable against the generic siblings like rsc_get_workloads or rsc_get_clusters.

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?

Gives unusually rich context: "Use for any question about protection policies" with named filtering dimensions, then a second sentence listing alternative intents (counting, mapping workload types, retention lock, replication/archival lookup). It stops short of naming a sibling to prefer in a specific case or stating when NOT to use it, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.