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 the single-call batching behavior but does not disclose error handling, partial failures, or behavior with invalid/duplicate ids. This is acceptable but not rich 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?

The description is a single, front-loaded sentence that conveys the essential action, target, limit, and batching behavior. Every word earns its place, with no filler or repetition.

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 a simple single-parameter batch read with strong annotations, so the description is largely complete for selection and invocation. It lacks explicit mention of the return format or handling of invalid ids, but given the low complexity and good schema/annotation coverage, this is a minor 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 description coverage is 100%: the schema describes 'ids' as '1 to 50 fragrance ids' with item constraints. The description repeats 'by id' and 'up to 50' without adding additional semantic detail, so it does not meaningfully extend the schema information.

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 'Fetch up to 50 fragrances by id in a single call' clearly states a specific verb (fetch), the resource (fragrances), and the scope (by id, up to 50 in one call). This distinguishes it from siblings like get_fragrance (single) and search_fragrances (query-based).

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 makes the usage context clear: it is for retrieving multiple fragrances by their ids in one call, and it states the batch limit of 50. However, it does not explicitly name alternatives or exclusion criteria, such as 'use this instead of multiple get_fragrance calls' or 'use search_fragrances for filtering.'

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 established. The description adds the output structure (shared/distinct notes, accords, families, scores, synthesis) and notes the input requirement of two fragrance IDs, but it does not disclose additional behavioral traits like pagination, rate limits, or error conditions. With annotations covering the safety profile, a 3 is suitable.

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 two sentences, with the primary purpose front-loaded in the first sentence and the parameter note in the second. Every word contributes either to purpose or to invocation, and there is no superfluous 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?

The tool has no output schema, so the description carries the burden of explaining return values. It lists the categories (shared/distinct notes, accords, families, scores, written synthesis), which gives a good high-level picture for an agent deciding whether to use it. It lacks detailed output formatting or edge-case behavior, but for a read-only comparison tool with full schema coverage, it is adequately 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 100%, and the schema already documents 'a' as 'First fragrance id' and 'b' as 'Second fragrance id (must differ from a)'. The description merely says 'Takes fragrance ids' without adding semantic detail beyond the schema, so it stays at the baseline of 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 clearly identifies the tool as comparing two fragrances and enumerates the output dimensions (notes, accords, families, scores, written synthesis). The verb 'compare' and the resource 'two fragrances' are specific, and the output list distinguishes it from sibling tools like get_fragrance or get_similar_fragrances.

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 implies the use case when a side-by-side comparison of two specific fragrances is needed, but it does not explicitly mention exclusions or alternative tools. It provides clear context without explicit when-not-to-use guidance, so a 4 is appropriate.

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, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds context about what data is returned (notes, accords, reviews, similar fragrances) but goes beyond annotations only mildly—it doesn't mention pagination, rate limits, or response structure. With annotations covering the safety profile, a 3 is appropriate.

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 sentence that efficiently lists the tool's scope without waste. Every word contributes to the meaning, and the key phrase 'in one call' is front-loaded for quick comprehension.

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 has no output schema, so the description partially compensates by enumerating the returned resources (notes, accords, reviews, similar fragrances). It doesn't mention that review_limit and similar_limit constrain the response size, but those are in the schema. Given the rich annotations and the description's coverage of the composite nature, it is sufficiently complete for an agent to understand the tool's 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 100%: all three parameters (id, review_limit, similar_limit) have meaningful descriptions in the schema. The enrichment description doesn't add any parameter info beyond what's already documented, so the baseline of 3 is correct—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 uses a specific verb ('Fetch') with a clear resource ('a fragrance') and lists exactly what data is included (notes, accords, reviews, similar fragrances). It distinguishes itself from sibling tools like get_fragrance, get_fragrance_reviews, and get_similar_fragrances by framing this as a single composite call.

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 'in one call' clearly signals when to use this tool—when an agent wants all the listed data together instead of making multiple separate requests. It doesn't explicitly state when not to use it (e.g., if only one type of data is needed), but the context is strong enough for an agent to infer the trade-off.

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, openWorldHint, idempotentHint, and destructiveHint=false, fully covering the safety profile. The description adds the behavioral detail that the tool returns both a brand profile and top fragrances, which is useful but not extensive. No contradictions with 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 a single concise sentence that front-loads the action ('Get') and resource ('brand profile'), with every word contributing. No filler or redundant 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?

Given the tool's simplicity (one parameter, read-only, no output schema) and the annotations, the description fully conveys the tool's purpose and return content ('brand profile and its top fragrances'). It is sufficient for an agent to select and invoke the tool 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 for the single 'slug' parameter is 100%, with a clear example in the schema description. The description's phrase 'by slug' adds minimal meaning beyond what the schema already provides, so the baseline 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 clearly states the tool retrieves a brand profile and its top fragrances, using a specific verb and resource. It does not explicitly differentiate from sibling tools like list_brand_fragrances, but the added 'brand profile' scope provides some distinction.

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 implies usage when a brand profile with top fragrances is needed, but it provides no explicit guidance on when to choose this tool over siblings such as list_brand_fragrances or get_fragrance. No alternatives or exclusions are mentioned.

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-only, idempotent behavior, so the bar is lower. The description adds that this is a leaderboard fetched by slug, but doesn't disclose additional behavioral details like pagination, ordering, or potential staleness. It's 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 sentence that is front-loaded with the action and resource, using examples to clarify without unnecessary words. Every part 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 tool with one parameter, strong annotations, and no output schema, this description is complete. It tells the agent exactly how to invoke the tool (with a slug) and what to expect (a chart leaderboard). No critical information 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 a simple 'Chart slug' description. The tool description adds concrete examples of slug formats, which helps the agent understand what a valid slug looks like and that it's a URL-friendly identifier, going slightly beyond the schema's minimal description.

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') and resource ('chart leaderboard') and clearly identifies the key parameter (slug), with concrete examples ('top-rated', 'top-rated-brand-chanel'). This distinguishes it from siblings like list_charts, which lists charts rather than fetching a specific one.

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 clearly implies that you need a chart slug to retrieve a specific leaderboard, and provides examples of valid slugs. However, it doesn't explicitly mention when to use this tool instead of list_charts or other alternatives, nor does it state any 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 declare readOnly, idempotent, and non-destructive. The description adds context about the return contents (notes, accords, perfumer, community score) and shows a slug example, which goes beyond the minimal annotation coverage.

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 sentence, front-loaded with the verb and resource, and every phrase adds information (full profile, by id or slug, example, key fields). No wasted words.

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 single-resource lookup with no output schema, the description provides sufficient context by naming the key fields returned and the identifier format. It covers what an agent needs to know for practical use.

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 fully documents the single 'id' parameter, but the description adds meaning by explaining it accepts both id and slug and provides a concrete slug example ('tom-ford/oud-wood'). This helps the agent understand the expected format beyond the schema's generic description.

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 clearly states the tool gets the full profile for a single fragrance, specified by id or slug, citing an example. This distinguishes it from siblings like list_brand_fragrances or batch_get_fragrances, which handle multiple fragrances.

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 clearly implies the tool is for retrieving one specific fragrance by id or slug, which helps select among the many siblings. However, it does not explicitly state when not to use it or mention alternatives like search_fragrances or list_brand_fragrances, so no exclusions are given.

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 that results are paginated and accepts id or slug, but does not disclose ordering, response format, or behavior on invalid IDs. With annotations providing the safety context, 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 with no wasted words. It conveys the essential action, resource, and flexibility (id or slug) in minimal 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 a simple read-only paginated list tool, the description plus rich annotations and fully described parameters provide sufficient context. No output schema exists, so return values need not be explained. A minor gap is the lack of any mention of review ordering or content, but the tool is simple enough that this is not a critical omission.

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

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

Schema description coverage is 100%, so all parameters are already well-documented. The description's mention of 'id or slug' reinforces the id parameter but adds no new information beyond what the schema states. Baseline of 3 is appropriate when the schema handles the parameter semantics.

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 clearly states the tool retrieves paginated community reviews for a fragrance, with a specific verb ('get') and resource ('community reviews'). It also mentions both id and slug, which distinguishes it from sibling tools like get_fragrance (details) and get_review_digest (summary). The purpose is immediately understandable.

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 provides context: this is for paginated community reviews. However, it does not explicitly say when to use it over alternatives (e.g., get_review_digest). The clarity of 'paginated community reviews' implies a read use case, but exclusions or alternative tool references are absent.

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 the return content (note profile and top fragrances) but lacks details on return format, pagination, or ordering. This is comparable to the get_calls calibration example, which earned a 3.

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, clear sentence that earns its place. It is front-loaded with the action and object, free of filler, and immediately understandable.

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, single-parameter read-only tool with strong annotations and no output schema, the description sufficiently covers what the tool does. It mentions both the note profile and top fragrances, making the return content clear without needing to detail the response structure.

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 description for 'slug' is 100% covered, including examples ('oud', 'bergamot', 'iris'), so the parameter is well-documented there. The tool description adds no additional parameter semantics beyond 'by slug', which is redundant with the schema. Baseline 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 uses a specific verb 'Get' and clearly identifies the resource as 'a note profile and its top fragrances' with the mechanism 'by slug'. This distinguishes it from sibling tools like list_notes (which lists all notes) and get_fragrance (which retrieves a fragrance).

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 implies when to use this tool: when you have a specific note slug and need its profile and top fragrances. It contrasts with list_notes for browsing, but it does not explicitly name alternatives or provide exclusion criteria, so it doesn't fully reach 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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the result includes 'top creations,' which is useful return-value context, but it does not disclose details such as sorting criteria for 'top' or possible empty results. No contradiction with 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 a single, front-loaded sentence that clearly states both the resource and the input key. Every word earns its place; there is no fluff 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?

For a simple, read-only, single-parameter lookup tool, the description is mostly complete: it names the resource, what is returned, and how to target it. It could be slightly more explicit about the meaning of 'top creations' or error behavior, but the combination of strong annotations and minimal schema makes this sufficient.

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 'slug' parameter is well documented with an example ('francis-kurkdjian'). The description repeats 'by slug' without adding new semantic detail, so it stays at the baseline for high schema coverage.

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 clearly identifies the resource ('perfumer profile') and what it returns ('their top creations'), with a specific retrieval verb ('Get'). It distinguishes this tool from sibling tools like get_brand, get_note, and get_fragrance by targeting the perfumer-specific resource.

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?

No explicit guidance is given for when to use this tool versus alternatives. The description only states the action and input ('by slug'), without mentioning exclusions, prerequisites, or related sibling tools. The context signals list siblings but the description itself provides no usage direction.

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 tool as read-only, idempotent, and non-destructive, so the description does not need to repeat those traits. It adds the 'short summary' behavioral context but does not disclose additional details like what the digest contains or any aggregation behavior. No contradiction with 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 a single, front-loaded sentence with no filler. It communicates the action, resource, and input format efficiently, earning its place completely.

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?

Given the tool's low complexity (one parameter, strong annotations, read-only operation), the description is sufficient for an agent to select and invoke it. However, since no output schema exists, a bit more detail about what the 'short summary' includes could improve completeness, though 'short summary' is reasonably clear.

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%: the single parameter id is already described as 'Fragrance id or slug'. The description's parenthetical '(id or slug)' simply repeats the schema, adding no new semantic information beyond the structured field.

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') and clearly identifies the resource as a 'short summary of a fragrance's community reviews', which distinguishes it from the sibling tool get_fragrance_reviews. It also specifies that the identifier can be an id or slug, making the purpose precise.

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 implies that this tool is for obtaining a concise digest of community reviews, but it does not explicitly mention alternatives such as get_fragrance_reviews for full review lists, nor state when not to use this tool. Usage guidance remains implied rather than 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 readOnly, openWorld, and idempotent behavior. The description adds meaningful context by specifying that similarity is based on 'accord profile', which explains the matching logic. It does not contradict annotations and provides useful domain-specific behavior beyond the structured hints.

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 conveys purpose and input without any wasted words. It is concise, easy to scan, and appropriately sized for a simple tool.

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 low-complexity tool with two parameters and no output schema, the description is complete: it states what is returned (fragrances), the similarity criterion (accord profile), and the input type (id or slug). No critical information gap exists.

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?

Input schema describes both parameters (id and limit) with clear semantics, achieving 100% coverage. The description partially reinforces the 'id or slug' aspect, but adds little beyond the schema, so the baseline 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 uses a specific verb 'Find' and clearly identifies the resource as 'fragrances with a similar accord profile', distinguishing it from sibling tools like get_fragrance (single lookup) and search_fragrances (text search). It also specifies the input as a fragrance id or slug.

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 clearly implies when to use the tool: when you want fragrances similar to a given fragrance based on its accord profile. It does not explicitly name alternative tools or state when-not-to-use, but the context is clear enough to guide selection among 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 readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral detail about aggregation windows (day, 7 days, 30 days) and the flexibility of 'id or slug', which is valuable context beyond 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?

The description is a single, front-loaded sentence. Every word adds value, and there is no redundancy or filler. It is concise without sacrificing 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?

The tool is simple: one parameter, no output schema, and strong annotations. The description fully explains the aggregation behavior and time ranges. It is complete for this low-complexity tool with good annotation coverage.

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%: the single parameter `id` is described as 'Fragrance id or slug' in the schema. The description repeats 'id or slug' but adds no extra syntactic or semantic detail, so it meets the baseline without exceeding 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?

The description uses a specific verb 'Aggregate' with a clear resource 'wearing counts for a fragrance' and scope 'over the last day, 7 days, and 30 days'. This is precise and distinguishes it from sibling tools like get_fragrance or trending.

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 clearly implies when to use the tool: when you need aggregated wearing counts over specific time windows. There are no explicit exclusions or alternatives named, but the unique purpose and sibling context make the use case obvious.

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, and non-destructive behavior. The description adds the 'all' scope, which is slightly beyond annotations but doesn't disclose additional behavior like pagination or ordering. It doesn't contradict annotations, but contributes minimal unique behavioral context.

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, well-structured sentence with no redundancy. It front-loads the core action and resource, making it maximally concise and easy to parse.

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

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

Given the tool's simplicity (zero parameters, no output schema) and strong annotations, the description fully covers the necessary context. 'List all accord families' is complete for a read-only, list-all operation. No further details are required.

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 has zero parameters, so the schema provides no meaning. The description clarifies that the operation targets 'all accord families', which is sufficient for a no-argument call. Baseline for 0 parameters is 4, and the description meets that 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?

The description clearly states the action ('List') and the resource ('accord families'), making it unambiguous. It distinguishes itself from sibling tools like 'list_notes' and 'list_brand_fragrances' by naming a different specific resource.

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 usage context is implied: use this tool when you need all accord families. However, there is no explicit 'when to use vs alternatives' or exclusion guidance. Since it's a unique list-all tool with no filters, the context is straightforward but not explicitly 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, idempotentHint, and destructiveHint=false, establishing a safe read operation. The description adds valuable behavioral context beyond annotations by specifying ordering ('by community score') and pagination, which are not inferable from annotations alone.

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 sentence that is front-loaded with the verb 'Get' and includes no wasted words. It efficiently conveys the core action, scope, ordering, and pagination.

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 thoroughly cover safety and idempotency, and the description covers ordering and pagination. No output schema exists, but a list tool's return shape is reasonably implied as a list of fragrances. Slight gap in not describing the exact response structure, but this is a simple paginated list and the overall context is adequate.

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?

Input schema covers all three parameters with descriptions (100% coverage). The description does not add additional semantic detail beyond what the schema already provides, so 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 clearly states the action ('Get'), the resource ('a brand's full catalogue'), and the key parameter ('by slug'). It distinguishes from sibling tools like get_brand (which retrieves brand info) and search_fragrances (which searches across brands).

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 'full catalogue' implies this is for retrieving all fragrances for a specific brand, but it does not explicitly contrast with sibling search tools or state when to use this over alternatives. Usage context is implied rather than 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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the semantic detail that it lists chart rankings and mentions 'slug' for the leaderboard, but does not disclose any additional behavioral traits (e.g., rate limits, auth, return format). This is consistent with annotations but not additive beyond them.

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 two short, front-loaded sentences. The first sentence states the primary purpose, and the second provides a useful pointer to a sibling tool. There is no redundant or filler text, earning a perfect score for conciseness.

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-only list tool with no output schema, the description is fully adequate. It explains what is listed (available chart rankings) and how to obtain more detail (use get_chart). The sibling context and annotations further round out the tool's behavior, so no additional information is needed.

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 are zero parameters and the schema emptiness is fully described (100% coverage). The baseline for zero parameters is 4, and the description doesn't need to compensate for missing schema information. The description's mention of 'slug' implicitly hints at the output shape, which is helpful.

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 'List' with a clear resource 'available chart rankings', and explicitly distinguishes from the sibling tool get_chart by directing users to use get_chart for the full leaderboard. This makes the purpose unambiguous and 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?

The description provides explicit usage guidance by stating the tool's purpose (listing available chart rankings) and offering a direct alternative: 'Use get_chart with a slug for the full leaderboard.' This tells the agent when to use this tool versus the sibling, satisfying the when/when-not/alternatives criterion.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the browsing/filtering scope, which is helpful but not rich behavioral context beyond the schema. It does not contradict 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 that is front-loaded with the action and resource, followed by optional filters. Zero wasted words; every element adds value.

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 low-complexity list tool with three optional params fully described in the schema and comprehensive annotations, the description is sufficiently complete. No output schema exists, but the purpose is clear enough that return values are predictable.

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%—all three parameters have clear descriptions in the schema. The description merely restates some of this (filtering by family, sorting) without adding new meaning. Baseline 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 uses the specific verb 'Browse' with resource 'fragrance notes', clearly indicating the tool lists notes with optional filtering and sorting. This distinguishes it from siblings like get_note (singular note retrieval) and list_accords (different entity).

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 clearly implies when to use the tool: to browse notes, optionally filtered by family and sorted. It does not explicitly mention alternatives or exclusions, but the context is unambiguous given the tool's name and sibling set. No misleading 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 the tool as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds minimal behavioral context beyond scope; it does not describe result ordering, defaults when type is omitted, or pagination. This earns a baseline 3 given annotation coverage.

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 two short sentences, front-loaded with the core purpose and then a clear alternative sibling reference. Every word earns its place with no fluff 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?

Given the simple three-parameter schema, rich annotations, and explicit sibling guidance, the description is complete for an agent to select and invoke this tool correctly. No output schema is present, but none is necessary for a search endpoint with this limited scope.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (q, type, limit) with their constraints. The description adds no additional parameter-level detail, meriting the 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 the tool searches across multiple entity types (fragrances, brands, notes, perfumers, collections) in one call, giving a clear verb, resource, and scope. It also distinguishes itself from the sibling search_fragrances by positioning itself as the broad, all-in-one search.

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 explicitly guides users to use search_fragrances for filtered fragrance queries, clearly delineating when to use this general search versus the more specialized sibling. The phrase 'Good for quick lookups' provides additional context for appropriate use cases.

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 tool as read-only, open-world, idempotent, and non-destructive. The description adds the behavioral constraint that at least one filter is required, and it clarifies the pagination mechanism via cursor. 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 two sentences, front-loaded with purpose, and every clause earns its place. It states the core action, the pagination feature, a required precondition, and the alternative tool without any 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?

Considering the 7 parameters are fully detailed in the schema and annotations cover safety traits, the description completes the picture by explaining filter requirements, pagination style, and the differentiation from 'search'. It is sufficiently complete for an agent to select and invoke the tool 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?

While the schema covers 100% of parameter descriptions, the description adds meaningful grouping: it identifies which parameters act as filters (q, brand, note, family, price_range) and implies that limit and cursor are pagination controls. It also imposes a business rule (at least one filter) not present in 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 clearly states the tool filters fragrances and uses cursor pagination, with a specific verb ('Filter') and resource ('fragrances'). It distinguishes itself from the sibling 'search' tool by contrasting 'open keyword lookups' with filtered queries.

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 guidance is given: this tool is for filtered fragrance searches (requiring at least one filter), while the 'search' tool is for open keyword lookups. This directly tells the agent when to use this tool versus an alternative.

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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds 'right now' to indicate temporal freshness, which complements the openWorldHint. However, it doesn't disclose response format or any additional behavioral traits beyond what annotations already provide.

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 phrase that communicates the tool's purpose with no wasted words. It is front-loaded and easy to parse.

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

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

The tool is simple with one optional parameter and no output schema. The description states the content (trending queries and fragrances) but does not clarify the response structure or whether they are returned together or separately. Given the annotations and simplicity, it is adequate but leaves minor ambiguity.

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 'limit' parameter, which has a clear description. The tool description adds no additional parameter context, so the baseline 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 specifies the resource: trending search queries and most-worn fragrances. It is clear and distinct from siblings like list_charts, but lacks a verb and doesn't explicitly contrast with other 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?

No guidance is provided on when to use this tool versus alternatives. The description simply states what it returns without mentioning context, exclusions, or sibling comparisons.

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