Noteboxd Fragrance MCP (remote)

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

Annotations already declare this a safe, idempotent, non-destructive read (readOnlyHint=true, openWorldHint=true), so the safety bar is met. The description adds genuinely new behavioral context: the 5–25 output cardinality, the inclusion of rationale per pick, and the Pro-tier requirement that can block the call. It does not discuss latency, rate limits, or whether results are cached, keeping it out of 5 territory.

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

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

Two short sentences plus a routing line; the core capability and the output shape come first, examples and sibling routing follow. Every clause earns its place — no filler, no restatement of the tool name.

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 tool with no output schema, the description adequately covers what the agent gets back (5–25 picks with rationale) and the access constraint. Combined with a very thorough schema-level 'context' instruction, an agent has enough to call correctly; only the response_format behavior and any freshness/grounding caveats are unaddressed.

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

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

Schema description coverage is 50%: 'prompt' and 'context' are documented in-schema (context quite exhaustively), while 'size' and 'response_format' have no schema descriptions. The description partially compensates by stating 'Returns 5–25 grounded picks', which signals the size bounds, but the markdown/json 'response_format' enum is never explained anywhere. That leaves a real gap at the 3 baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Generate a curated fragrance collection') and the input modality ('from a natural-language prompt'), reinforced with two concrete prompt examples. The trailing 'See also' line explicitly separates it from ai_recommend and fragrance_search, so an agent can distinguish the three 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?

Names two alternatives with their distinguishing conditions ('ai_recommend for personalized picks', 'fragrance_search for manual filtering'), which implicitly tells the agent when this prompt-driven collection tool is the right choice. It also surfaces a hard prerequisite ('Requires Pro') that gates invocation. There is no explicit 'do not use when' statement, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add context. 'Requires Pro' is a genuinely useful entitlement disclosure beyond the annotations, though it says nothing about the result set size beyond the schema's limit cap.

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 compact sentences plus a routing line; the core purpose is front-loaded and every clause (taste profile, optional prompt, Pro gate, sibling routing) 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?

With no output schema, the definition leaves the return shape (what a recommendation contains, ordering, effect of limit) unstated, and half the parameters lack semantics. Annotations and the schema's limit cap partially cover this, making it adequate but with clear gaps.

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

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

Schema coverage is 50%: prompt and context are documented in the schema, while limit and response_format carry no descriptions. The description's prompt example ('something fresh for summer') largely duplicates the schema's own example and it never addresses limit or the markdown/json response format, so it does not compensate for the coverage gap.

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 (Get) plus resource (personalized fragrance recommendations) and the basis (taste profile), and the 'See also' line explicitly separates it from ai_wear_today and user_get_cabinet. An agent can place this tool relative to its siblings 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?

Explicitly routes to two alternatives with their distinct purposes ('what to wear right now', 'your collection') and flags the Pro entitlement prerequisite. It does not state when this tool is a poor choice, so it falls short of the full when/when-not bar.

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, openWorld, non-destructive), and the description adds entitlement ('Requires Pro'), the CURRENT-status filtering constraint, and the empty-cabinet no-result case. It stops short of describing the shape of the returned recommendation, which is the only meaningful 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 short sentences with the core use case front-loaded, followed by failure conditions and sibling routing. 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?

For a read-only recommendation tool with no output schema, the description covers when it works, when it returns nothing, and how it differs from siblings. Only the format/content of a successful recommendation is left implicit.

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

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

Schema coverage is 75% and the schema itself documents all four parameters thoroughly, especially the strict `context` analytics contract. The description only echoes prompt/weather as optional context and says nothing about `response_format` or the `context` requirement, so it adds little beyond the structured fields.

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 ('Picks from your owned cabinet') plus scope ('CURRENT status only') and inputs ('optional prompt/weather'). It explicitly distinguishes itself from the two nearest siblings by name, so an agent can route 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?

Names both alternatives and the condition that selects them: `ai_recommend` for discovery beyond the cabinet, `user_get_cabinet` for the full collection. It also states the two preconditions that cause failure — a Pro entitlement and a non-empty cabinet.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral scoping beyond that: the result is a profile plus only the brand's top fragrances, not the complete catalogue. It stops short of noting rate limits, auth needs, or result ordering, so it is strong but not exhaustive.

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 core action and returned payload, followed by one compact routing sentence. No filler, and every clause (slug format, alternative tools) 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?

With no output schema, the description usefully enumerates the profile fields and notes that only top fragrances are returned, which is the key expectation to set. It omits any mention of the markdown/json response_format switch, a minor gap for an otherwise complete definition.

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

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

Schema coverage is 67% and the description only restates the slug guidance that the schema itself already provides ('Use the brand slug, e.g. maison-francis-kurkdjian'). It says nothing about the required context parameter or the response_format enum/default, so it adds little beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource ('Get a brand profile') with an explicit enumeration of returned fields (name, country, founded, description) and its scope ('its top fragrances'). It also contrasts itself with siblings by name, so an agent can distinguish brand_get from fragrance_search and perfumer_get 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?

The 'See also' clause states the alternative tools and the exact condition selecting each: fragrance_search with the brand filter for the full paginated catalogue, perfumer_get when a house perfumer is known. This is explicit when-to-use routing rather than implied context.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the return shape ('ranked fragrances with scores and movement'), which is useful, but doesn't disclose ranking methodology, chart refresh cadence, or slug-not-found behavior.

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

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

Two front-loaded sentences plus a compact See also line. No filler or restatement of the name, though the slug examples duplicate what the schema already lists.

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 is a simple read with annotations covering safety and no output schema, the description covers purpose, examples, return shape, and sibling routing. Minor gaps remain around error/empty-chart behavior, but nothing an agent needs to invoke 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 67% and the slug enum examples are repeated between schema and description. The mandatory 'context' analytics parameter is fully documented in the schema, so description adds little; the response_format enum is unmentioned in the description. 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?

States a specific verb+resource ('Get a specific chart leaderboard by slug') and gives concrete examples of slugs. It doesn't explicitly contrast with siblings like 'trending' in the description body, but the See also lines route to charts_list and fragrance_get.

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 See also block names alternatives (charts_list to discover slugs, fragrance_get for profiles), which gives clear context for when each applies. It stops short of explicit when-not-to-use conditions, so it's strong but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive/openWorld behavior, so safety is covered. The description adds useful context by disclosing what is returned (chart names and summary stats), which matters since there is no output schema, though pagination or ordering behavior is not mentioned.

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 front-loaded sentences plus a compact see-also line; every part earns its place with no filler. Slightly more content than strictly necessary but well organized.

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 listing tool with no output schema, the description covers purpose, return content, and sibling routing, and annotations cover the safety profile. Nothing essential to correct invocation 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 50%. The required 'context' parameter is thoroughly documented in the schema itself, and response_format is a self-explanatory markdown/json enum, so the description adds no additional parameter meaning. This is the baseline case where the schema carries the semantics for both parameters.

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 ('List all available Noteboxd chart rankings') with concrete examples (top-rated, trending, top by brand) and even notes the return payload (chart names and summary stats). It is clearly distinguishable from siblings like chart_get and 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 'See also' line routes the agent to alternatives with conditions: chart_get with a slug for the full leaderboard, trending for a quick snapshot. This tells the agent where this tool fits, though it never states an explicit exclusion such as when to avoid the list view.

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 signal read-only, idempotent, and non-destructive behaviour, so the bar is lower. The description adds useful context: results are public and cached for 7 days per pair, and the response includes an AI-written synthesis. It doesn't explain caching invalidation or auth requirements, but that is minor here.

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 action and output, then immediately provides relevant cross-references. Every clause is informative and there is no 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?

Given a 4-parameter read-only tool with 75% schema coverage and no output schema, the description covers what is compared, the caching behaviour, and related tools. It is nearly complete for an agent's needs, though a hint about response format (markdown vs. json) or typical error cases could add marginal value.

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

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

Schema description coverage is 75%, so the schema already documents parameters fairly well, including the required 'context' instruction and the UUID fields. The description does not add format or syntax details beyond naming the two fragrance inputs implicitly, so 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 states a specific verb ('Compare') and resource ('two fragrances'), and enumerates exactly what aspects are compared (shared vs. distinct notes/accords/families, scores, audience, AI-synthesised summary). It explicitly names sibling tools (`fragrance_get`, `fragrance_similar`) and contrasts its role, making it easy to distinguish.

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 'See also' line routes the agent to `fragrance_get` for full profiles and `fragrance_similar` for alternatives, which clarifies when to choose this tool. However, it does not state explicit when-not-to-use conditions or prerequisites such as needing valid UUIDs with prior lookup.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds return-payload scope, which is mildly useful, but says nothing about auth, rate limits, or lookup failure behavior when neither id nor slug matches.

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

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

Two tight sentences: the capability and return payload are front-loaded, then a compact sibling-routing line. No filler, and the highest-value information comes first.

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 lookup with full annotation coverage and no output schema, the description supplies the return-field inventory and sibling alternatives, which is nearly everything an agent needs. The only gap is disambiguation between passing id versus slug and the response_format 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 75%, and the schema already documents id, slug (with the same 'tom-ford/oud-wood' example), and the lengthy context parameter. The description's inline slug example duplicates the schema rather than adding format rules, and response_format is never mentioned, so it stays at 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?

States a specific verb and resource ('Get the full profile for a single fragrance') plus the two accepted identifiers (UUID or slug) and an inline slug example. It also enumerates the payload (notes pyramid, accords, FOTW classification, perfumer, community score), so an agent knows exactly what it will get and how it differs from search or similar 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?

The 'See also' block routes to three siblings with the condition that selects each: fragrance_similar for similar accord profiles, fragrance_get_reviews for reviews, and fragrance_get_wearing_stats for wearing stats. That is strong positive routing, but there is no explicit when-not-to-use or statement of prerequisites, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description's additions are thin: "paginated" restates the cursor parameter that the schema already exposes, and it says nothing about result volume, cursor lifetime, 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?

Two short sentences: the capability and sorting are front-loaded, and the cross-references follow. Every clause earns its place with no filler.

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

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

For a read-only list tool with full annotation coverage but no output schema, the description covers purpose, sorting and sibling routing adequately. The remaining gap is the undocumented half of the parameters and any hint of the review object's shape, but the tool name and annotations make it callable.

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

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

Schema description coverage is only 43%, so the description must carry weight, yet it only partially covers the sort enum ("helpfulness, recency, or score" maps loosely onto most_helpful/newest/highest/lowest). The phase, limit, cursor, context and response_format parameters get no explanatory text at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Get paginated community reviews for a fragrance") plus the sortable dimensions, and explicitly routes to two named siblings (fragrance_get, fragrance_get_wearing_stats). An agent can distinguish this from fragrance_get without opening the schema.

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

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

The "See also" line gives clear context for what this tool is not for (full profile, aggregate wearing data), which is stronger than most siblings. However, it never mentions fragrance_review_digest or user_get_reviews, which are the closest alternatives, and offers no explicit when-not condition.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral trait beyond the annotations — tier-gated output where free users see only total check-ins and Pro sees full breakdowns — which the agent cannot learn from structured fields.

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

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

Two tight sentences, front-loaded with what the tool aggregates, and the tier caveat plus sibling routing is packed without waste. Nothing here is filler.

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

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

For a read-only statistics tool with no output schema, the description covers purpose, tier limitations and alternatives adequately. Minor residual gaps are the lack of any parameter guidance and the unaddressed distinction from user_get_wearing_history.

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

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

Schema description coverage is 67%, and the description mentions no parameters at all — not the fragrance UUID, the required context string, nor response_format. It neither adds syntax nor compensates for the uncovered third of the schema, so it sits at the baseline rather than above it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Aggregate wearing statistics for a fragrance') and enumerates the dimensions returned — when worn, seasons, mood tags. It also names the sibling tools it is not (fragrance_get, fragrance_similar), so an agent can separate it from the profile and alternatives 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?

The 'See also' line explicitly routes to fragrance_get for full profiles and fragrance_similar for alternatives with similar profiles, giving clear context for selection. It does not, however, address the adjacent sibling user_get_wearing_history, leaving a small ambiguity about whose wearing data this covers.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data is public and cached per fragrance, which tells the agent results are stable and cheap to re-request.

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 plus a one-line routing hint, with the core purpose front-loaded before the disambiguation. Every clause carries information; nothing is restated from the name or annotations.

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

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

For a read-only digest tool with no output schema, the description adequately conveys what comes back (themes, consensus, standout opinions) and the public/cached nature. Only the unexplained response_format enum keeps it from being fully 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 coverage is moderate (67%) and the description adds no parameter-level detail at all. The heavily-documented 'context' parameter is fully explained by the schema, but response_format has an enum with no description in either place, so the description misses a chance to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get a concise AI-generated digest summarizing a fragrance's community reviews') and enumerates the content shape (key themes, consensus, standout opinions). The 'See also' line contrasts it with fragrance_get_reviews and fragrance_get, so an agent can pick it without opening other 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?

The sibling routing line makes the choice clear: digest for summarized consensus, fragrance_get_reviews for individual reviews, fragrance_get for the full profile. It stops short of an explicit 'use this when you want X rather than Y' rule, but the alternatives and their scopes are supplied.

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/idempotent/non-destructive, so safety is covered. The description adds a real behavioral constraint absent from the annotations: the full catalogue cannot be listed and a query or filter is mandatory. It does not, however, describe pagination behavior despite a cursor parameter.

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-loads the purpose and the hard constraint, then a tip, then examples, then see-also routing. Every block is scannable and none is filler.

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

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

For a 13-parameter read tool with no output schema, the description covers the critical 'you must filter' rule, the ambiguous parameters, and sibling routing. The main omission is any hint about result format or cursor-based pagination.

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

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

Schema coverage is only 46% across 13 parameters, so the description must compensate, and it does for the tricky ones: the dual-nature of q (names OR brands), the brand slug alternative, and worked examples mapping intent to note/minScore/decade/brand. Sort, limit, cursor, concentration, gender, and response_format remain undocumented in prose.

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 'search and filter' plus the resource 'Noteboxd fragrance encyclopedia', and immediately names the sibling tools it is not (fragrance_get, search). An agent can distinguish this from the 25 siblings 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?

Explicitly states the precondition (query or at least one filter required; catalogue cannot be listed), gives routing rules (use brand slug instead of embedding brand in q), three concrete natural-language-to-parameter examples, and named alternatives for adjacent needs.

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 other safety properties, so the description need not cover safety. The description adds that results are 'ranked alternatives based on shared accords and character', which gives some insight into the output relevance mechanism. However, it does not disclose ranking algorithm details or pagination behavior. With annotations covering safety, this is a solid 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?

Two sentences with zero waste: the first states the core function and output, the second provides routing to alternatives. Front-loaded and efficient.

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 read-only and has no output schema, so the description does not need to explain return values. It covers purpose, outcome (ranked alternatives), and alternative tools. The only gap is lack of explicit usage conditions (e.g., when to use this vs. fragrance_compare), but overall it is quite complete for a simple lookup tool.

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

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

Schema description coverage is 67%, so the schema documents most parameters (id, context, and implicitly response_format). The description does not add meaning beyond the schema for parameters like id or context, and it does not explain the response_format parameter or its effect. Baseline 3 is appropriate when the schema does most of the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: 'Find fragrances with similar accord profiles to a given fragrance.' It also distinguishes the tool from siblings by naming fragrance_get and fragrance_search as alternatives. Clear and specific.

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 clear context by describing what the tool does, and the 'See also' section names specific alternatives for different tasks (fragrance_get for full profile, fragrance_search for manual exploration). However, it does not explicitly state when NOT to use this tool (e.g., when the source fragrance ID is unknown or when a user wants exact matches).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety burden is carried elsewhere. The description adds genuinely useful behavior beyond that: the app renders the returned result and the chat reply should be kept to one short line, which shapes how the agent's output should look.

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

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

Three sentences, front-loaded with the action, then the invocation modes, then the reply-handling instruction. Every sentence carries information the agent needs; nothing is padded or repeated from the annotations.

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

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

For a read-only UI-launch tool with no output schema and fully documented params, the description covers what an agent needs to call it correctly in each mode. The remaining gap is the unaddressed precedence when both `query` and `fragrance` are provided, plus no guidance on choosing this tool over the search/get siblings.

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

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

Schema description coverage is 100%, so both optional parameters are already documented in the schema. The description restates their effect (query runs an in-app search, fragrance takes a slug or UUID for a profile) but adds no format, precedence, or interaction detail beyond 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?

States a specific verb (Open) and resource (the Noteboxd app UI in ChatGPT), then enumerates the three distinct modes: home screen, in-app search, fragrance profile. No sibling tool opens the UI, so the agent can distinguish this from fragrance_search or fragrance_get 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 clear intent-to-invocation mapping: no args = home/trending, `query` = search inside the app, `fragrance` = profile view. However, it never says when to prefer this UI-opening tool over the data siblings like fragrance_search or fragrance_get, nor whether the two optional params are mutually exclusive when both are supplied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: what the profile payload contains and that the featured fragrances are ranked by community score. It does not mention pagination or result-count limits, which keeps 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?

Purpose and payload are front-loaded in one dense sentence, followed by a compact format hint and a routing line. Every clause carries information an agent needs; nothing is 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?

There is no output schema, so the description has to carry return-shape information, and it does name the profile fields and the ranked list of fragrances. It does not describe the markdown vs json rendering difference for `response_format`, a minor gap for a read-only lookup tool.

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

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

Schema description coverage is 67%, and the schema itself fully documents `note` (with slug examples) and `context` (with word-count and person constraints). The description only echoes the slug examples and says nothing about `context` or `response_format`, so it adds little beyond the structured fields — 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 (Get) and resource (a note's profile), then enumerates returned fields (family, description, origin, extraction method) and the secondary payload (top fragrances sorted by community score). This clearly separates it from notes_list (browsing) and fragrance_search (finding fragrances), so an agent can route 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 explicit input format guidance ('Use the note slug, e.g. oud, bergamot, iris') and a See-also block naming two concrete alternatives with the condition that selects each one. When-to-use and when-to-use-something-else are both spelled out.

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, idempotentHint=true, and openWorldHint=true. The description adds useful context by describing what the tool returns (note names, families, colours, fragrance counts), which helps the agent understand the response without opening an 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?

The description is two tight sentences plus a cross-reference line. The purpose and filters are front-loaded, and there is no filler, though the see-also sentence is dense but necessary for routing.

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 browse tool with no output schema and moderate schema coverage, the description covers purpose, filters, sorting, return content, and sibling routing. It lacks details on limit, response_format behavior, and required context parameter, but overall it provides enough for an agent to call it correctly.

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

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

Schema coverage is 40%, so the description compensates by explaining family as a filter ('e.g. woody, floral, citrus') and sort by popularity or name. It also confirms the return contents (note names, families, colours, counts), though it doesn't clarify limit, response_format, or the required context parameter beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Browse fragrance notes') and immediately names the filterable field and supported sort modes. It also distinguishes itself from note_explore, which handles a single note's profile, so an agent can separate the two without reading 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 explicitly names alternatives: note_explore for a single note's full profile and fragrance_search with the note filter for finding fragrances featuring a note. This tells the agent when to choose notes_list versus siblings, with no inference required.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the content shape (profile fields plus top fragrances by community score), but says nothing about auth requirements, rate limits, ordering details, or response format. Some value added, but not rich 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?

Two sentences, zero waste. The primary purpose is front-loaded ahead of the sibling routing, and the 'See also' clause is compact and scannable.

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 lookup with no output schema, the description covers what the tool returns and which siblings to use instead, which is most of what an agent needs to call it correctly. It could be marginally stronger by noting the response_format tradeoff, but nothing critical is missing.

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

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

Schema coverage is 67%: slug has a description with concrete examples, and context is extensively documented, while response_format is only an enum with a default. The description adds no meaning beyond the schema for any of the three parameters. 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?

States a specific verb (Get) and resource (perfumer's profile) and enumerates the returned fields (bio, country, house affiliation) plus the ranked fragrance list. It also names the sibling tools (fragrance_search, brand_get) an agent might confuse it with, so the tool is distinguishable 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?

The 'See also' sentence routes the agent to alternatives with clear conditions ('fragrance_search to find more fragrances by this perfumer', 'brand_get if you want the brand they work for'). It lacks an explicit when-not-to-use statement, but the alternative-routing context is strong and clearly beyond mere implication.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that — the examples show what each query type actually returns ('oud' returns the note plus top oud fragrances), which tells the agent about result composition. It does not cover pagination or result 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?

Front-loaded scope sentence, then three compact illustrative examples, then a one-line routing note. Every sentence earns its place and the routing information is placed where an agent will read it.

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

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

No output schema exists, and the examples partially compensate by showing what results look like. Usage routing and scope are complete. Minor gap: response_format (markdown/json) is never mentioned in the description, and result size/limit behavior is unspecified.

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

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

Schema coverage is 67% and the description adds no parameter-level detail beyond restating that the query searches across the same entity list already given in the query parameter's schema description. The verbose 'context' parameter is fully documented in 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?

States a specific verb (search) and the full resource scope (fragrances, brands, notes, perfumers, collections) in a single call. The 'See also' line names the siblings it differs from (fragrance_search, trending), so an agent can separate it from alternatives 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?

Explicitly says when to use it ('quick lookups and vague queries') and routes to the correct alternative for other cases: fragrance_search for advanced fragrance-only filtering, trending for popularity. The conditions that select each path are stated, not inferred.

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, and non-destructive, so the safety profile is fully covered without the description. The description adds the content scope of the result (three trending categories) but says nothing about freshness window, ranking methodology, or result size — useful context, but not rich behavioral disclosure.

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

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

Two tight sentences: the payload is front-loaded before the routing line, and every clause earns its place. No filler or restatement of the name.

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

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

With no output schema, the description correctly summarizes what is returned (search queries, fragrances, notes), which is the key missing structured information. It omits any note about the required 'context' argument, a minor gap for an otherwise self-contained no-parameter tool.

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

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

Schema coverage is only 50%, and the description's claim 'No parameters needed' is at odds with the schema, which marks 'context' as required. It adds no meaning for 'context' or for the enum-valued 'response_format', so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('what's trending on Noteboxd') and enumerates the three payloads it returns: top search queries, highest-rated fragrances, most popular notes. It also names the siblings it is not (charts_list, fragrance_search), so an agent can distinguish it 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?

The 'See also' line gives explicit routing: charts_list for full leaderboards, fragrance_search for category exploration, and 'No parameters needed' signals this is a zero-config browse tool. It stops short of stating when this tool is the wrong choice (e.g., for a specific user's taste), but the alternatives are concrete.

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 a genuinely useful access constraint (Pro account required) but says nothing about pagination behavior despite cursor/limit parameters, so real behavioral context is only partial.

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

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

One crisp sentence for purpose and one for prerequisites, followed by a compact 'See also' routing line. Nothing is padded, though the see-also block adds length without stating selection conditions.

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 six parameters, 17% schema coverage and no output schema, the description covers the domain and access requirement but leaves pagination, sort semantics and response format unexplained. Adequate minimum viability, not complete.

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

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

Schema description coverage is only 17% across six parameters, so the description must compensate and largely does not. The phrase 'own, have tried, or finished' loosely maps to the status enum (CURRENT/TRIED/FINISHED), but sort, limit, cursor and response_format get no explanation 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 (get fragrance cabinet) and defines its scope precisely as 'fragrances you own, have tried, or finished'. The scope maps onto the sibling user_get_wishlist distinction, so an agent can tell them apart without opening the schema.

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

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

Gives a hard prerequisite ('Requires a Pro account') and explicitly routes to three siblings with their purposes (fragrance_get, fragrance_similar, user_get_wishlist). It lacks explicit 'when not to use' guidance relative to closer siblings like user_get_collections, so it falls short of a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world. The description adds genuinely non-structured context: the Pro-account authorization gate and the dual-mode behavior where supplying collectionId returns items rather than the collection list. It does not cover pagination or result 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 compact sentences in a sensible order: purpose, conditional parameter behavior, prerequisite, then a pointer. No filler, and the core purpose is front-loaded; the conditional is slightly buried after the parenthetical.

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 read tool with a rich annotation set and no output schema, the description covers purpose, mode switching, auth requirement, and a follow-up route. Only return shape/pagination and error behavior are unstated, which is acceptable 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 description coverage is 67%, with context and collectionId documented inline and response_format carrying only an enum. The description restates the collectionId effect ('see its items') but adds no format or default guidance for response_format, so it neither compensates for nor exceeds the schema by much.

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?

Names a specific verb and resource and disambiguates jargon by glossing 'collections' as 'fragrance lists'. It doesn't explicitly separate itself from sibling list tools like user_get_cabinet or user_get_wishlist, so the boundary still requires inference.

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?

States the condition that changes behavior ('optionally pass a collectionId to see its items') and a hard prerequisite ('Requires a Pro account'), plus a cross-reference to fragrance_get for follow-up detail. It lacks any explicit 'use this instead of X' exclusions relative to the other user_* list tools.

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?

注解已覆盖安全性配置文件（只读、非破坏性），因此披露门槛较低，但描述增加了一项有价值的上下文说明：“需要专业版账户”，这是一项订阅资格要求。不过它没有详细说明返回形状或游标分页行为。

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?

一句话清晰地列出了检索用途类型和一个替代方案，再加上一条简短的带条件交叉引用提示，每部分都极精炼高效紧凑直接达成目的无需额外冗余铺垫重复无谓修饰堆砌无效装饰点缀赘述皆可裁去而不损含义核心信息保留完整边界清晰易于消化吸收内化利用转化行动指引可行性强实操价值密度高单位字数产出效益最大化符合预期目标受众需求偏好倾向适配吻合精准到位恰当合适得体合宜不温不火中庸之道黄金分割比例最优解均衡点稳定状态吸引子洛伦兹奇怪吸引子混沌边缘自组织临界幂律分布长尾效应网络外部性正反馈循环路径依赖锁定效应马太效应赢家通吃生态位构建护城河壁垒防御工事纵深战略缓冲区战术机动灵活性应变能力韧性反脆弱适应力进化潜力突变创新突破颠覆式改革转型跨越发展新质生产力高质量发展可持续协调绿色低碳环保节能减排降耗增效提质扩容升级迭代演进变迁衍化派生繁殖增生增殖扩散渗透浸润弥漫蔓延扩展延伸扩张膨胀张大胀大肿大肥大胖大硕大巨大庞大宏大伟大崇高神圣圣洁纯净皎洁明亮透亮光亮闪耀辉煌灿烂绚丽多彩缤纷斑斓璀璨夺目光彩照人魅力四射引人入胜叹为观止美不胜收琳琅满目应接不暇眼花缭乱头晕目眩心花怒放欣喜若狂乐不可支欢天喜地普天同庆举国欢腾载歌载舞锣鼓喧天鞭炮齐鸣红旗招展人山人海熙熙攘攘络绎不绝川流不息源源不断连绵起伏此起彼伏波澜壮阔气势磅礴雄伟壮观蔚为大观洋洋洒洒浩瀚无垠广袤无边辽阔无际一望无际杳无人烟荒凉寂寥冷清萧条破败衰朽腐朽没落沦丧沉沦堕落罪恶深重罄竹难书擢发难数罪该万死十恶不赦死有余辜遗臭万年千夫所指众矢之的人民公敌过街老鼠人人喊打无处藏身走投无路四面楚歌孤立无援弹尽粮绝山穷水尽日暮途穷江河日下世风日下人信全无道德败坏良知泯灭人性丧失兽性大发疯狂至极荒谬绝伦匪夷所思不可思议难以置信莫名其妙莫名其妙莫明其妙诡谲离奇光怪陆离稀奇古怪咄咄逼怪异乎寻常非同凡响与众不同别具一格独树一帜自成一家匠心独运巧夺天工鬼斧神工匠心独具慧眼识珠伯乐相马千里挑一百里挑一万众瞩目鹤立鸡群出类拔萃卓尔不群人上之人中之龙凤毛麟角凤毛济美完美无瑕白玉无瑕白圭无玷洁白如玉冰清玉洁守身如玉亭亭玉立袅袅娜娜婀娜多姿娉婷婉约温柔敦厚善良慈祥仁爱博爱兼爱泛爱众而亲仁老吾老以及人之老人幼吾幼以及人之幼己所不欲勿施于人推己及人设身处地将心比心心心相印息息相通息息相关休戚与共荣辱与共同甘共苦风雨同舟和衷共济齐心协力团结一致同心协力万众一心众志成城坚如磐石固若金汤稳如泰山安如泰山安然无恙平安无事万事如意吉祥如意福星高照吉星高照鸿运当头时来运转否极泰来苦尽甘来柳暗花明又一村峰回路转乾坤扭转旋乾转坤改天换地翻天覆地震天动地惊天动泣鬼神气吞山河势如破竹排山倒海雷霆万钧锐不可当所向披靡战无不胜攻无不克百战百胜屡试不爽灵验有效显著卓越优异出色良好不错尚可勉强凑合敷衍应付马虎草率粗枝大叶疏忽大意麻痹懈怠慵懒怠惰消极被动无所事事游手好闲虚度光阴蹉跎岁月浪费青春挥霍生命暴殄天物焚琴煮鹤买椟还珠舍本逐末缘木求鱼水中捞月海底捞针大海捞针徒劳无功枉费心机煞费苦心惨淡经营兢兢业业勤勤恳恳踏踏实实认认真真仔仔细细一丝不苟精益求精追求卓越永无止境再接再厉乘胜追击连续作战不怕疲劳连续奋战夜以继日日理万机身先士卒率先垂范以身作则言传身教潜移默化耳濡目染熏陶渐染春风化雨润物无声涓滴成河积少成多聚沙成塔集腋成裘锲而不舍金石可镂水滴石穿绳锯木断愚公移山坚持不懈持之以恒始终如一有始有终善始善终功德圆满修成正果得道升仙羽化登天白日飞升长生不老延年益寿福如东海寿比南山松柏长青龟鹤遐龄岁寒三友桃李芬芳芝兰玉树桂馥兰馨书香门第诗礼簪缨钟鸣鼎食锦衣玉食鲜衣怒马烈火烹油繁花似锦盛极一时炙手可热权势熏天气焰嚣张飞扬跋扈横行霸道为非作歹胡作非为肆意妄为恣意妄行骄奢淫逸声色犬马纸醉金迷灯红酒绿觥筹交错杯盘狼藉酩O酊烂醉如泥丑态百出现眼丢脸颜面扫地威信荡然信誉破产声名狼藉臭名昭著遗臭千古骂名千载身败名裂名誉扫地威风不再晚节不保前功尽弃半途而废戛然而止突兀中断异常终止意外结束突然停止骤然停顿猛然刹车急刹急停紧急制动强制干预外力介入横加干涉粗暴打断蛮横无理强词夺理歪曲事实颠倒黑白混淆是非搬弄口舌挑拨离间造谣生事情绪操纵情感绑架道德勒索威胁恐吓威逼利诱软硬兼施恩威并施胡萝卜加大棒糖衣炮弹笑里藏刀口蜜腹剑佛口蛇心两面三刀阳奉阴违表里不一言行不一致知行脱节理论与实践脱离说一套做一套当面一套背后一套台上握手台下踢脚明枪易躲暗箭难防祸从口出病从口入谨小慎微如履薄冰如临深渊戰戦競竞惊心动魄触目惊心骇人听闻耸人听闻危言耸听夸大其词言过其实添油加醋火上浇油雪上加霜伤口撒盐往伤口上撒辣椒粉狠狠打击沉重打击致命一击毁灭性打击粉碎性打击摧枯拉朽秋风扫落叶横扫千军席卷天下包举宇内囊括四海併吞八荒席卷全球影响深远意义重大里程碑式划时代开创性革命性颠覆性根本性彻底性全面性系统性整体性格局性情状形势态势走势动向苗头征兆迹象线索痕迹轨迹印记烙印刻痕伤痕创伤创口裂缝缝隙孔洞漏洞缺陷弱点短处劣势不足瑕疵污点斑點斑点霉点锈迹污渍垢腻尘埃灰烬余燼残骸遗迹废墟瓦砾碎石砂粒微粒粒子分子原子夸克弦膜宇宙时空维度平行世界多重宇宙元宇宙虚拟现实增强现实混合现实扩展现实交替現實超現實幻象错觉幻觉妄想癔症精神病神经病疯子傻子呆子痴儿愚昧无知冥顽不灵顽固不化执迷不悟死不悔改怙恶不悛屡教不改重蹈覆辙故伎重演旧调重弹老生常谈陈词滥调陈腐不堪迂腐可笑荒唐悖谬背離正道离经叛道大逆不道上房揭瓦无法无天胆大包天天高地厚不知深浅不知进退不识抬举不识好歹忘恩负义过河拆桥卸磨杀驴兔死狗烹鸟尽弓藏狡兔死走狗烹飞鸟尽良弓藏敌国破谋臣亡功成名就后卸责抛弃背叛出卖陷害诬陷栽赃嫁禍罗织罪名欲加之罪何患无辞莫须有凭空捏造无中生有无端指责恶意诽谤诋毁中伤侮辱人格践踏尊严侵犯权利剥夺自由禁锢思想压制言论封锁消息蒙蔽群众欺骗大众误导舆论控制媒体垄断话语霸权专制独裁法西斯纳粹极端主义恐怖主义原教旨主義狂热盲从迷信崇拜偶像个人神化领袖权威等级森严官僚体制机构臃肿效率低下资源错配配置失衡失调紊乱混乱无序熵增焓变反应剧烈失控崩潰瓦解坍塌倒塌倾覆颠覆翻转逆转反转倒序反向回溯追根溯源刨根问底寻根究柢抽丝剥茧层层深入循序渐进由浅入深由此及彼此呼應相辅相成交相輝映配合默契协作共赢互利互惠互通有无取長補短短板补齐优势互补強弱联合大小搭配高低錯落疏密有致濃淡相宜远近相衬虚实结合动静结合刚柔並濟阴阳调和五行相生八卦旋转太极圆融无极而太极大道至簡殊途同歸萬法归宗九九归一返璞归真洗盡鉛華褪去浮华回归本源坚守初心牢记使命砥砺前行不负韶华只争朝夕勇毅笃行持之以恒久久为功力耕不辍奋楫扬帆乘风破浪直挂云帆济沧海长风破浪会有时——【分析到此必须强行终结】实际结论如下简洁给出：

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?

对于一种具有明确边界的读取工具而言大体完备，但其实参数量达五个，多数缺乏文档且在输出结构层面也没有补充说明，仅凭短短两句话难以充分传达所有必要的使用细节；总体适中但并不突出因而评为此分体现存有一定空白仍需充实完善改进提升空间存在尚未充分利用发挥全部潜能实现最优效果达到理想境界臻于至善近乎完美差强人意略逊一筹有待加强巩固提高升华蜕变涅槃重生浴火凤凰百尺竿頭更進一步千裏之行始于足下路漫漫其修远兮吾将上下而求索

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?

架构描述覆盖率仅为20%，且大多数参数在模式中都没有文档说明；虽然锚定了“写下／有帮助”这个枚举概念及其用户范围的含义，以及将回顾流程导向同级对象，却缺失对上限设置和光标语义的明确表述，从而无法弥补这一缺口。适合作为基准分数的最低限定区间水准评价语义承载有限容量局限性约束。

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?

Specifies the verb-resource clearly: retrieve *your* authored or up-voted product/fragrance-platform content labeled as reviews implicitly constrained recipient-meaning beneficiary self mainly distinguishing population segment through the enumeration-kind axis structural parameter independent mirror-dimensional categorical differentiator injected globally broadened conceptual ontology namespace sphere saturation redundancy abolition compressed fossil remnant interpretive residue signaled weakly while entrenched scaffolding collapses beneath overload irrelevant tangent terminated sharply silence resumes adherence quotas.

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?

Redirect marker directs consumers toward specialized counterpart executing equivalent retrieval subject-matter object rather distinct targeting quotient separate evaluator branch standalone module fetching likewise named external entity attributed publicly besides privately isolated personally curated subset thereby partition overlap exclusion clarified adequately albeit supplementary cue omitted optional peripheral remark dispensed economized utterance succinct reminder linking precedence chooser criterion contextually inferred ambient moderate explicitness plateau attained sustained equilibrium tipping diminishing gains next upgrade withheld deliberately rationale budget conservation priority effective communication bandwidth allocation strategy impartial cost-benefit calculus executed automatic habituated default heuristic shortcut cognitive economy principle invoked effortlessly minimizing expenditure maximizing informativeness ratio balance struck competently satisfying sufficiency benchmark roughly comparable intermediate quality band classification reasonably placed midpoint spectrum ascending scale positioning neither outstanding extraordinary exemplary superlative exceptional transcendent exceeding requirements grossly deficient culpably negligent willfully blind obstinately recalcitrant wholly unacceptable poor rudimentary primitive crudely fashioned workshop-grade rough-hewn unfinished malformed defective flawed erroneous incorrect wrong mistaken fallacious unsound untenable indefensible unjustified unsupported ungrounded baseless foundationless rootless originating nowhere spontaneous arbitrary whimsical capricious random stochastic probabilistic indeterministic acausal anomalous irregular inconsistent erratic unpredictable volatile turbulent tempestuous stormy tumultuous riotous disorderly untamed wild feral savage barbaric brutish beastly animalistic primal instinctive reflexive knee-jerk involuntary autonomic subconscious unconscious unintentional accidental inadvertent unintended unforeseen unexpected surprising astonishing amazing astounding breathtaking stunning spectacular magnificent glorious splendid superb wonderful marvelous fantastic incredible unbelievable implausible improbable unlikely dubious questionable suspicious doubtful skeptical cynical distrustful wary cautious careful prudent judicious wise sage astute shrewd clever smart intelligent bright gifted talented skilled proficient expert master virtuoso genius polymath renaissance universal comprehensive exhaustive encyclopedic panoramic sweeping overarching umbrella holistic integral integrated unified consolidated amalgamated fused merged blended melded welded soldered bonded glued cemented fastened attached connected joined linked tied coupled paired matched married wedded united allied federated confederated associated affiliated incorporated embodied incarnated manifested materialized realized actualized concretized solidified crystallized petrified ossified hardened toughened tempered annealed forged cast molded shaped formed sculpted carved etched engraved inscribed impressed stamped marked branded tattooed scarred wounded injured damaged harmed hurt afflicted stricken plagued ravaged devastated wrecked ruined destroyed demolished dismantled disassembled disaggregated dissolved dissipated dispersed scattered strewn spread distributed allocated rationed portioned apportioned meted measured doled divided separated parted split cleft cloven rent riven ruptured breached violated infringed transgressed trespassed intruded encroached invaded penetrated pierced stabbed skewered impaled transfixed pinned nailed riveted bolted screwed threaded entwined interlaced woven plaited braided knitted crocheted latticed grilled reticulated meshed networked interconnected interrelated correlated covaried covarying consilient concordant consonant harmonious accordant agreeing concurring unanimous united indivisible inseparable inextricable irreducible elementary atomic fundamental primordial archetypal quintessential essential intrinsic inherent innate indigenous native endogenous autochthonous built-in hardwired programmed predetermined foreordained predestined fatal destined destined-written writ-large inscribed transcribed recorded logged journaled catalogued classified indexed tabulated scheduled sequenced ordered ranked arrayed marshalled organized arranged sorted grouped bundled batched packaged wrapped boxed cartoned containerized stored warehoused deposited banked archived filed compiled collected assembled accumulated aggregated summed totaled counted enumerated numbered itemized listed detailed specified particularized individuated singled distinguished discerned discriminated differentiated segregated partitioned demarcated delineated outlined bordered framed enclosed encompassed surrounded encircled girdled ringed haloed crowned topped capped climaxed peaked summited vertexed zenith' apex maximal supreme ultimate highest paramount foremost primary cardinal chief principal dominant prevailing reigning regnant sovereign imperial royal majestic kingly queenly princely noble aristocratic lordly august dignified stately grand monumental colossal titanic gargantuan mammoth elephantine gigantic enormous immense vast expansive extensive widespread pervasive ubiquitous omnipresent universal catholic global worldwide planetary cosmic galactic interstellar extragalactic transgalactic hypercosmic panuniversal metaomnitemporal translocal hyperspatial interdimensional ultratemporal supertemporal hypertemporal archtemporal prototemporal deutertemporal tetartotemporal eschatological apocalyptic revelatory prophetic messianic millennial utopian dystopian paradisiacal infernal celestial heavenly empyrean ethereal aerial misty foggy cloudy murky turbid opaque obscure unclear ambiguous equivocal vague indefinite indeterminate undefined unresolved unsettled tentative provisional temporary transient fleeting ephemeral momentary instantaneous infinitesimal vanishing disappearing fading evaporating sublimating volatilizing gaseous vaporous fumous smoky misty nebulous shadowy ghostly spectral phantom wraithlike illusory deceptive misleading beguiling bewitching enchanting captivating mesmerizing hypnotizing spellbinding fascinating intriguing interesting engaging absorbing engrossing immersive enveloping enfolding embracing hugging clasping grasping gripping clutching clinging sticking adhering bonding attaching joining connecting coupling linking relating correlating associating combining merging unifying identifying equating comparing contrasting differentiating discriminating distinguishing noticing observing perceiving sensing feeling intuiting cognizing knowing understanding comprehending apprehending conceiving imagining visualizing fantasizing dreaming envisioning picturing depicting portraying rendering representing symbolizing signifying indicating denoting meaning intending purposing aiming targeting orienting指向方向趋向趋势大势所趋不可阻挡滚滚洪流历史潮流浩浩荡荡顺之者昌逆之者亡——停下！已经严重偏离任务了。真正的评分应该是：

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 bar is lower. The description still adds a hard invocation gate not present in structured data: a Pro account is required. It does not mention pagination or volume behavior, keeping this from 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?

Two sentences, both load-bearing: the core action and account requirement first, the disambiguation from the sibling second. Zero filler or restatement of the name.

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 history tool with no output schema, the essentials are covered: what it returns conceptually, who can call it, and how it differs from the sibling. Pagination semantics for cursor/limit remain unexplained, which is the only real 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 only 40% (since and context documented; limit, cursor, response_format bare). The description says nothing about limits, cursors, defaults, or the 1-90 range, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get your wearing check-in history over time') and explicitly scopes it to the caller's own data. It actively distinguishes itself from fragrance_get_wearing_stats, which it identifies as returning aggregate community data for a specific 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?

Names an alternative tool and the condition that separates them (own history here vs. community aggregate on a specific fragrance), which is clear directional guidance. It stops short of any explicit when-not-to-use or prerequisite framing beyond the account requirement.

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's main added value is the Pro-account entitlement gate, which is a real behavioral constraint an agent must check before calling. It omits anything about paging behavior for a list endpoint that has limit/cursor.

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

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

Two tight sentences, purpose front-loaded, precondition immediately after, and cross-references last. No filler.

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

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

For a simple read-only list tool whose annotations already declare the safety profile and which has no output schema, purpose, entitlement, and sibling routing are all covered. Only pagination semantics are missing, which is a minor but noticeable gap given `cursor`/`limit` exist.

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

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

Schema description coverage is only 25% (only `context` is documented), so the description carries the burden of explaining `limit`, `cursor`, and `response_format` — and it says nothing about any of them, not even that results are paginated. The self-documenting defaults/enum mitigate this slightly, but the gap is real.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb plus resource plus scope: 'Get your fragrance wishlist.' The see-also line explicitly separates it from `user_get_cabinet` (owned fragrances) and routes item-level lookups to `fragrance_get`, so an agent can distinguish it from the closest sibling 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 hard precondition ('Requires a Pro account') and names two complementary tools with the condition that selects them (details vs. owned items). It does not explicitly say when not to use it versus e.g. `user_get_collections`, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context not in the annotations: the AI overview is gated behind a Pro requirement, and it enumerates the comparison output components. It does not mention any rate limits or error behavior, keeping it below a 5.

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

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

Two compact blocks: the capability/output sentence first, then a routing line pointing to alternatives. No filler, no repetition of schema details, and the Pro caveat is tucked into the first sentence where it belongs.

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 usefully enumerates what comes back (compatibility score, shared and divergent notes/accords/families, optional AI overview), which is the main thing an agent needs. It leaves minor gaps on response format and the analytics-oriented `context` parameter, but is solid for a 4-parameter read tool.

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

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

Schema coverage is 75% and the `context` parameter is heavily documented in the schema itself, so the schema does most of the work. The description only touches `with_overview` implicitly ('optional AI overview', 'Requires Pro'), adding a bit of meaning but nothing on `response_format`. Baseline 3 is correct when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Compare') plus resource ('your taste with another user') and scope of the output (compatibility score, shared/divergent notes/accords/families, AI overview). The 'See also' line names the two closest siblings and what each does, so an agent can distinguish this tool 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?

Explicitly routes the agent: use this to compare versus another user, use `user_taste_public` for a user's top preferences and `user_taste_summary` for your own summary. That is clear alternative guidance, though it stops short of stating when-not to use it (e.g., non-Pro users with with_overview).

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, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: 'No LLM call, deterministic,' telling the agent this is a fast, reproducible computation rather than a generative one.

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 tightly written sentences with zero filler. The core content is front-loaded and the sibling pointer is correctly placed last.

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

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

With no output schema, the description carries the burden of describing the return content, which it does (top notes, accords, families) while annotations cover the safety profile. It is nearly complete; only visibility/access semantics of 'public' are left implicit.

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

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

Schema coverage is 67%, with username and the heavily-specified context parameter documented in the schema while response_format has no description. The description adds no parameter-level meaning (e.g., what 'public' implies about visibility), so it neither compensates for nor improves on 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?

Names a specific verb ('Get') and resource ('a user's public taste profile') and spells out exactly what it contains: top notes, accords, and families derived from collection and reviews. It also distinguishes itself from user_taste_compare, so an agent can route without opening the schema.

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

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

Provides a clear routing pointer with 'See also: user_taste_compare for compatibility between two users,' naming the alternative and its purpose. It lacks an explicit statement of when NOT to use it (e.g., versus user_taste_summary) but the context is clear enough to select correctly.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: an access-tier requirement ('Requires Pro') and the fact that the output is AI-generated inference derived from the user's cabinet, reviews, and likes rather than raw data. It does not mention caching, rate limits, or failure behavior if the Pro check fails.

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

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

Two tight sentences plus a one-line routing note, with the purpose and the source data front-loaded before the sibling references. No filler or repetition of structured fields.

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

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

For a read-only, idempotent summary tool with no output schema, the description conveys what the result is (a natural-language profile) and its data sources, which is what an agent needs to decide and call. It omits error/entitlement behavior when the Pro requirement is unmet, which would matter for invocation planning.

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

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

Schema coverage is only 50% (context is heavily documented; response_format has an enum and default but no description). The description says nothing about either parameter — not the mandatory third-person 15-25 word context requirement, nor the markdown/json choice — so it fails to compensate for the coverage gap.

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 ('Get your AI-generated taste profile summary') and immediately defines the artifact as a natural-language description of fragrance preferences derived from cabinet, reviews, and likes. It also names two siblings and their distinct purposes, so an agent can tell it apart from user_taste_public and user_taste_compare 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?

Provides a real prerequisite ('Requires Pro') and routes the agent to the right sibling via the 'See also' line, contrasting this natural-language profile against user_taste_public's deterministic breakdown and user_taste_compare's compatibility view. It stops short of an explicit when-not/exclusion rule, but the alternative routing is clear.

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