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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's main job is the pricing semantics. It does add real value there: a zero price is valid only for a server-confirmed owner exemption, and 'Free' means no picture will be made, which is a non-obvious side-effect claim. It does not say how long a quote or pricingVersion stays valid, or what happens when the caller disagrees with the returned price, so it adds context without fully covering the quote lifecycle.

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 outcome (price and pricingVersion), then the tier default, then the exemption rule, then the approval gate and sibling routing; each sentence carries a distinct constraint. Minor deduction because 'Free: changes nothing and makes no picture' is telegraphic and relies on context to parse.

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 states what comes back (price plus pricingVersion) and covers the zero-price edge case and approval gating. It leaves out quote validity or expiry and whether pricingVersion must be passed to the generate call, both of which matter for a pricing tool an agent must act on.

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%, so all three parameters are already documented; the description's tier guidance ('premium is the default') largely repeats the pictureTier schema text. It adds no detail on imageUrls, even though the schema calls out HTTPS evidence-locator requirements the description never echoes. Baseline 3 is appropriate for a case where the schema does the documentation work.

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 the exact verb and resource ('Get the current account price and pricingVersion for one new GPT Image picture'), and explicitly marks the boundary with sibling quoting tools: photo edits, background removal, and upscaling have their own quote tools. An agent can distinguish this from soclo_image_photo_edit_quote, soclo_image_remove_background_quote, and soclo_image_upscale_quote without opening any 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?

Specifies the workflow ordering ('Show the price and wait for the owner's approval before soclo_image_generate') and the selection rule for the tier ('Premium is the default; use Standard if the owner chooses it'). It also names exclusions: other image operations must use their own quote tools, so the agent will not call this for edits or upscaling.

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