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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the agent knows this is a mutating, repeatable, potentially destructive operation. The description adds essentially nothing beyond that: it does not warn that disabling a link breaks an existing shared URL, that team sharing sends no invitation, or that Audience marketplace listing is unaffected — all of which appear only in the parameter schema. With annotations already covering the safety profile, this sentence adds minimal new behavioral context.

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 front-loaded sentence with no filler and no redundancy. It is efficient, though bordering on under-specified rather than merely concise — the whole definition is one clause.

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?

A rich schema, full annotations, and an output schema relieve the description of much of its burden, and sharing toggles are conceptually simple. Still, for a destructive, open-world mutation with five parameters and nested object selection, the description omits who is permitted to call it and what observable effect toggling has on existing recipients. Adequate but with clear gaps.

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 100%, so every parameter including the nested study/audience id-or-name objects is fully documented in the schema, which sets the baseline at 3. The description contributes no additional parameter meaning; it only implies the link/team toggles exist without naming them or explaining the 'send link, team or both' combination rule. Baseline 3 is therefore correct.

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 gives a specific verb ('turns ... on or off') and names both resources (Study, Audience) plus both sharing channels (public link, team sharing). It is clear and distinguishes the tool from any sibling, since no other tool touches sharing state. It stops short of a 5 because it never contrasts itself with adjacent tools like update_item or the listing tools, though none of them overlap meaningfully.

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 offers no when-to-use guidance, no prerequisites, and no alternatives. It does not say that only the owner may change team sharing, that an owner/admin role is required, or what to do when both link and team need updating. The schema parameter text carries some of this, but the description itself supplies no routing or precondition information.

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