Growwer MCP server

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is known. The description adds one genuinely new fact — the buyer is notified — which is an irreversible outward-facing side effect not visible in the schema. It does not say what happens if the order is not in an acceptable state, nor confirm that acceptance cannot be undone.

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?

One sentence, no filler, and the usage trigger is front-loaded. But the grammar is tangled ('takes an order placed on one of their medias that waits for acceptance'), which costs a re-read and obscures what 'takes' means operationally.

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?

This is a destructive, state-changing tool with no output schema and an undocumented required 'id'. The description covers the happy-path trigger and one side effect but omits error/precondition behavior and the meaning of the primary identifier — the two things an agent most needs before committing an irreversible action.

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 coverage is only 50%: requestId is fully documented in the schema, but 'id' has no description anywhere. The description never mentions 'id' at all, so it fails to compensate for the gap and leaves the agent guessing whether it is the order id, media id, or buyer id.

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?

Specific verb+resource: accepts an order that was placed on one of the seller's medias and is awaiting acceptance, plus the consequence (buyer is notified). It implicitly separates itself from reject/approve siblings via the 'waits for acceptance' precondition, though it never names those siblings. Clear, but differentiation is by implication rather than explicit contrast.

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?

'Use this when a seller takes an order... that waits for acceptance' gives a usable trigger condition tied to order state. However, it never names the counterpart actions (growwer_reject_seller_order, growwer_approve_order, growwer_deliver_seller_order) or states when NOT to use it, so the agent must infer the branch from state alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered, and the description is consistent with them (it is a write, and overwriting existing post fees matches 'destructive'). The description contributes what specifically gets overwritten (post fees) and where the replacement values come from, but says nothing about reversibility, whether existing custom fees are lost, or what happens on failure.

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?

A single sentence that front-loads the usage trigger and gets to the effect without padding. The phrasing is slightly tangled ('the competitiveFees growwer_get_seller_media answers'), but no sentence is wasted.

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?

For a two-parameter destructive write with no output schema, the description covers the trigger, the field mutated, and the value source. It leaves the agent guessing whether it returns the updated media/fees, whether the get call is a hard prerequisite, and how the seller-media id is obtained — gaps that matter more here than for a read-only sibling.

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 only 50%: requestId is fully documented in the schema, but 'id' carries no description. The phrase 'for one of their medias' implies id is a seller-media identifier, but the description never says so explicitly or points to growwer_list_seller_medias/get_seller_media for obtaining it.

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 concrete verb and effect ('sets its post fees') on a concrete resource (one of the seller's medias), and ties the written values to the competitiveFees returned by growwer_get_seller_media. An agent can distinguish this from growwer_update_seller_media (manual fee editing) with reasonable confidence, though the domain jargon ('medias', 'competitiveFees') and the title's near-duplication add mild noise.

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?

'Use this when a seller wants the fees Growwer suggests' gives an explicit trigger condition, and naming growwer_get_seller_media as the source implies the fetch-then-apply workflow. It stops short of stating exclusions — e.g. that this is the wrong tool if the seller wants custom fees (use growwer_update_seller_media instead).

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

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

Adds real context beyond the annotations: the irreversible nature ("cannot be undone"), the financial consequence (the seller is paid), and the human confirmation step before execution. The annotations already flag destructiveHint=true, so this is reinforcing but also enriching. It does not explain the idempotency/requestId replay behavior, though the schema does.

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?

Three short clauses, no waste, with the triggering condition front-loaded before the consequence and the irreversibility warning.

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?

For a destructive, two-parameter mutation with no output schema, the description covers the trigger, the terminal effect, irreversibility, and the confirmation flow. The remaining gap is the undocumented `id` parameter and what a caller gets back on success or failure.

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 coverage is only 50%: requestId is thoroughly documented in the schema, but the required `id` parameter has no description anywhere. The description never mentions parameters at all, so the meaning of `id` (presumably the order identifier awaiting review) is only weakly inferable from "an order that waits for their review."

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 and resource (approve an order's delivery) plus the business outcome: the order finishes and the seller is paid. It is clear what the tool does, though it never names or distinguishes itself from close siblings like growwer_approve_order_draft, growwer_deliver_seller_order, or growwer_reject_seller_order.

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?

Gives an explicit triggering condition: the user has reviewed a delivery that waits for their review and accepts it. That is a clear when-to-use rule, but no when-not-to-use and no named alternative for the rejection path, which exists as a sibling.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond them by naming the downstream consequence — the seller publishes the order — which explains why the call is destructive. It does not mention permission requirements or what happens on an invalid or rejected draft state.

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?

One sentence with no filler, leading with the usage trigger and following with the effect. The phrasing 'a post order that waits for their review' is slightly awkward but not wasteful. Nothing is repeated from structured fields.

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?

For a two-parameter destructive mutation with no output schema, the description covers the when and the consequence, which is the core need. It stops short of clarifying the id parameter's referent and does not indicate what the caller gets back or what error conditions (e.g., draft not in review state) to expect.

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 only 50%: requestId is thoroughly documented in-schema, but id carries no description and the tool description never says what it identifies (order id? draft id?). With half the parameters undocumented and no compensating text, an agent must guess the meaning of the required id argument.

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 and resource: approving the draft of a post order, with the resulting effect that the seller publishes it. An agent can grasp the operation without opening the schema. However, it does not differentiate from the near-identical sibling growwer_approve_order (non-draft approval), so the agent must infer which of the two applies.

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?

The trigger is explicit and precondition-based: use it when the user has read the draft awaiting their review and accepts it. That is clear positive guidance. No exclusions or alternatives are offered, so nothing tells the agent when to prefer growwer_approve_order, growwer_request_order_draft_update, or growwer_refute_seller_order_draft_update instead.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real value beyond them: money returns to the buyer's wallet, the seller is notified of the reason, and a confirmation step precedes the write. It doesn't cover failure modes (e.g., what happens if the seller already accepted).

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?

One tight sentence with the precondition, the effect, and the confirmation requirement all front-loaded; no filler.

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?

For a destructive three-parameter write with no output schema, the description covers trigger, effect, side effects, and confirmation. Minor gaps: no error/precondition-failure behavior and no mention of the id parameter.

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 coverage is 67% and the schema already explains requestId idempotency and the reason length/semantics. The description reinforces the reason's audience ("the seller is told the reason") but says nothing about the required `id`, leaving that to a bare string property.

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 and resource plus a scoping precondition ("cancel an order the seller has not accepted yet"), which separates it from siblings like reject_seller_order or request_order_update. It falls short of 5 only because it doesn't name the sibling alternative explicitly.

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?

Gives a clear triggering condition (user wants to cancel, seller has not yet accepted) and mentions that confirmation happens first, so the agent knows the flow. No explicit when-not guidance or named alternative for already-accepted orders.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it returns a count without listing medias, but does not add further behavioral context such as response shape or permission requirements.

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 definition is a single front-loaded sentence with no filler. The clause after the colon is slightly convoluted, but the overall statement remains compact and purposeful.

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?

For a simple two-parameter read-only count tool with rich annotations and fully described parameters, the description is sufficient. It implies a numeric result via 'how many' but does not explicitly describe the return value, which is a minor gap given the lack of an 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?

Schema description coverage is 100% and both parameters are documented ('The project' and 'The saved filter'). The description reinforces that id is a project and filterId is a saved filter, but adds no syntax or format details beyond the schema.

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 a specific verb and resource: counting catalogue medias matched by one saved filter of a project. It also distinguishes the operation from listing medias and references the sibling growwer_search_project_medias, though the final clause about that sibling is somewhat awkwardly worded.

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 a clear usage condition: use this when you need a count without listing medias. It names the relevant alternative (growwer_search_project_medias) but does not explicitly describe when not to use this tool or any prerequisites.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds the context that makes destructiveness concrete: the price leaves their wallet and nothing is charged without user acceptance. That is meaningful beyond the annotations, though it doesn't address wallet-balance failure modes or what state the created order starts in.

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?

Three sentences, front-loaded with the trigger condition, then the mechanic (price leaves wallet), then the safety constraint (confirmation required). No sentence is redundant.

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?

For a 9-parameter, money-spending mutation with no output schema, the description covers the trigger, the cost consequence, the price source, and the confirmation gate. It leaves gaps on wallet insufficiency and on the relationship to the approve/cancel siblings, but the core decision-making information is present.

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 coverage is 78%, so most parameters are self-documented, but the description adds real workflow semantics absent from the schema: expectedPrice must be the exact value growwer_estimate_order returned. That connects two tools' parameters in a way the schema alone cannot.

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 ('places the order') and resource ('an article or a link addition on a catalogue media') and ties it to a project, which separates it cleanly from read siblings like growwer_get_order and growwer_list_orders. It does not explicitly contrast with growwer_approve_order or growwer_cancel_order, so the lifecycle position is only implied.

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?

Clearly states the triggering condition ('when the user has decided to buy') and the interaction precondition ('the user is asked to confirm the purchase first, and nothing is charged unless they accept'). It also names growwer_estimate_order as the source of expectedPrice, establishing the required call order, but gives no explicit when-not guidance (e.g. when to approve or cancel instead).

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world, so safety is covered. The description adds genuinely useful behavior the annotations don't: the project is analysed asynchronously in the background to recommend medias. However it says nothing about the required requestId de-duplication contract (which sits only in the schema), cost/credit implications, or auth/permission needs, which matter for a write.

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?

A single sentence that front-loads the selection trigger and then the effect; no filler, no restatement of the title.

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?

For a 9-parameter, 6-required mutation with no output schema, the description leaves out too much: the need to resolve topic/language/country via growwer_get_vocabulary, the requestId rule, and what the agent should do after creation (poll get_project?). Only the background-analysis outcome is conveyed.

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 coverage is only 67%, and the description adds zero parameter meaning — no mention of topics/language/country needing vocabulary lookups, no mention of the mandatory requestId, rootUrl format, or the 5–10 promotedProducts constraint. Required-but-undescribed parameters like rootUrl, name and websiteType are left entirely to the schema.

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 sentence names a specific verb (creates) and resource (project) and adds the distinguishing precondition 'a website that has no project yet', which separates it from get_project/update_project and from create_order. Sibling tools are not named, which is the only thing keeping it from a 5.

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 an explicit trigger: use when the user wants to buy links and no project exists yet. That implicitly covers the when-not case (an existing project should route to create_order / get_project), but the alternative is never named, so the agent must infer it from the sibling list.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false), so the description only needs to add beyond that. It adds meaningful context: saved filters persist to the web account and can be reused there, and notifications of new matching medias can be enabled. The only gap is that it doesn't say what the tool returns or what happens on failure.

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?

A single front-loaded sentence gives the trigger, the resource, the parent-input relationship, and the optional notification behavior. Nothing is wasted.

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?

For a five-parameter write with a nested filters object and no output schema, the definition covers purpose, trigger, input provenance, and notification side effects. It lacks only a note on what is returned or whether saving is limited per project, which would matter to an agent handling results.

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 coverage is 100%, so the baseline is 3. The description nevertheless adds real value by tying the 'filters' parameter to the exact set of parameters that growwer_search_project_medias accepts, which is more actionable than the schema's reference to GET /projects/{id}/medias.

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 names a specific verb and resource ('saves the filters growwer_search_project_medias takes') and adds the reuse scope ('here or on the web'). It also explicitly links the tool to the sibling whose inputs it persists, so an agent can tell exactly what it does.

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 opens with a clear trigger condition ('Use this when the user wants to keep a catalogue search of a project to reuse it'), which is the right usage context. It does not explicitly exclude sibling scenarios such as updating or deleting an existing saved filter, so it stops short of a full when/when-not statement.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false), so the description's main added value is the disclosure that 'Growwer reviews it in the background' — a genuine async behavior an agent needs. It does not say what the media's state is during review, what happens on rejection, or that consent flags must be true.

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?

One sentence, front-loaded with the use case, with zero redundant restatement of the title or schema.

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?

A 12-parameter creation tool with no output schema would benefit from stating what comes back (media id, pending-review status) and that the write is idempotent via requestId. The background-review note helps, but the definition remains thin for this complexity.

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 coverage is only 58% across 12 parameters, and the description only gestures at 'fees and offer' without mapping to postOffer/linkAdditionOffer or the required ownership/publishing consents. The rich nested schema descriptions carry most of the burden, leaving this at baseline.

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 and resource ('registers the media') plus what it carries (fees and offer) and that it belongs to a seller's own website. The word 'new' implicitly separates it from growwer_update_seller_media, but no sibling is named.

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?

'Use this when a seller wants to offer a new website of theirs on Growwer' gives a clear trigger condition, and 'new' implies the update/delete siblings are for other cases. No explicit when-not or prerequisite (e.g. must already be onboarded) is stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds genuinely new context — permanence ('deletes it for good'), the in-progress-order blocker, and a confirmation step. It omits what else is affected (associated media, orders) and any permission requirements.

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?

Three short sentences, front-loaded with the trigger, then the blocking constraint, then the confirmation behavior. No filler and no repetition of schema or annotation content.

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?

For a destructive, non-open-world tool with full annotation coverage and no output schema, the description supplies trigger, permanence, precondition and confirmation. The remaining gap is blast radius — whether dependent data is removed — which an agent about to delete would want to know.

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 coverage is 50%: requestId is fully documented in the schema, while 'id' has no description. The phrase 'one of their projects' only loosely implies that 'id' is the project identifier, so the description partially compensates for the undocumented parameter but adds no format detail.

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 and resource ('deletes it for good' for 'one of their projects'), which plainly distinguishes it from get_project, list_projects and update_project. It stops short of naming those siblings explicitly, so it is clear but not maximally differentiated.

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?

Gives an explicit trigger ('when the user no longer wants one of their projects') plus two operating conditions: projects with an order in progress cannot be deleted, and the user is prompted to confirm. It does not point at alternatives (e.g. cancel_order) for the in-progress case, which keeps it from a 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds value beyond that by noting the side effect that notifications stop and that web-saved filters are included, though it doesn't say whether deletion is reversible.

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?

A single front-loaded sentence that leads with the trigger condition and then the effect. The 'including one saved on the web' clause is slightly awkward but still earns its place as scoping 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?

All three required parameters are documented in the schema, annotations carry the safety and idempotency profile, and no output schema exists, so the description need not explain returns. It is essentially complete, with only the sharpening of alternatives/discovery left out.

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 coverage is 100% and each parameter is documented in the schema (project id, filter id, requestId idempotency key). The description's references to 'one of the saved filters of a project' loosely map to id/filterId but add no syntax or format detail, so baseline 3 applies.

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 (delete a saved filter) and adds scope detail ('of a project', 'including one saved on the web'), which tells an agent what it is operating on. It does not name sibling tools like growwer_list_saved_filters or growwer_create_saved_filter for differentiation, keeping it below a 5.

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?

'Use this when the user no longer wants one of the saved filters' gives an explicit trigger condition. It does not state exclusions or point to the listing tool needed to discover a filterId, so it stops short of full alternative guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real behavioral context beyond them: the delete is permanent ('for good'), media with an order in progress cannot be deleted, and the user is prompted to confirm first — all decision-relevant facts.

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?

Three short sentences, front-loaded with the usage trigger and zero filler. The blocking condition and the confirmation step each earn their place.

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?

For a destructive two-parameter tool whose annotations carry safety and idempotency, the description covers permanence, prerequisites, and confirmation. Only the meaning of the 'id' argument and post-deletion behavior are left unaddressed.

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 coverage is only 50%: requestId is fully documented inline, but the 'id' parameter has no description anywhere. The description never mentions either parameter, so it does nothing to compensate for the undocumented identifier — an agent must infer that 'id' is the seller media id.

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 and resource (deletes a seller's media) and adds scope with 'for good', which implicitly separates it from the discard/undiscard siblings without naming them. An agent can identify the operation, though the description never explicitly contrasts with growwer_discard_media.

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?

'Use this when a seller wants to stop offering one of their medias for good' gives a clear triggering condition, and the block on media with an order in progress is a useful exclusion. It stops short of naming the obvious alternative (discard_media) that an agent should pick when permanence is not wanted.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds real value by disclosing the conditional shape of the payload ('with the URL ... and publicationDateConfirmed' vs 'with neither'), but it says nothing about the irreversible state change implied by destructiveHint or what delivery does to the order 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?

A single sentence with the trigger front-loaded, so it is compact and leads with the actionable condition. But the clause 'a link addition with neither' is dense and requires the reader to resolve 'neither' back to two previously named parameters, costing a re-read.

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?

For a destructive, idempotent mutation with no output schema, the description covers the precondition and payload shape but omits consequences: what delivery commits, whether it can be undone, and what the buyer-review state means for subsequent calls. Adequate to invoke, thin for predicting effects.

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 coverage is 75% and the schema descriptions are already detailed (including idempotency semantics for requestId). The description still adds genuine meaning by tying url and publicationDateConfirmed to the order mode, which the schema does not express. With 'neither' left ambiguous about which parameters it refers to, it stops short of a 5.

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 ('delivers') and resource ('seller order') and even splits behavior by order type: post orders take the post URL plus publicationDateConfirmed, link additions take neither. That is more than a restatement of the name, but it never distinguishes itself from close siblings like growwer_deliver_seller_order_update or growwer_deliver_seller_order_draft.

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?

'Use this when a seller has published an accepted order' gives a clear triggering condition, so the agent knows the precondition. However, there is no explicit statement of when NOT to use it and no routing to the near-identical sibling tools (deliver_seller_order_update, deliver_seller_order_draft), leaving the alternative selection to inference from names.

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

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

The annotations already disclose that this is a destructive, non-read-only, idempotent operation. The description adds the useful prerequisite that the file must come from growwer_upload_file, but it does not describe delivery consequences or what happens to the draft after submission; the file-consumption detail lives in the schema rather than the description.

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 description is a single concise sentence that front-loads the usage condition. The phrasing is slightly awkward, but it contains no wasted text.

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?

For a destructive write operation with three required parameters and no output schema, the description covers the trigger and file prerequisite but leaves gaps around the id parameter, post-delivery state, and expected outcome. It is adequate but not complete.

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 67%, with detailed descriptions for fileId and requestId, so the schema carries most parameter meaning. The description only references the uploaded file and does not clarify the undocumented id parameter or add parameter semantics beyond the schema.

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 a specific action and resource: delivering a seller order draft from a file uploaded via growwer_upload_file. It is distinguishable from non-draft delivery tools by the word "draft" and the file prerequisite, though it does not explicitly contrast itself with sibling tools such as growwer_deliver_seller_order_update.

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?

The description gives a clear trigger condition: use it when a seller who writes the draft of a post order has it ready. It does not explain when not to use it or name alternatives, but the intended usage context is explicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this write is irreversible and safe to retry. The description adds the dependency on growwer_upload_file, but the material consequence — that the file is consumed on delivery and cannot be reused — lives only in the fileId schema field, not the description. 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?

A single sentence, front-loaded with the usage condition and ending with the resource dependency. No filler. It could only be improved by spending a few more words on the sibling disambiguation, which would still fit comfortably.

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?

For a three-parameter destructive write with no output schema, the definition covers the trigger and the file source but not the outcome: what happens to the order state after delivery, what the caller gets back, or how failures surface. Annotations carry the idempotency and destructiveness signals, which keeps this at minimum viable rather than inadequate.

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?

Coverage is 67%: fileId and requestId carry strong schema descriptions (allowed formats, 8 MB limit, single-use file; idempotency key semantics), so the description needn't repeat them. The `id` parameter is undocumented in both places, and the description only obliquely implies it identifies the seller order/draft being updated.

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 and resource: it delivers the new draft of a post order produced from an uploaded file, scoped to the case where the seller revised the draft at the buyer's request. This separates it from the plain delivery tool in spirit, though it never names its near-identical siblings (growwer_deliver_seller_order_draft, growwer_deliver_seller_order_update), so an agent must infer the boundary from the tool name alone.

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?

The trigger is explicit and conditional: use it when the seller has changed the draft as the buyer asked. That is real routing guidance, not a restatement of the name. It stops short of exclusions — it never says to use growwer_refute_seller_order_draft_update when the update is unacceptable, or growwer_deliver_seller_order_draft for a first delivery.

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

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

Annotations already declare idempotentHint=true, destructiveHint=true and openWorldHint=false, so the safety profile is covered. The description adds the meaningful detail that the result goes back to the buyer for another review, and that one mode carries a URL+confirmation while the other carries neither. It does not explain what the destructive/review consequence actually means operationally.

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?

It is a single front-loaded sentence with the usage condition first, which is good. But the second clause is compressed and hard to parse ('delivers a post order with ... and a link addition with neither'), forcing the reader to decode the two-mode logic, so structure costs clarity.

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?

For a destructive, idempotent mutation with 4 params and no output schema, the description covers the conditional parameter logic and the review-loop intent. It omits any description of the return value (since there is no output schema) and the failure/validation behavior when the two-mode rules are violated, leaving some gaps for an agent operating a write tool.

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 coverage is 75%, so the baseline is 3. The description genuinely adds value by defining a conditional relationship the schema does not state: a post order takes the URL and publicationDateConfirmed, while a link addition takes neither. That mutual-exclusion logic is not encoded in the schema and meaningfully guides which parameters to send.

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 a specific action (delivering a post order/link addition for buyer re-review) tied to the seller having changed a delivered order. It reads clearly as a submit-for-review operation, though the two-mode phrasing (post order vs link addition) is dense. It does not explicitly name the sibling it differs from (e.g. deliver_seller_order_draft_update), so differentiation is only implicit.

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?

'Use this when a seller has changed a delivered order as the buyer asked' gives a clear triggering condition and the word 'delivered' implicitly excludes draft orders. However it names no alternative tool and states no when-not conditions, so an agent must infer that draft updates route elsewhere.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description still adds real context: the discard is scoped "for that project" rather than deleting the media outright, which is crucial for a destructive operation. "Discarding it again changes nothing" merely restates idempotentHint, so it earns no extra credit.

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?

Two short sentences with the trigger condition front-loaded ahead of the mechanical effect. "As the web does" is slightly informal but conveys parity with the UI in three words; nothing is padded.

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?

For a three-required-param mutation with annotations and no output schema, the description covers the trigger, the project-scoped effect, and idempotent re-invocation. It leaves the response shape unspecified, but with no output schema that gap is minor and the annotations already flag it as destructive.

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 coverage is 100% and every parameter is documented, including the requestId idempotency semantics, so the schema carries the load. The description adds no parameter-level detail beyond the implicit project/media pairing, making 3 the correct baseline.

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 (discard) and resource (a catalogue media, for a given project), plus the intent behind it ("the user does not want a catalogue media for one of their projects"). That differentiates it from growwer_get_catalogue_media or growwer_delete_seller_media, though it never names growwer_undiscard_media as the inverse action.

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?

"Use this when the user does not want a catalogue media for one of their projects" gives a clear situational trigger, and "as the web does" anchors it to the familiar UI behavior. It stops short of stating when NOT to use it or pointing at the sibling restore tool (growwer_undiscard_media).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds that this is a file retrieval rather than a data lookup, but discloses nothing about file format, what happens when no document is attached, or whether the document is generated on demand — gaps annotations can't fill.

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?

Two sentences, zero filler, with the primary condition front-loaded and the prerequisite id source placed after it. Every clause carries information the agent needs.

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?

For a one-parameter read-only download with no output schema, the description covers the trigger, the resource, the outcome and how to obtain the id. The main remaining hole is the nature of the returned file (format/content type), which the agent may need to report back to the user.

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 coverage is 0% and the single parameter is a bare 'id: string' with no description in the schema. The description partially compensates by explaining that the id identifies a transaction movement and by pointing to growwer_list_buyer_transactions as the source of valid values, but it never says what kind of identifier it is or how it differs from order/invoice ids used by sibling download tools.

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 precisely ('the document Growwer attached to a movement of their buyer wallet') and the outcome ('returns the file'), which is enough to distinguish it from the many order/invoice/download siblings. It does not explicitly contrast itself with growwer_download_seller_transaction_document, relying on the word 'buyer' alone to make that split.

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 an explicit trigger ('when the user needs the document...') and, more usefully, tells the agent how to obtain the required id via growwer_list_buyer_transactions. It stops short of saying when not to use it (e.g. seller-side movements or withdrawal invoices), so it is clear guidance but not a full routing rule.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the operation 'returns the file,' but it does not explain auth requirements, error behavior, or file format. With annotations carrying the behavioral basics, this is adequate but not rich.

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 description is a single front-loaded sentence that is easy to scan. It is appropriately sized for a simple download tool, though the closing 'returns the file' is slightly redundant and the title/description terminology mismatch reduces precision.

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?

For a one-parameter read-only tool with annotations and no output schema, the description covers the basic purpose and return type. It remains incomplete because it does not clarify the id parameter or differentiate the tool from similar download siblings, which matters for correct selection.

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?

The only parameter is 'id' with 0% schema description coverage, so the description must compensate. It implies the id refers to one of the user's post orders, but it never explicitly identifies the parameter or says whether it is an order id, briefing id, or draft id.

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 a clear verb and resource: retrieving the file attached to the briefing of one of the user's post orders. It is understandable on its own, though it does not explicitly distinguish this tool from nearby siblings such as growwer_download_order_draft or growwer_download_seller_order_briefing, and the title's 'draft' wording differs from the description's 'briefing' wording.

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?

The phrase 'Use this when the user needs the file they attached to the briefing of one of their post orders' gives a clear usage context. It does not name alternatives or exclusions, so it falls short of full when/when-not guidance, but the intended situation is easy to infer.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that it returns a file and that it reflects the 'current' draft, but it does not say what happens when no draft exists, whether the call fails or returns empty, or what format the file is.

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?

One front-loaded sentence with the usage condition first and the outcome last; there is no filler. The trailing ': returns the file' is slightly redundant with 'draft file' earlier in the same sentence but still adds the confirmation that a file, not metadata, comes back.

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?

The tool is simple (one param, no output schema, rich annotations), so the description need not explain return values. However, for a download tool it leaves open the file type/size and the no-draft case, which are the main things an agent would still need to handle 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?

Schema description coverage is 0% for the single required 'id' parameter, so the schema alone gives no clue what identifier is expected. The description partially compensates by framing the resource as 'one of their post orders', implying the id is an order id rather than a draft id, but it never says so outright.

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 pairs a specific verb (download) with a specific resource (the current draft file of a post order) and states the time in which it is useful (before publishing). It implicitly separates itself from the seller-side sibling by saying 'their post orders', but never names growwer_download_seller_order_draft or growwer_download_order_briefing explicitly.

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?

'Use this when the user needs the current draft file ... to review it before publishing' gives a clear trigger condition tied to the draft-review workflow. It offers no explicit exclusions or named alternatives, so the agent must infer that it should not be used for the published order or for the seller-side equivalent from sibling names.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is settled. Against that lower bar the description adds nothing behavioural: 'returns the file' restates the verb, and it says nothing about what form the file comes back in, whether access is permission-gated, or what happens when no attachment exists.

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?

It is a single short sentence, so nothing is padded, but the trailing ': returns the file' is pure redundancy and the main clause is a nested run-on. Front-loading is acceptable ('Use this when...') though the object of the action arrives late.

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 is the only place the return value could be characterised, and 'returns the file' does not say whether that is a URL, a token, or a binary payload. Combined with an undocumented 'id' parameter, an agent knows roughly the intent but not enough to invoke this confidently.

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 is a single required parameter, 'id', with 0% schema description coverage, and the description never mentions it at all – the agent must infer it is a seller order id rather than a briefing or draft id. With only one parameter the schema alone is thin, so the description needed to compensate and does not.

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 verb (download/returns) and resource (the file the buyer attached to a briefing on a seller's order) are present, so an agent can roughly tell what it does. But the wording is muddled – the pronoun 'they' leaves it unclear whether buyer or seller owns the 'post order', and the title calls the artifact a 'draft' while the description calls it a 'briefing', an ambiguity the agent must resolve against siblings like growwer_download_order_briefing and growwer_download_seller_order_draft.

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?

'Use this when the user, as a seller, needs the file...' gives an explicit usage trigger scoped to the seller role, which is real guidance. However, it never names the obvious alternatives (the buyer-side briefing download or the seller order draft download), so the agent gets no rule for picking this tool over them.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds only 'returns the file', without saying whether the result is a URL, binary payload, or where the draft comes from. Modest added value beyond structured fields.

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?

A single front-loaded sentence with no padding. Slightly awkward phrasing ('post order they sell') keeps it from being a clean 5, but nothing is wasted.

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?

For a one-parameter, no-output-schema download tool the description covers the essentials of when and what. It omits the return shape (file vs link) and the precise meaning of 'id', which matter for correct invocation.

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 is one required parameter, 'id', with 0% schema description coverage. The description implies it is the id of the order being sold but never states that explicitly, nor whether it is an order id versus a draft id — the single most important ambiguity here goes unresolved.

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 and resource: it downloads/returns 'the current draft file of a post order they sell'. The seller qualifier distinguishes it from growwer_download_order_draft, but the phrase 'post order' is odd and the object of the download is only loosely named.

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?

'Use this when the user, as a seller, needs the current draft file' gives a use condition tied to the seller role. It does not name exclusions against closely related siblings such as growwer_download_order_draft or growwer_download_seller_order_briefing, leaving the agent to infer which download to pick.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is carried by structured data. The description adds that the tool 'returns the file', clarifying it produces document content rather than metadata, but says nothing about file format, encoding, size limits, or failure behavior.

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?

Two sentences, zero waste, and the triggering condition is front-loaded before the prerequisite tool. Nothing could be removed 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 output schema, the description should explain how the file is delivered (binary content, base64 payload, or URL) since that determines how an agent handles the result. 'Returns the file' gestures at this but does not resolve it, leaving a real gap for a download tool.

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?

The single parameter 'id' has 0% schema description coverage, so the schema alone leaves it ambiguous. The description partially compensates by pointing to growwer_list_seller_transactions as the source of the movement, implying the id is a movement identifier, but it never states this outright.

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 and resource: returns the document attached to a movement in the user's seller wallet. The phrase 'seller wallet' distinguishes it cleanly from the sibling growwer_download_buyer_transaction_document without needing to open either 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?

'Use this when the user needs the document Growwer attached to a movement of their seller wallet' gives a clear triggering condition, and it explicitly routes the agent to growwer_list_seller_transactions to obtain the movement first. It does not contrast against other document-download siblings (withdrawal invoice, invoice PDF), so the routing is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only that the result is a returned file; it says nothing about file format, behavior when no invoice was uploaded, or permission requirements. Useful but thin beyond 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?

One sentence with the usage trigger front-loaded and no padding. The trailing 'returns the file' is slightly vague and could have carried more useful detail instead.

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?

For a single-parameter read-only download tool with full annotation coverage and no output schema, the description is largely sufficient. The remaining gaps (what the returned file is, failure mode when the withdrawal has no uploaded invoice) are minor but real.

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 0%, so the bare 'id' string would be ambiguous. The description partially compensates by implying the id identifies a withdrawal ('for one of their withdrawals'), which is genuinely helpful disambiguation, but it gives no format or sourcing guidance.

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 names a specific verb (download/return) and resource (the invoice the user uploaded for a withdrawal), and the phrase 'invoice they uploaded' distinguishes it from platform-generated invoice tools like get_invoice_pdf. It does not explicitly name which sibling to use instead, so an agent must infer the boundary from context.

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 a clear trigger condition: 'use this when the user needs the invoice they uploaded for one of their withdrawals.' That is enough to route a request, but no when-not guidance or explicit alternative (e.g. list_withdrawals to find the id) is offered.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, and the description reinforces this with 'Changes nothing.' Beyond that, it usefully discloses the computation itself — which proposal sets are totalled and that the result is compared to wallet balance — which the annotations cannot express.

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?

A single well-constructed sentence, front-loaded with the usage trigger followed by the described computation and the no-op guarantee. Dense but every clause carries information; no padding.

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 explains what the result contains (total versus wallet balance). The only gap is the unexplained required `id` and whether the estimate is returned as a structured breakdown, but the core is complete enough to call it 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?

Schema coverage is 50%: `accept` is already documented in the schema and the description's phrasing ('the proposed ones named in accept') merely restates it. The required `id` parameter is undocumented in both schema and description, leaving the agent to infer it is the campaign id.

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 and resource: it estimates the cost of accepting managed-service campaign proposals by totalling accepted-awaiting-order plus proposed items and comparing against wallet balance. This is clearly distinct from growwer_estimate_order or growwer_get_managed_service_proposals_summary, though it never names those neighbors as alternatives.

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?

'Use this when the user considers accepting proposals' gives a clear trigger condition that implies this is a pre-flight check before the actual accept action. It doesn't mention which sibling to consult first (e.g. review_managed_service_proposals) or when-not to use it, so no exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety bar is low. The description adds real value by disclosing that the result compares the computed price against the available wallet balance, which is behavior not visible in the schema or 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?

Two sentences, the trigger condition is front-loaded, and the non-mutation guarantee is placed last for emphasis. No filler.

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 at least conveys what the result contains (price and wallet-balance comparison). It stops short of saying how validation failures for the briefing are surfaced, which is the one gap an agent would hit in practice.

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 coverage is 71% and the nested briefing variants are documented in the schema itself, so the baseline is 3. The description adds no parameter-specific meaning beyond 'these arguments', leaving behavioral details entirely to the schema.

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 and resource: it checks, prices and wallet-compares an order described by the arguments. 'Changes nothing' implicitly separates it from growwer_create_order, though it never names that sibling.

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?

'Use this when the user considers buying an article on a media' gives a clear trigger condition for the pre-purchase step. It does not explicitly say when to stop estimating and call create_order, but the read-only framing makes the boundary reasonably clear.

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

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

Annotations already declare destructiveHint=false, idempotentHint=true and openWorldHint=false, so "adding it again changes nothing" largely echoes idempotentHint rather than adding new information. The description says nothing about ownership requirements, what happens if the media or project is invalid, or what is returned.

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?

One compact sentence with the trigger condition front-loaded and no duplicated content. The analogy is short and pays for itself by clarifying the semantic, though the later clause overlaps with the annotations.

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?

For a three-parameter, all-required, non-destructive toggle with full schema coverage and annotations covering safety and idempotency, very little more is needed. Missing only failure modes (unknown project/media) and any note on the resulting state, which are minor for this tool.

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 coverage is 100%: id, mediaId and requestId are each documented in the schema, including requestId's deduplication contract. The description adds no parameter-level detail beyond the prose, so baseline 3 applies.

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 and resource: marks a catalogue media as a favourite of a given project. The heart-on-the-web analogy pins the intent precisely. It does not name the paired sibling (unfavourite_media), so it stops short of full differentiation.

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?

"Use this when the user likes a catalogue media for one of their projects" gives a clear activation condition tied to user intent. There is no explicit exclusion or pointer to growwer_unfavourite_media for the reverse action, so the guidance is clear but not complete.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by pre-announcing the response contents (balance plus top-up page), which matters because there is no output schema. It says nothing about currency, error cases, or auth, which caps it below 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?

One sentence that leads with the triggering condition and then the returned data. No filler, no restatement of the title beyond what is needed.

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?

For a zero-parameter read with no output schema, the description covers both when to call it and roughly what comes back, which is enough to invoke it correctly. Minor gaps are that it does not name the balance's currency/format or what 'page' means operationally.

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?

The tool takes zero parameters and the schema is trivially complete, so there is nothing for the description to disambiguate. The default baseline of 4 applies.

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 a specific verb and resource — it answers the balance of the buyer wallet — and even names the secondary return value (the top-up page). 'Buyer wallet' implicitly separates it from the sibling growwer_get_seller_wallet, though it never explicitly contrasts the two.

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?

"Use this when the user asks how much they can spend" gives a concrete triggering intent, which is stronger than most definitions. It stops short of stating exclusions or pointing at alternatives such as growwer_list_buyer_transactions for spending history.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value by disclosing what the response contains (prices, metrics, conditions), which is the main behavioral question an agent has here; it stops short of noting auth requirements or error cases.

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?

One sentence, no redundancy, and the trigger condition is front-loaded. Slightly long for the amount of information delivered, but nothing is wasted.

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?

For a one-parameter read tool with no output schema, the description adequately covers what the call returns and why an agent would make it. Missing only disambiguation against the other media-detail siblings.

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% for the single 'id' parameter, so the schema carries the load and baseline 3 applies. The description adds nothing about the identifier's format or where it would come from (e.g. a prior list/search call).

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 names a specific verb and resource ('the full details of one media of the catalogue') and enumerates the content categories returned (prices, metrics, conditions). It does not, however, distinguish itself from close siblings like growwer_get_seller_media or growwer_search_project_medias, which an agent could plausibly confuse it with.

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 a concrete use condition: fetch full detail before estimating or recommending an order, which implicitly points at growwer_estimate_order as the downstream tool. There are no explicit when-not conditions or named alternatives for the seller-side media lookups.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new operational context: 'Needs no sign-in or API key', which tells an agent it can call this before authentication — information absent from the annotations. It stops short of noting the guide's size or response format.

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?

A single sentence, front-loaded with the trigger condition followed by the content inventory. Every clause carries information; nothing is padded or restated.

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?

For a zero-parameter documentation tool with no output schema, the description tells the agent everything needed to decide to call it and what topics it will cover. A minor gap is that it doesn't hint at the guide's form (long reference document vs. short primer), which could matter for context budgeting.

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?

Zero parameters, so per the baseline this is a 4. The description correctly implies a no-argument call and adds no misleading parameter expectations.

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?

Specific verb ('get') plus resource ('the Growwer guide'), then enumerates its contents: buyer/seller profiles, order states, paging, error codes and vocabulary id origins. No sibling tool is a documentation/onboarding resource, so an agent can immediately distinguish it from growwer_get_vocabulary or growwer_get_me.

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?

Gives two explicit triggers: 'when you start working with Growwer' and 'when a tool answer is unclear'. This is a rare case where the when-to-use is stated concretely enough that an agent knows exactly which situation selects this tool over the domain-specific siblings.

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

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

Annotations already declare safe-read (readOnlyHint, idempotent, non-destructive), so the bar is lower, but the description usefully adds that this returns a binary file, which is not expressed anywhere else and matters because there is no output schema. No auth or size-limit context, but the essential behavioral fact is covered.

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?

Two tight sentences, front-loaded with the usage condition followed by the prerequisite lookup. Nothing is extraneous.

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?

For a one-parameter read tool, the description covers when to use it, how to get the id, and that the return is a file. Lacking only minor details like permissions or file format, and annotations already carry the safety profile.

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 coverage is 0% and the single parameter 'id' is undocumented in the schema, so the description must compensate. It does by telling the agent to obtain the id from growwer_list_invoices, which is exactly the missing semantic, though it gives no format or validation detail.

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 (return the PDF file) and resource (top-up invoices), and the qualifier 'top-up' implicitly distinguishes it from growwer_download_withdrawal_invoice. An agent can identify what it retrieves 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?

Gives an explicit trigger ('when the user needs the PDF of one of their top-up invoices') and routes the agent to growwer_list_invoices to obtain the id. It doesn't explicitly exclude the withdrawal-invoice sibling, but the 'top-up' scoping does most of that work.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that the payload includes budget, targets, state and progress, which is genuine value, but says nothing about what happens when the id is unknown or whether the result is a snapshot vs live progress.

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?

A single front-loaded sentence with no filler; the usage trigger and the returned content are both packed in without redundancy.

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 should describe the return shape, and it only lists four field areas without structure or nesting. For a one-parameter getter with annotations covering safety, it is close to adequate but missing the id-to-result relationship and error behavior.

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 0% for the single 'id' parameter, so the description must carry the load. 'One managed service campaign' implies the id identifies a campaign, but it never says the id is the campaign identifier, nor its format or where to obtain it (e.g. from the list tool).

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 resource ('one managed service campaign') and scope ('in full'), and the word 'one' implicitly contrasts with the list sibling. It never names growwer_list_managed_service_campaigns or growwer_get_managed_service_proposals_summary explicitly, so sibling differentiation is implied rather than stated.

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?

The phrase 'Use this when you need one ... in full' gives a usable trigger condition and hints at single-vs-list usage. However, it never states when NOT to use it or points to the list tool or the proposals tools as alternatives, leaving routing to inference from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new trait — that the call returns a file rather than structured data — but says nothing about permissions, file size, or whether the extended PDF differs structurally.

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?

One dense sentence with no filler, front-loaded with the usage trigger before the parameter note and return note. Slightly compressed grammar ("extended adds the details of each media") costs a little readability.

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 should carry the return-value burden and it does only minimally ("Returns the file"). For a two-parameter download tool that is just about adequate, but the meaning of `id` and the exact PDF content variation under `extended` remain underspecified.

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 coverage is 50%: `id` has no schema description, and `extended` is documented as "Whether to show the prices" while the description calls it "adds the details of each media" — related but not identical, leaving the agent to reconcile two phrasings. The description does at least clarify the practical effect of `extended`, but not what `id` refers to.

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: produce the PDF summary of a managed service campaign's proposals, plus that it returns a file. That distinguishes it from list_managed_service_proposals and review_managed_service_proposals by output format, though it never names those siblings explicitly.

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?

"Use this when the user wants the PDF summary ... as the campaign page offers it" gives a clear trigger condition. But there is no statement of when NOT to use it or which sibling (list_managed_service_proposals, review_managed_service_proposals, estimate_managed_service_proposals) to prefer when the user just wants the data rather than the PDF.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description's added value is the return-surface enumeration (restriction flag, catalogue openness, managed service), which tells the agent this is a broad account snapshot and not a targeted lookup.

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?

One sentence, front-loaded with the usage trigger, and every clause after the colon names a distinct piece of returned data rather than padding. No 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 carries the burden of telling the agent what comes back, and it does so field-by-field. Missing only the shape/format of responses (single object vs nested) and any auth failure behavior, which is a minor gap for a zero-arg read.

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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for parameterless tools applies. The description correctly adds no parameter noise.

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 names the resource (the caller's own account) and enumerates what it surfaces: profiles, buyer/seller balances, seller restriction state, catalogue openness, managed service. It implicitly distinguishes itself from the narrower wallet siblings (get_buyer_wallet, get_seller_wallet), though it never says so explicitly.

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?

'Use this when you start working with an account, or need its profiles, balances or access' gives a concrete trigger condition rather than leaving usage implied. It stops short of naming an alternative to pick instead (e.g. get_seller_wallet for balance-only reads), so no explicit exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds useful composition detail by naming the payload sections (briefing, draft, state history). It says nothing about failure modes such as an unknown id or cross-buyer access.

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?

A single front-loaded sentence that states the usage condition first and then the payload. No repetition of the title, no filler.

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?

For a one-parameter read with no output schema, the description does outline return contents, which is helpful. It still leaves the identity of the id and error behavior unspecified, so an agent cannot fully call it without guessing.

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 coverage is 0% and the sole 'id' parameter is completely undocumented, so the description must compensate. It implies that the id addresses one purchased order, but never specifies the id format or whether it is a buyer order id versus a seller order id.

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 a specific retrieval: one order 'the user bought', including its briefing, draft and state history. The buyer framing implicitly separates it from the seller-side siblings like growwer_get_seller_order, but it never names that counterpart explicitly.

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?

'Use this when you need one order' sets a context but offers no exclusions or alternatives. An agent must infer on its own when to prefer growwer_list_orders or growwer_get_seller_order over this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing what the response contains (domain, topics, state), which annotations cannot express; it says nothing about errors or missing-project behavior, keeping it short of 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?

A single sentence with no filler, and the selection condition is front-loaded. Slight vagueness in "in full" costs it a perfect score.

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?

For a trivial one-parameter read tool with no output schema, the description tells the agent what it gets back (domain, topics, state), which compensates for the absent output schema. The only gap is not explaining where the project id comes from.

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 0%, so the description carries the burden for the single `id` parameter. It implies the id identifies one of the user's projects but gives no format or source guidance (e.g., where to obtain the id); the self-explanatory field name keeps this at a baseline 3.

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 a specific retrieval action on a single project and even previews the payload (domain, topics, state), which distinguishes it from growwer_list_projects. It stops short of naming that sibling explicitly, so it is clear but not fully differentiated.

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?

"Use this when you need one of the user's projects in full" gives a clear selection condition — full detail on a single project versus a list. There are no explicit when-not cases or named alternatives, but the usage context is unmistakable.

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

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

The annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds value beyond the annotations by naming what the response actually contains (fees, extras, suggested competitive fees, performance). It does not mention what happens when the id does not exist or is not owned by the user.

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 description is one sentence, front-loaded with the triggering condition, and each enumerated field earns its place by telling the agent what comes back. It is slightly dense in the trailing enumeration but has no filler.

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?

No output schema exists, and the description largely makes up for that by listing the returned facets. The remaining gaps, such as not-found behavior and the relationship to the sibling media tools (get_catalogue_media, list_seller_medias), are minor for a single-id read tool whose safety profile is already carried by the annotations.

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?

The schema documents zero parameters (0% coverage), so the description carries the full burden; it never mentions "id" explicitly. The phrase "one of the user's seller medias" does make the meaning of the single required id inferable as the seller-media identifier, but that inference is left unstated. Mitigating the gap, the input is a single obvious string identifier.

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 uses a specific verb ("get ... in full") on a specific resource ("one of the user's seller medias") and enumerates the content returned (fees, extras, suggested competitive fees, performance). It does not explicitly distinguish the tool from the many sibling reads the agent could reach for, notably growwer_get_catalogue_media and growwer_list_seller_medias.

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?

"Use this when you need ... in full" gives an implied condition for this tool. However, it never names an alternative: it does not say to use growwer_list_seller_medias to browse/summarize, to use growwer_get_catalogue_media for catalogue-side media, or what to do when the id is unknown, so the choice between siblings is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description earns credit beyond that by disclosing the composition of the response (briefing, draft, state history), which tells the agent this is a heavyweight full-detail fetch rather than a summary.

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?

One sentence, front-loaded with the usage trigger and then the scope and payload. Nothing redundant and nothing padding.

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?

For a read-only single-entity fetch with no output schema, listing the returned components is the right minimum, and annotations carry the safety story. What is missing is the disambiguation from growwer_get_order and the download_* siblings, which is the main failure mode in a 60-plus tool surface.

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 coverage is 0%, so the single `id` parameter is entirely undocumented in the schema. The description implies it identifies a seller-side order ('one order placed on one of the user's medias') but never states the id format, whether it is the seller order id or a shared order id, or what happens with an invalid id.

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 and resource (get one order placed on one of the user's medias) and enumerates the payload it returns: briefing, draft, state history. That is enough to separate it from list tools, but it never names growwer_get_order, the near-duplicate sibling an agent must distinguish it from.

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?

"Use this when you need one order ... in full" gives a positive use condition, implying the list tools are for enumeration. However, there is no when-not guidance and no explicit routing between this and growwer_get_order or growwer_download_seller_order_briefing/draft, so the agent must infer the split.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral content: the response splits into immediately withdrawable funds versus amounts pending order settlement, which an agent would otherwise not know. Auth or currency details are unstated, keeping it below 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?

One sentence, front-loaded with the use-case trigger and followed by the payoff. No filler, no restatement of the title, nothing to trim.

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 carries the return-value explanation, and it does describe the two balance components. For a zero-parameter read tool this is close to sufficient; currency, seller verification state, and pending-payout timing are left implicit.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is nominally 100% but the schema is empty, so no param burden exists at all.

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 names the resource (seller wallet) and states concretely what it returns: the withdrawable balance and funds held until orders settle. That is more specific than the title. It does not explicitly contrast with growwer_get_buyer_wallet or growwer_list_withdrawals, but the seller/buyer distinction is carried by the name.

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?

"Use this when the user asks what their sales earned" gives a clear triggering condition tied to user intent, which is the main thing an agent needs for selection. It stops short of naming exclusions or pointing to alternatives such as list_withdrawals for withdrawal history.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the return content (every code paired with its English name) and the intent behind it ('so the ids are never guessed'), which is important since there is no output schema. It does not say how the entries are grouped or how large the response is.

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?

A single sentence with the usage trigger front-loaded ahead of the effect. Nothing is repeated from the annotations and there is no filler.

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, the description carries the burden of explaining the return, and it does state that the payload is codes plus English names for five vocabulary families. It is slightly thin on shape (whether results are grouped per category) and on whether the full list is always returned unpaginated.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description implicitly confirms the no-argument nature by saying it lists every code, i.e. no filtering input is required.

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 and resource — it 'lists every code with its English name' for the enumerated vocabularies (country, language, topic, product type, link type). That is far more concrete than the title 'Get the codes and names'. It does not distinguish itself from the other 'getter' sibling growwer_get_guide, which an agent could conceivably confuse with it, so it stops short of a 5.

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?

Gives an explicit triggering condition: use it 'when a filter or an answer takes a country, language, topic, product type or link type.' That tells the agent exactly the situation that selects this tool. There is no explicit exclusion or named alternative, but no sibling overlaps enough to require one.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered structurally. The description adds real value beyond them by disclosing the sort order ('newest first') and the exact composition of the result set, which an agent cannot get from 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?

One sentence, front-loaded with the trigger condition, then the resource and its contents, then the ordering. Zero filler and nothing buried.

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?

For a two-optional-param read-only listing with no output schema, the description tells the agent what will be returned, in what order. It could note that results are paginated or whether a total count accompanies them, but the schema covers the paging knobs adequately.

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% with clear limit/offset definitions and bounds, so the schema carries the burden. The description says nothing about paging, so it adds no semantics beyond the schema — baseline 3 applies.

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?

Specific verb ('lists') plus specific resource ('movements of their buyer wallet'), and it enumerates the movement categories returned: top-ups, order debits and refunds, gifts, manual corrections. It doesn't name the closest sibling (growwer_get_buyer_wallet for balance, growwer_list_seller_transactions for the seller side), so the distinction is inferable rather than explicit.

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?

'Use this when the user asks about the movements of their buyer wallet' gives a clear triggering condition and implicitly excludes balance/other-wallet queries. No explicit 'don't use for X, use Y instead' exclusion against the sibling wallet tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that: nothing about pagination behavior, result caps, how flash-offer availability is determined, or what the response shape is for a read-only listing.

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?

A single sentence with the usage trigger front-loaded via a colon, and no filler. Slightly dense in the trailing clause ('catalogue of one of their projects'), but nothing wasted.

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?

For a read-only query tool with 36 filter parameters, no output schema and no pagination explanation in the description, the definition is thin. The absent output schema means the agent cannot learn from structured data what a result row contains or whether offset/limit pages carry a total count, and the description does not fill that 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?

All 36 parameters carry schema descriptions at 100% coverage, including enums, defaults, ranges and subtle semantics (e.g. 'only `true` applies it; omit it otherwise'). The description adds no parameter guidance of its own, so the baseline of 3 is appropriate when the schema does all the 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?

The description names a specific verb (lists) and a precise resource (medias on a time-limited flash offer) scoped to one project's catalogue. The 'discounted / flash offer' framing differentiates it conceptually from growwer_search_project_medias or growwer_get_catalogue_media, though it never names those siblings explicitly.

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?

There is a clear triggering condition — use it when the user is looking for discounted medias — which gives an agent a concrete entry point. It stops short of stating when *not* to use it or which of the many sibling search/catalogue tools to prefer instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavior beyond that: results are ordered newest first and include amounts and dates. It says nothing about pagination behavior or how many total invoices exist despite limit/offset in the schema.

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?

A single front-loaded sentence with no filler: the usage trigger comes first, then the ordering and returned fields. Every clause carries 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 output schema, the description usefully characterizes the return (amounts, dates, newest first) and the schema fully documents the two params. Only minor gaps remain, such as whether pagination metadata is returned or how to detect the end of the list.

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 coverage is 100% and both parameters (limit, offset) carry their own descriptions, so the schema does the heavy lifting. The description adds no paging guidance, such as how to walk pages or a sensible default page size, so baseline 3 applies.

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?

It states a specific verb and resource ('lists' the user's top-up invoices) and adds scope detail ('of their top-ups', 'newest first, with their amounts and dates'). That implicitly separates it from siblings like growwer_download_withdrawal_invoice or growwer_get_invoice_pdf, though no sibling is named explicitly.

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?

'Use this when the user asks about the invoices of their top-ups' gives a clear trigger condition an agent can match against a user request. It stops short of stating when not to use it or which sibling to pick for PDF downloads versus listing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are ordered newest first and the list is empty when the user has no managed service, which prevents the agent from misreading an empty array as an error.

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?

Two short sentences, zero filler, and the usage trigger is front-loaded ahead of the ordering and empty-state facts. Nothing here repeats the schema or annotations.

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?

For a two-parameter, read-only list tool with full schema coverage, rich annotations, and no output schema, the description covers the trigger, the ordering, and the empty-result case. An agent has everything needed to select and call it 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?

Schema coverage is 100% and both limit and offset carry their own descriptions with defaults and bounds, so the description needn't restate them. It adds no extra meaning such as how paging interacts with the newest-first ordering, leaving this at the baseline.

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 (lists) and resource (managed service campaigns) and scopes it as the campaigns Growwer's team runs on the user's behalf, which cleanly separates it from the singular growwer_get_managed_service_campaign. It does not explicitly name the sibling for detail views, so differentiation is implied rather than stated.

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?

"Use this when the user asks about the campaigns Growwer's team runs for them" gives an explicit trigger, and "Empty without a managed service" gives a precondition that tells the agent when not to expect results. It stops short of naming an alternative tool for drilling into a single campaign.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful context that results are newest-first and include state and price, but it does not mention pagination behavior or filtering effects.

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?

It is a single front-loaded sentence that states the use case and the key result characteristics without filler. Every clause contributes useful 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?

Annotations cover the safety profile and the schema covers most parameters, while the description adds returned-field context. However, it does not distinguish this listing tool from adjacent summary/review tools or explain pagination, leaving some ambiguity for an agent.

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 75%, with limit, state, and offset documented in the schema. The description does not clarify the required id parameter, the comma-separated state filter, or pagination semantics beyond what the schema already provides.

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 and resource: it lists proposed medias for a managed service campaign, including ordering and returned attributes. It is clear what the tool does, though it does not explicitly contrast itself with sibling summary, review, or estimate tools.

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?

Gives a concrete usage condition: use it when the user reviews what Growwer's team proposes for a managed service campaign. It does not name when-not cases or alternatives such as get_managed_service_proposals_summary or review_managed_service_proposals.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral value: the delta/polling pattern using updatedAt sort with updatedSince to see only what changed.

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?

One front-loaded sentence that opens with the usage trigger, then the capabilities. Slightly run-on with semicolons, but nothing redundant or wasted.

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 7 optional params, no output schema and only annotations for safety, the description covers the call trigger and the polling trick but says nothing about what a page of orders looks like or how pagination/limit-offset behave in the result. Adequate but leaves a clear gap for a read tool with no return 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?

Schema description coverage is 100% and every parameter is documented there, including the enum, the 422 refusal on unknown states, and ISO-8601 formatting. The description merely summarizes the filter set, adding no syntax or semantics beyond the schema – baseline 3.

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?

Specific verb and resource with scope: "lists them with filters on state, project and dates". The phrase "the orders they bought" implicitly scopes it to buyer orders, distinguishing it from growwer_list_seller_orders without naming that sibling explicitly.

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?

Gives a clear trigger ("when the user asks about the orders they bought, or to follow them") and encodes the polling pattern via sort=updatedAt plus updatedSince. It stops short of naming alternatives like growwer_get_order for a single order or the seller-side list.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered elsewhere. The description adds one useful behavioral fact the annotations don't: results are ordered newest first. It says nothing about pagination defaults, total counts, or how many projects a typical user has.

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?

A single sentence that front-loads the trigger condition before the mechanics, with no filler. The colon-joined clause is slightly dense but still readable.

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?

For a zero-required-parameter list tool with a fully documented schema and no output schema, the description covers purpose, trigger, ordering and the id-chaining use case. The main residual gap is not describing what identifying fields a project record carries beyond the hinted id.

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%, with limit and offset fully documented in the schema, so the baseline of 3 applies. The description contributes no additional parameter guidance such as how to page through a large project list.

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 and resource ('lists the user's projects') and clarifies what a project is in this domain ('the websites they buy for'). It implicitly separates itself from growwer_get_project by being the list form, though it never names that sibling.

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?

Gives a concrete usage trigger: 'when you need the user's projects... for example to pick the project id the catalogue and order tools take.' This tells the agent both the situation and the downstream consumer. It stops short of stating when not to use it (e.g. preferring get_project when an id is already known).

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is settled. The description adds genuine non-structured context: result ordering ("newest first") and the reason to call it (to obtain savedFilterId for search_project_medias). It doesn't discuss volume, pagination, or what a saved filter record contains.

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?

One sentence, front-loaded with the trigger condition before the action and the follow-up. Every clause carries information: trigger, scope, ordering, and downstream use.

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?

For a one-parameter read tool with annotations and no output schema, the description covers when to call it, what it returns in terms of ordering, and how the result is consumed downstream. Only the shape of a returned saved filter entry is left unspecified, which is a minor gap for a list tool.

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?

The single parameter has a 100%-covered schema description ("The project"), so the baseline is 3. The description's "of one project" reinforces that id scopes to a single project but adds no format, type, or lookup guidance beyond the schema.

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 a specific verb and resource ("lists the saved filters of one project") and adds ordering ("newest first"), which is more than the title alone. It also pins down the resource as project-scoped, distinguishing it from a global listing. It stops short of contrasting itself with the adjacent create_saved_filter / delete_saved_filter siblings.

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?

"Use this when the user refers to a catalogue search they saved, on the web or here" gives a concrete trigger condition for invocation. It also points to the follow-up tool and the field to use ("savedFilterId in growwer_search_project_medias"), making the workflow path explicit. No when-not-to-use condition is stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-scope context beyond annotations by saying results include 'every state' and carry 'their fees and performance'.

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 description is a single front-loaded sentence that immediately states when to use the tool and what it returns. There is no redundant or wasted text.

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 usefully notes that results include fees and performance, and that all states are listed by default. Pagination, sorting, and filtering are fully covered by the schema, though the description itself does not mention those mechanics.

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?

All four parameters are fully documented in the schema, including enum values, defaults, limits, and sorting semantics. The description adds no parameter-specific detail, so the schema does the heavy lifting and the baseline score of 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?

The description states a specific verb and resource: it 'lists' the 'medias they sell articles on' in 'every state with their fees and performance'. This clearly identifies the tool's purpose and differentiates it in practice from single-media tools like get_seller_media, though it does not explicitly name that sibling.

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?

The opening clause 'Use this when the user asks about the medias they sell articles on' gives a clear triggering context. It does not explicitly mention when not to use it or name alternatives, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond them: the incremental-sync pattern of pairing updatedAt with updatedSince to see only what changed, which is not derivable from 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?

One sentence, front-loaded with the triggering condition, with the operative detail (filters, the updatedAt/updatedSince pairing) after the colon. The colon-and-semicolon construction is a bit dense but nothing is wasted.

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?

For a read-only list tool with 6 fully documented parameters this is largely adequate, but there is no output schema and the description never indicates what a listed order contains or how paging results are returned, leaving the agent to guess the response shape.

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 coverage is 100%, so baseline would be 3, but the description adds cross-parameter meaning the schema does not: it explains that sort=updatedAt must be combined with updatedSince to track changes, not just what each field does in isolation.

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?

It states a concrete verb (lists) and resource (orders placed on the seller's medias) and scopes it explicitly to the seller role, which separates it from buyer-side siblings like growwer_list_orders. It stops short of naming that sibling outright, so the differentiation is implied rather than stated.

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?

'Use this when the user, as a seller, asks about the orders placed on their medias, or to follow them' gives a clear triggering context, and the updatedSince tip supplies a concrete follow-up workflow. No explicit exclusion or hand-off to growwer_list_orders or growwer_get_seller_order is given, so it is not a full when/when-not treatment.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine behavioral value with the 'newest first' ordering and the composition of movement types, but says nothing about pagination behavior or what a page of results looks like beyond the schema's limit/offset.

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?

A single sentence that front-loads the usage trigger, then the resource and its scope. No filler and nothing redundant with the schema or annotations.

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?

For a simple read-only list tool with full schema coverage and rich annotations, the description covers what is listed, in what order, and when to use it. With no output schema, a brief note on pagination/total counts would make it complete, but nothing critical 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?

Schema coverage is 100% with two optional, fully documented pagination parameters, so the baseline of 3 applies. The description adds no information about limit/offset semantics beyond what the schema already states.

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 and resource ('lists ... movements of their seller wallet') and enumerates what those movements are (earnings from orders, withdrawals, manual corrections) plus sort order, which an agent can distinguish from the balance-oriented get_seller_wallet. It stops short of explicitly naming the sibling it is not, so 4 rather than 5.

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?

'Use this when the user asks about the movements of their seller wallet' gives a clear triggering condition. No exclusions or alternatives are named, so the agent must infer that get_seller_wallet handles balances and list_withdrawals handles withdrawals alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuine behavioral context beyond them: results are ordered newest-first and each record carries a state. Pagination semantics are left to the schema rather than the prose.

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?

A single sentence with zero filler: trigger condition first, then scope, ordering and payload. Nothing is repeated from the title or schema.

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?

For a zero-required-parameter read with full schema coverage and a complete annotation set, the description covers when to call it, what it returns conceptually, and how results are ordered. No output schema exists, so a brief note on the shape of a withdrawal record (amount, date) would have closed the last 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 coverage is 100% — limit, offset and state are all fully documented, including the 422 refusal on unknown states. The description's phrase 'with their state' only loosely gestures at the state filter and adds no syntax or default information beyond the schema, so baseline 3 applies.

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 ('lists withdrawals') plus scope ('they requested from their seller wallet'), ordering ('newest first'), and the key field ('state'). This clearly separates it from growwer_get_seller_wallet (balances) and growwer_download_withdrawal_invoice, though neither sibling is named explicitly.

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?

'Use this when the user asks about the withdrawals they requested' gives an explicit triggering condition, which is stronger than most sibling definitions. It stops short of naming alternatives (e.g. get_seller_wallet for balance, download_withdrawal_invoice for the PDF), so it lacks exclusions.

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