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

Beyond the annotations, it discloses that nothing is bought or paid and that sellers may be told a buyer is interested, which is material side-effect information not captured by destructiveHint=false. It also details idempotency concretely (a repeat call returns the first requestedAt and Growwer is not re-asked), and distinguishes pre-flight refusals (retryable with the same requestId) from growwer_media_request_failed and growwer_media_host_invalid, explaining what state each leaves behind.

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 purpose and precondition are front-loaded, and nearly every sentence carries substantive content. However, it is a single dense paragraph of run-on sentences, and the "new preview and a new requestId" retry guidance is repeated across two error-code explanations, which slows scanning on a tool an agent will call under confirmation pressure.

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?

An output schema exists, so return values need no explanation; what the description must supply — prerequisites, the confirmation gate, side effects, idempotency, and every named failure mode with its recovery path — is all present. There is no material gap for an agent to call this correctly.

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?

With only 40% schema description coverage, the description compensates for the undocumented organizationId/projectId by explaining that the project maps to the Growwer project whose website matches ("the first one, as get_growwer_offers picks it"), and it defines the confirmationToken workflow and the host-invalid condition. The requestId retry rule is largely a restatement of the schema's own description, so it adds less than the rest.

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 first sentence names a specific verb and resource ("ask Growwer ... to find media on one source host for a project"), identifies the external system as a sponsored-content marketplace, and scopes it to the owner's connected account and the matched Growwer project. This is clearly distinguishable from get_growwer_offers and get_project_sources, which it references as different steps.

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 states the precise precondition for use ("Use it on a host get_project_sources lists with a growwer block whose canRequest is true") and names the alternative path — making the request on Growwer's own site — along with the exact error codes that signal it. It also spells out the mandatory confirmationToken flow (preview_operation first, show plan, wait for explicit user agreement).

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