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

Annotations already cover read-only, idempotent, closed-world and non-destructive semantics, so the description does not need to restate safety. It earns credit for disclosing a non-obvious behavioral quirk: the default 'all' silently omits demand_signals and martini_growth_checks, which must be requested by name. It does not describe response shape, but no output schema exists and the section list largely implies it.

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 short sentences, no filler, with the identity of the tool front-loaded and the opt-in caveat placed immediately after the usage trigger. Every sentence carries information an agent needs.

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 zero-required-param, read-only, single-enum tool with no output schema, the description gives enough to call it correctly and to understand which sections come back by default. Return-value detail is left implicit, which is the only real gap.

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% and the enum is fully documented, so the schema carries this dimension. The description's remark about 'all' omitting the curator/ops sections restates the schema's field description almost verbatim, adding emphasis rather than new meaning. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Get the mcp.film operating pulse') and enumerates the contents: catalog freshness, verification queue, curator agenda, machine-readable surfaces. This distinguishes it from the get_film_*/list_film_* siblings, which are all single-object or listing tools. It stops short of naming a sibling to contrast with, so a 4 rather than 5.

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?

'Use this before deciding what to update next' gives a concrete decision context rather than vague guidance. The note about opt-in sections tells the agent how to narrow the call. No explicit when-not or named alternative, so not a 5.

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