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

Annotations already declare non-read-only, idempotent, non-destructive and closed-world, so the description's job is to add context, and it does: it says the source, catalog, objective and credit ceiling are frozen, that approval links gate positive ceilings, and crucially that 'this call never invokes a model or provider'. That last point materially changes agent expectations about cost and side effects. It stops short of describing what the prepared session object contains, though the output schema covers that.

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?

Five sentences, front-loaded with the action and scope, with no filler or restatement of the title. Some sentences are dense and jargon-laden ('canonical native toolsets', 'the exact source, catalog, objective ... are frozen'), which costs a little readability but not much length.

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 15-parameter, conditionally-constrained tool with an output schema and annotations, the description covers the high-risk surfaces: approval gating, video authorization, GenAds account selection and the no-model-invocation guarantee. What is missing is the lifecycle relationship to start_studio_session and any note on how request_key supports the declared idempotency, but nothing essential to calling it correctly is absent.

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 60%, so the baseline sits at 3 and the description only marginally exceeds it. It adds the notion that expected_revision, expected_catalog_version, maximum_credits and the brief are 'frozen' at preparation time, which explains why those parameters are required, and it clarifies that GenAds homes and advertisers must be explicitly selected. It says nothing about workspace_id, request_key or the enum's other studio kinds, leaving several parameters documented only by the schema.

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 states a specific verb and resource ('Prepare a native session') and scopes it to 'any studio named by studio_kind', with the additional detail that all canonical native toolsets and instructions are attached. It does not distinguish itself from the adjacent siblings start_studio_session, prepare_studio_task or start_studio_task, so an agent cannot tell from the text alone which of these to reach for.

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?

Conditional guidance is present but is about approvals rather than tool selection: zero-credit sessions need no paid approval, positive ceilings need the creator approval link, video requires include_video plus separate approval, and native_policy is restricted to Film/Series/GenAds Social automation. There is no statement of when to use this versus start_studio_session or prepare_studio_task, so routing is left to inference.

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