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

Explicitly discloses the side-effect boundary: it does not place an order or take payment, and the user must open cart_link and pay on curo.you. This is consistent with readOnlyHint=true and idempotentHint=true and adds the multi-step purchase flow that annotations cannot convey. It also tells the agent what comes back (cart lines and cart_link), which matters since there is no output 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?

Three short sentences, front-loaded with the action and resource, then the usage condition, then the behavioral caveat. No filler or repetition; every sentence carries distinct 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?

For a single-parameter tool with an explicit statement of return values, this is nearly complete — the agent knows what to call, when, and that payment happens downstream. Minor gaps remain, such as whether the link expires or how invalid productIds are handled, but nothing essential for a correct call 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 description coverage is 100%, with productId explained as the slug from search_products/get_product and qty as 1 or more units. The description only restates 'products and quantities' without adding format, limits, or error behavior beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Make a curo.you cart link for products and quantities.' The naming of the output artifact (cart_link) makes the intended effect unambiguous. Sibling differentiation is implicit rather than explicit — the siblings are all read/search tools (get_product, search_products, get_coa), so the contrast is obvious but never 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 it only when the user wants to buy' gives a clear positive trigger and an implicit exclusion (not for browsing or research, which is what the sibling search tools cover). No alternative tool is named, but the boundary between this and the informational siblings 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 and destructiveHint=false, so safety is covered. The description adds genuinely non-structured context: the data is third-party lab output and each report carries a link to verify on the lab's own site, which matters for trust/attribution. It stops short of describing behavior on no-match or multiple matches, keeping it at 4.

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 tight sentences: capability first, payload second, routing third. No filler, and the most decision-relevant constraint (the sibling handoff) lands last where it is easy to act on.

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?

There is no output schema, so the description's field enumeration (lab, lot, test date, identity, purity, potency, report link, verification link) is necessary and present. For a one-parameter read tool, nothing an agent needs to call it correctly 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% and the 'query' parameter already documents lot-number-from-vial-label vs product name/slug. The description's 'by lot number or product' restates that rather than adding format or matching semantics, 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?

The description opens with a specific verb and resource ('Read third-party lab reports (COAs)') and states the two lookup keys (lot number or product). It also enumerates what a report contains, so an agent can distinguish it from get_product and search_products without opening a 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?

It states the use case explicitly ('questions about testing, purity or a lot number') and names the alternative with its own scope ('Use get_product for prices and stock'). This is a clean when-to-use / when-not-to-use 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds useful content disclosure — the response includes price, stock, and COA documents per lot — which the annotations cannot convey. It does not mention behavior for an invalid/stale slug or result size, 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?

Three short sentences, front-loaded with what is returned, then prerequisite, then the alternative tool. No filler or 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?

There is no output schema, so the description carries the burden of describing return contents, which it does (price, stock, COAs per lot). With a single required parameter fully documented and safety covered by annotations, an agent has everything needed 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 description coverage is 100% and the slug property already documents its origin ('The slug field from a search_products or get_product result'). The description largely restates that provenance plus an ordering hint, adding little semantic detail 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 and resource (read one Curo product) and names the payload: price, stock, and per-lot COAs. It is distinguishable from search_products (plural search) and get_coa (single lot lookup) without opening 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?

Explicitly prescribes the upstream step ('Call search_products first and pass a slug from its results') and routes the alternative case ('Use get_coa when the user gives a lot number'). Both when-to-use and when-to-use-something-else are 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 readOnly=true, idempotent=true, openWorld=true and destructive=false, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the result (a link to each policy page) rather than raw policy text alone, though it does not clarify whether full policy text, excerpts, or only links are 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?

Two sentences: the first front-loads what is returned, the second handles routing to siblings. No filler, no repetition of the title, and each sentence carries decision-relevant 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?

For a zero-parameter, no-output-schema read tool, the description covers purpose, scope, and sibling boundaries adequately. The only residual gap is the exact return shape (links vs. full policy text), which matters slightly more because there is no output schema to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the baseline this scores 4. The description correctly implies a no-argument call by framing it as a plain read of store-wide policies; there is nothing further a parameter discussion could add.

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 ("Read") and a specific resource (Curo's shipping, returns, contact and research-use-only policies), enumerating the exact policy domains covered plus the form of the response (a link per policy page). This is clearly distinguishable from any sibling, none of which deal with store policies.

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 it for questions about delivery, refunds or how to reach Curo" gives concrete triggering conditions, and the next sentence explicitly excludes product facts, routing them to search_products and get_product. Both when-to-use and when-not-to-use plus named alternatives are present.

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, openWorld), so the description correctly spends its words elsewhere: it discloses the fallback path when PepBank has no data (a PepBank link is returned) and imposes an operational requirement to surface the credit line with the answer. These are genuine behaviors not present in the annotations. Missing only peripheral details such as latency or rate limits.

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, zero filler, and the payoff (what the brief contains) is front-loaded before the routing rule. Each sentence carries a distinct load: contents, selection rule, empty-result behavior.

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-parameter tool with no output schema, the description compensates by describing the return payload in concrete sections and by explaining the degenerate case (no PepBank data). An agent knows what it will get back and how to route around an empty result, which is the full job here.

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 the single parameter is fully documented in the schema with examples (BPC-157, tb-500), so the description need not restate it. The description only reinforces that the argument is a single named peptide ("one peptide"), adding no format or slug-resolution guidance beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 opens with a specific verb+resource ("Read the PepBank brief for one peptide") and enumerates exactly what the brief contains: aliases, evidence split by human/animal/lab, findings with citations, regulatory status, credit line. That scope statement distinguishes it cleanly from search_research, which the description explicitly names as the multi-study alternative.

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 positive trigger ("Use it when the user names one peptide") and an explicit negative/alternative case ("Use search_research for a question across many studies, such as an outcome or a body system"). Both the when and the when-not are stated with the condition that selects between 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful return-shape context (name, slug, dose, price in USD, stock, lab report and buy links) that the annotations cannot convey. It doesn't mention result caps or pagination for the list-all case, which is the one remaining gap.

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 compact sentences, front-loaded with what the tool returns and how to invoke it, then sibling routing. No filler or restated name/title boilerplate.

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 covers return fields, matching behavior, and alternatives to a degree that is sufficient to call it correctly. Only listing limits/truncation behavior for the empty-query path 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% and the single parameter's schema description already explains the name format and the empty-query behavior. The description restates the empty-query rule but adds no new syntax or matching semantics, so the 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 (find/list) and resource (Curo products) plus the exact matching key (peptide or product name). It is clearly distinguishable from get_product and peptide_research, which are 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?

Gives explicit routing: use get_product for all doses of one product with lot reports, and peptide_research for study information. It also specifies the degenerate case (empty query lists all products), leaving nothing 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 readOnly/idempotent/openWorld, so the description doesn't need to re-state safety. It adds genuinely new behavioral context: the shape of each result (plain-word finding, peptide, evidence class, source passages) and the obligation to display the PepBank credit line. Pagination behavior beyond the schema's cursor note is not addressed.

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?

Four short sentences, front-loaded with purpose, then result shape, then attribution, then usage and the alternative. Nothing is 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?

With no output schema, the description carries the return-value burden and does so, covering result fields and the attribution requirement. Minor gaps remain on result volume and how pagination is meant to be traversed 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 100%, so baseline is 3. The description adds meaning beyond the schema by saying the query spans topics, outcomes, or questions (not just keyword matching on peptide names), which shapes how the agent should phrase input.

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 ('Search PepBank study findings across all peptides') plus the searchable dimensions (topic, outcome, question). It explicitly contrasts with the sibling peptide_research, so an agent can pick between them without opening a 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 a concrete trigger example ('which peptides were studied for tendon healing') and names the alternative plus the condition that selects it ('use peptide_research when the user names one peptide'). Both the when and the when-not are present.

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