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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description still adds real value: it discloses the notice-period and warm-up constraints, the 60-day horizon, and the 'free' cost. It omits auth/permission needs and rate limits, so a 4 rather than a 5.

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?

Front-loaded with the core purpose and efficient overall, but the parenthetical explanations for earliestQueueDate are dense and could be trimmed. Every clause still carries useful information, so minimal waste.

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 correctly takes on the burden of enumerating the returned fields (earliestQueueDate, firstOpenDay, dailyCap, creditsPerPost, countsByDay/fullDays) plus the warm-up/notice semantics needed to interpret them. Nothing an agent needs to call and read the result is missing.

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?

Only one parameter (accountId) with 100% schema description coverage, so the schema already does the documenting. The description conveys that the account is a 'hosted / managed' one but adds no format or lookup detail beyond the schema's 'Managed account UUID'. 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+resource ('Which days a hosted / managed account can take a post') and immediately names what it distinguishes itself from by pointing at publish_to_managed_account. An agent can identify this as a read-only capacity/availability check 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?

Explicitly prescribes the workflow: 'Call this before publish_to_managed_account to pick a legal queueFor day.' The when-to-use and the downstream tool it feeds are both named, leaving nothing to inference.

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