zia_get_network_svc_group

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent is aware this is a bounded read operation — the description doesn't contradict this (no annotation_contradiction). The description does add one piece of behavioral value: 'with members' tells the agent the response enriches the group with its member list. Yet it adds no detail on error behavior, pagination, permissions, or the return contract, and given the annotation safety net, the description's added transparency burden is light but only partially met.

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?

A single 12-word sentence with every word earning its place: verb (Get), entity (ZIA network service group), scope (single... by ID), and response hint (with members). No filler, no repetition of the namespace prefix, and the term 'single' does double duty by disambiguating from the list sibling. This is a model of efficiency.

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?

Given the tool's low complexity — one self-describing parameter, a clean readOnly annotation, and no expected output schema — the description covers the essential contract: what it fetches (a single group by ID) and what comes back (members included). The sibling landscape is crowded (zia_get_network_service, zia_list_network_svc_groups), and the description is just specific enough to navigate it. It could add an example ID or format note but doesn't need much more for a tool this simple.

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 per the rubric the description carries the burden to compensate — but it does not explain the group_id parameter beyond 'by ID,' which only restates what the parameter name implies. No format, example, or constraint is given for group_id. The description's phrase 'by ID' does connect the parameter to its semantic role as an identifier, saving it from a 1, but with a single parameter left effectively undocumented at 0% coverage, this is below minimum viable.

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 uses a specific verb+resource pattern ('Get a single ZIA network service group by ID with members') that clearly distinguishes it from the sibling 'zia_list_network_svc_groups' tool via the singular 'a single' and 'by ID' qualifiers. The 'with members' phrase adds a helpful hint about the response shape. However, unlike the TDQS high-water mark, it doesn't explicitly name the alternative ('use list_network_svc_groups instead'), so a slight deduction is warranted.

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?

Usage context is only implied — the 'by ID' qualifier and singular form signal single-resource retrieval versus the plural list sibling, and the namespace distinguishes service groups from services. However, there is no explicit statement of when to use this versus zia_list_network_svc_groups, no exclusions, and no prerequisites mentioned. This meets the 'implied usage' bar (3) but provides no explicit alternatives or when-not-to-use guidance.

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