Greener Closet

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

Beyond the readOnly/idempotent annotations, it discloses the data-coverage caveat (only products 'Greener Closet has analyzed'), the return contents (scores, synthetic-fiber counts, sourced claims), and two hard scope limits: it never rates the company itself and cannot confirm PFAS finishes. These are exactly the interpretive constraints an agent needs before summarizing results.

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?

Purpose leads, examples follow, limitations and sibling routing close it out — a deliberate front-loaded ordering. Every sentence carries unique information: the examples disambiguate intent, the negative constraints prevent misuse, the final sentence routes elsewhere.

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 lookup with an output schema already documenting return shape and annotations covering safety, the description fills the remaining gaps: what data coverage exists, what it will not assert, and which sibling handles adjacent intents. Nothing material 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 schema already supplies brand-name examples, so the description mainly reinforces that the input is a free-text brand name via its example questions. It adds no normalization guidance (casing, aliases, abbreviations) beyond what the schema states, 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 and resource ('check' a 'clothing brand') and immediately scopes it with concrete example questions. It also explicitly contrasts itself with check_product and find_alternatives, so the agent can tell the three apart without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use triggers (materials or sustainability questions about a brand) with five sample phrasings, plus explicit when-not-to-use routing: single product to check_product, brand discovery to find_alternatives. It even names a question type it cannot answer (PFAS finishes), preventing an over-eager call.

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?

Goes beyond the read-only/idempotent/closed-world annotations by disclosing the scoring model (0-100 Greener Closet score, synthetic share, main concerns) and an important edge case: mismatched percentages yield the gap instead of a score. That edge-case behavior is exactly the kind of failure mode an agent needs forewarned. Minor deduction since prompt-side input normalization (e.g. handling unsorted or unit-less text) is not discussed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the triggering case and followed by examples, exclusions, and return behavior in a logical order. It runs long for one paragraph with two quoted example inputs, but each sentence (including the percentage-gap rule) carries information an agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure needn't be restated, and the description nevertheless summarizes the outputs and the no-score fallback. For a single-parameter, closed-world read tool, nothing needed 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 single parameter is already documented, so the baseline is 3. The description adds value by showing several accepted input forms (percent+percent, percent+% fiber, with organic/recycled modifiers), which clarifies that free-form label text is fine rather than requiring a normalized format.

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 object (check a fabric label / fiber composition) with concrete input examples like "60% cotton, 40% polyester". It also names what it is not (check_product for URLs, explain_fiber for single-fiber questions), so an agent can route correctly against all 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?

Explicit triggering condition (user supplies composition or care-label text and asks whether it's good/sustainable/synthetic/better than another), plus a worked comparison workflow: 'To compare labels, call it once per label.' Exclusions to check_product and explain_fiber are named directly.

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 behavior, so the bar is lower. The description still adds genuine value by disclosing the two-branch outcome: stored catalog data when found, otherwise a link to analyze the product on greenercloset.com — a fallback an agent needs to relay to the user. It stops short of describing result formatting or latency, but that is minor given the output schema 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?

Front-loaded with the trigger condition, followed by expected returns, then exclusions — a logical order an agent can scan. The single long sentence is dense and slightly run-on, but every clause (query types, sample utterance, fallback, two exclusions) earns its 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 one-parameter lookup with a full output schema and complete annotations, nothing an agent needs to select or invoke it is missing: trigger conditions, disambiguation from check_fabric_label, and the not-in-catalog behavior are all present. Return-value detail is appropriately deferred to the 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?

With one parameter at 100% schema coverage and a schema-side example URL plus length bounds, the schema does the heavy lifting, so baseline 3 applies. The description reinforces that the input must be a full product-page link rather than label text, but adds no format or normalization 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?

States a specific verb and resource ("Check a clothing product") and immediately specifies what it returns: Greener Closet's stored fiber breakdown and score, with a fallback when the product isn't in the catalog. It also names the sibling it is not (check_fabric_label), so an agent can separate it from alternatives without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use conditions are given (user shares a product-page link and asks about materials, polyester/synthetics, 100% cotton, or sustainability), complete with a sample utterance. It also states two clear exclusions — pasted label text goes to check_fabric_label, and URL-less product descriptions are out of scope — leaving nothing 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, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that it returns a reviewed guide with sources when available and plainly indicates when information is limited. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the when-to-use condition and examples before covering return behavior and exclusions. The example list is somewhat long but each one clarifies the intended scope and does not feel wasteful.

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 explainer with one fully described parameter and an output schema, the description covers purpose, usage, exclusions, and fallback behavior. Nothing an agent needs to call it correctly appears to be 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% and the single parameter has a detailed description with examples, so the schema does the heavy lifting. The description's fiber examples are usage illustrations rather than additional parameter semantics, making the baseline score 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 (explain a clothing fiber) and explicitly covers the natural/synthetic/safety angle, which is the tool's actual scope. It also distinguishes itself from the sibling check_fabric_label by naming that alternative, so an agent can route correctly without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use language, several concrete user-question examples, and a clear when-not-to-use case with the alternative tool named. This leaves little ambiguity about selecting explain_fiber over check_fabric_label.

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?

Beyond the annotations (readOnly/openWorld=false/idempotent), it discloses result ordering (highest score first), what the results contain (disclosed fiber breakdown), and the fail-closed semantics of exclusions (only products with full composition disclosed are excluded). It also notes it does not filter by price, which sets a clear expectation. Missing only a note on pagination/breadth or how scores are derived.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the primary use case and sibling routing, with no filler sentences. The five examples are slightly repetitive in aggregate but each maps to a distinct parameter combination, so they earn most of their space.

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 an 8-parameter read tool with an output schema, the description covers scope, ordering, exclusion semantics, PFAS caveat, price limitation, and sibling routing. Return-value detail is correctly omitted since the output schema carries it.

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 description adds real semantic value on top of it, especially that fiber exclusions apply only to products with full composition disclosure and that recycled variants are excluded too. It implicitly rules out a price parameter. The two undocumented parameters (limit, department) are self-evident from name and enum, so the gap is minor.

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 (find clothing by fiber content) and immediately differentiates from siblings: 'Do not use this to check one product or brand (use check_product or check_brand)'. The concrete query examples ("leggings like Lululemon without polyester", "polyester-free socks") make the retrieval intent unambiguous.

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 when-to-use framing ("Use this when the user wants clothing with specific fiber content or an alternative to a brand") and explicit when-not-to-use with named alternatives (check_product, check_brand). It also scopes an adjacent-but-different need by warning that fiber content is not a PFAS test, preventing misfires.

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