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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description still adds substantial domain behavior: the irreversible fold, the dependency of analytics on per-day records, and that the session boundary is decided server-side with the client flag untrusted. The "IRREVERSIBLE" warning describes the underlying config semantics rather than this call, so it is context, not a contradiction.

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?

Purpose is correctly front-loaded and the folded-history explanation is relevant, but the passage runs long for a single-field getter and mixes in write-side advice (DailyWindowDays thresholds, nulls) that is tangent to a read call.

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?

With no output schema, the description does need to convey what 'Usage' contains, and it does so by explaining the retention window, folding behavior, and SessionIdleTimeoutMinutes. Coverage is good, though the misplaced write-side instructions add noise rather than fill a 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 there is a single required title_id, so the schema already carries parameter meaning. The description adds nothing about title_id, making the baseline 3 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?

The opening states a precise verb+resource+scope: "GET ONLY the 'Usage' field of TitlePublicConfigurationModel." This clearly differentiates it from broad siblings like get_title_data and from the mutating save_usage, so an agent can select it without opening the schema.

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?

"GET ONLY" implies the read-scoped counterpart of save_usage, but no alternative or condition is explicitly named. The closing advice ("Leave every field null unless you have a specific reason") reads like write-side guidance and doesn't tell an agent when to call this getter versus get_title_data.

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