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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds real context on top: it acts on the member's behalf under the purchases:start permission scope, payment happens on Stripe and never through the assistant, and an unconnected member triggers a sign-in prompt. The embedded untrusted-content warning is boilerplate but relevant to a tool that surfaces member-written text. Nothing contradicts the annotations.

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?

The first two sentences say nearly the same thing twice ('as the boost screen shows them' and 'as the boost screen lists them'), and the bolded title is repeated verbatim at the start. The genuinely useful content — scope across entity types, the read-before-purchase instruction, the permission scope, the sign-in behavior — is buried mid-paragraph rather than front-loaded. It is not padded with irrelevant material, but it could shed a sentence without losing information.

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 parameters and no output schema, a read-only price lookup needs the description to say what comes back; it does that reasonably, listing boost lengths, prices, the launch price and start date, and the additional entity types covered. It also covers the permission and sign-in prerequisites. The main gap is that no concrete return shape (field names, ordering, currency) is implied, which matters precisely because there is no output schema.

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?

There are zero parameters, so there is nothing for the description to disambiguate and the baseline is high. The description does implicitly define the output surface (boost lengths, prices, launch price, start day, entity types), which is useful given there is no output schema, but that is completeness rather than parameter meaning; I hold it slightly below the 0-param baseline because it adds no per-parameter clarification and is vague about whether the caller can scope to one entity type.

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 the resource concretely: every boost length and its price today, including a launch price and the day a boost starts, plus equivalent prices for contracts, Direct Jobs, quotes, products, services and posts, with the profile list explicitly excluded. That is enough for an agent to distinguish it from mutating siblings like start_boost or start_boost_renewal. The first sentence is essentially the title restated, which costs a bit of precision, and the multi-entity scope is stated loosely enough ('The same prices for…') that an agent may not be certain the tool returns all of them in one call.

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?

It gives explicit sequencing guidance: read this before initiating a boost purchase so the member hears the price first, which ties it to the boost-purchase flow. It also flags the precondition that an unconnected member will be prompted to sign in. It stops short of naming the concrete sibling tools (start_boost, start_boost_renewal, start_paid_ad) that follow it, so the routing is implied via an endpoint reference rather than spelled out.

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