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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the comparison dimensions (objective attributes, sales summary, experiential topics), which is useful context beyond annotations. However, it does not disclose any additional behavioral traits such as auth requirements, rate limits, or data freshness.

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

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

The description is a single front-loaded sentence with no redundant or filler text. It efficiently communicates the core action, scope, and comparison dimensions.

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

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

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. However, with 0% parameter description coverage and no usage guidance, the description leaves significant gaps for an agent to correctly invoke the tool, especially regarding the nested experience_topics parameter and attribute_keys format.

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

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

Schema description coverage is 0%, so the input schema provides no semantic descriptions for any of the three parameters. The description mentions '2~5개 상품' (mapping to product_ids min/max) and the three comparison aspects (loosely mapping to attribute_keys and experience_topics), but it does not explain what attribute_keys expects, what the nested ExperienceTopic fields mean, or how sales summary is controlled. This is insufficient to compensate for the complete lack of schema documentation.

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), resource '상품' (products), and scope '같은 카테고리의 2~5개' (same category, 2-5). It also names three comparison dimensions: objective attributes, sales summary, and experiential topics. This differentiates it from search_products and get_product_details implicitly, though no sibling is named explicitly.

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

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

There is no explicit guidance on when to use this tool versus alternatives like get_product_details or search_products, nor any prerequisites, exclusions, or when-not conditions. The constraints (same category, 2-5 products) give minimal context but do not rise to clear usage 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=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds almost nothing beyond that: it does not explain pagination behavior despite limit/offset, nor what the referenced selectors mean. The mention of selector output fields is the only behavioral hint, and it is unexplained.

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 that are front-loaded and waste no words structurally. But the second sentence is jargon-laden and references undefined fields, so brevity comes at the cost of actual information.

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

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

An output schema exists, so return values need not be explained. Still, for a search tool with four fully undocumented parameters and mandatory result pagination, the description leaves too much unspecified, and its dangling selector terminology creates confusion rather than completeness.

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

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

Schema description coverage is 0%: limit, query, offset, and category carry only titles and constraints, with no meaning documented anywhere. The description only implies text search (suggesting 'query') and says nothing about limit, offset, or the category filter, and its selector references do not map to any parameter. 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?

The first sentence gives a specific verb and resource ('text-searches review attribute expressions'), which is reasonably distinguishable from siblings like list_review_states and get_review_evidence. However, the second sentence introduces 'matched_selector' and 'cluster_selector', terms that appear nowhere in the input schema, muddying rather than sharpening what the tool actually does. Core purpose is legible but the scope statement is opaque.

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?

'Look at matched_selector and cluster_selector and choose the scope yourself' gestures at a decision but names no alternative tool and gives no condition for when to use this versus get_review_evidence or list_review_states. The instruction is cryptic and does not tell an agent when this tool is the right choice.

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 this a safe read (readOnlyHint=true, destructiveHint=false), lowering the bar. The description does add a genuinely useful, non-obvious trait: the offer data is a snapshot as of the check time. However it says nothing about rate limits, batch size limits, or behavior on invalid product IDs, so it is context, 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 short sentences, front-loaded with the return payload and followed by the one caveat that matters (snapshot semantics). Nothing is wasted or buried.

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

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

An output schema exists, so return-value structure need not be restated, and annotations cover the safety profile. The remaining gap is parameter behavior — especially that availability filters results — plus batching or error semantics, none of which the description supplies.

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

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

Schema description coverage is 0%, so the description carries the full burden for two parameters and fails to address either. Critically, the availability filter (a supported-value enum subset) is never mentioned, and product_ids semantics (list input, batching, limits) are left entirely unexplained.

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 (반환한다/returns) and a specific resource scope (판매처별 offers with price, shipping, stock, check time), which lets an agent distinguish it from search_products or compare_products. It never explicitly names or excludes a sibling, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as compare_products for comparison workflows. Usage can only be inferred from the returned field list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a useful inventory of what is returned, but says nothing about the effect or role of experience_topics, pagination, or why certain data may be absent.

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

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

A single front-loaded sentence that enumerates the return contents with no filler. Efficient, though its brevity is achieved partly by omitting information the complex parameter schema needs.

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

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

An output schema exists, so explaining return values is not strictly required. However, for a tool with an undocumented nested parameter and 0% schema coverage, the description leaves the agent without the semantics needed to construct experience_topics correctly.

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

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

Schema description coverage is 0%, and the schema defines a non-trivial nested experience_topics object (topic_id, aspect_variant_ids, desired/contrary state variants) that the description never mentions. Only product_id is implicitly inferable from context, so the description 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?

The description states a specific verb (반환한다 / returns) and resource (상품 / product) and enumerates the returned content: objective attributes, detail Markdown, sellers, and key review attributes. This clearly separates it from search-oriented siblings like search_products, though it never explicitly names the distinction.

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

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

No when-to-use guidance or prerequisites are given. It does not say when to reach for this instead of siblings such as search_products, get_offers, or find_review_attributes, which heavily overlap the seller and review content mentioned here.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavior beyond them: an implicit cap of 10 results when no id is supplied, and the fact that warnings and failure causes are surfaced rather than just a status code. Auth and pagination behavior remain unstated.

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

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

A single dense sentence that front-loads the scope (one job vs. recent 10) and then the returned content, with no filler or redundancy. Every clause carries information an agent needs.

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

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

Given an output schema exists, return values need not be detailed, and the annotations cover the safety profile. For a one-optional-param read tool the description is essentially complete, though it omits how job_id is produced and any polling guidance that would make the workflow self-contained.

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

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

Schema description coverage is 0% for the single job_id property, so the description must carry the load, and it does: job_id selects one job and its absence switches to the 10-recent-jobs mode. It does not state the id's format or where an agent obtains it (presumably from register_product), which keeps it from a 5.

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

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

States a specific verb and resource ('조회한다' + '등록 작업') plus the return content (단계·경고·실패 원인) and the two operating modes (single job vs. recent 10). An agent can distinguish it from the sibling register_product, which performs the registration rather than reporting on one. It stops short of naming a sibling explicitly, which is what a 5 would require.

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 conditional '하나 또는 최근 10개' conveys clear usage context: pass job_id for a specific job, omit it for a recent-jobs overview. There is no explicit statement of when this tool should be reached for (e.g., polling after register_product) and no exclusion/alternative routing, 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral fact — that a single review can carry multiple labels — but says nothing about pagination, result volume, or how the many filters interact. With annotations carrying the read safety profile, a 3 is appropriate.

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

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

Two short sentences, front-loaded with the scope before the multi-label caveat, with no filler. It is efficient, though the brevity is partly under-specification rather than true density.

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

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

An output schema exists, so return values need not be described. But for a 9-parameter, filter-heavy retrieval tool with 0% schema coverage and no usage guidance, the description leaves the agent without enough to select filters or understand the paging model.

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

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

Schema description coverage is 0% across 9 parameters. The description's enumeration of label groups loosely maps to the group enum, but it never explains aspect_variant_ids (the required param), include_full_review, desired_state_variant_ids, contrary_state_variant_ids, or the paging/filter params. The description fails to compensate for the near-total schema 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?

The description names the resource (리뷰의 원문 근거 = review source-text evidence) and enumerates the label categories it covers (matching/contrary/other/state-unstated), which maps cleanly to the group enum. However, the verb 확인한다 ('check/verify') is vague — it does not make clear that this retrieves evidence text rather than validating it, and nothing distinguishes it from siblings like find_review_attributes or list_review_states.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The reader is told what the tool covers but not under which circumstances to call it versus the many sibling review/attribute 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the content scope (what the guide contains) but no further behavioral details such as size, caching, or whether the guide changes over time.

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

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

One compact sentence front-loads the returned content with no filler. It is appropriately sized for a simple reference tool, though the middle-dot list is slightly dense.

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

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

An output schema exists, so return values need not be explained. Still, for an agent to call this correctly, the description should indicate when to use it relative to the many search-related siblings and what the category parameter does; both are missing.

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

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

Schema description coverage is 0% for the single optional category parameter. The description mentions '카테고리' only as one of the guide's content areas, not as an input that filters the response, so it fails to compensate for the undocumented parameter.

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

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

The description names the specific content the guide returns—categories, dynamic filter keys/operators, observed values, and answer policy—which distinguishes it from the search/compare siblings that operate on products. However, it does not explicitly contrast with documentation-oriented siblings like get_product_docs or search_product_docs, so sibling differentiation is implied rather than stated.

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

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

No when-to-use guidance or alternatives are provided. It never states that this should be called before search_products to learn filter syntax, nor does it mention any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context of its own — nothing about pagination semantics, result limits, or interaction with the limit/offset parameters. Its content restates return values, which the output schema already carries, so it contributes little beyond the annotations.

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

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

It is a single compact sentence with no wasted phrasing, which is good structure. But the brevity is under-specification rather than discipline — nothing is front-loaded because nothing beyond the bare purpose is provided.

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

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

For a five-parameter, zero-schema-coverage tool, the description is far too thin: it omits parameter meanings, filtering behavior, and any usage routing. The existence of an output schema excuses it from explaining return values, yet it spends its only sentence on return contents anyway, leaving the caller-facing gaps unfilled.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the burden and it does not. It only loosely implies that aspect_variant_ids selects the 'original aspect expressions' being queried, leaving query, product_ids, limit, and offset entirely unexplained in both schema and description.

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

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

The description names a clear verb (조회한다/retrieve) and resource (the state of selected original aspect expressions), and it enumerates the returned contents: status ID, review count, sentiment distribution, and examples. That is specific enough for an agent to know what the tool returns. It does not, however, distinguish this from siblings like find_review_attributes or get_review_evidence, which all operate in the same review-aspect space.

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

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

There is no when-to-use guidance, no stated alternatives, and no exclusions or prerequisites. The reader cannot tell from the text whether this is the right tool versus find_review_attributes or get_review_evidence. Only the required aspect_variant_ids hints at any precondition.

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 this is a non-read-only, open-world, non-destructive operation, but the description adds genuinely new behavior: the call is fire-and-forget (don't await the result), the conversation should end, and a macOS notification fires on completion. That async, side-effecting behavior is exactly what an agent needs and is not derivable from the annotations.

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

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

Three short sentences with the critical invocation constraint front-loaded. Every sentence carries information; only the notification detail borders on trivia, but it supports the fire-and-forget behavior.

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

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

An output schema exists so return values need no explanation, and the async behavior is covered. However, for a 2-param write tool it says nothing about parameter meaning and never points to get_registration_status for tracking the async result, leaving a 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 0% and the description mentions neither 'url' nor 'category_hint'. With two parameters (one required, one optional with a default) completely undocumented, the description fails to compensate for the schema 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?

The description states the verb '등록' (register) and ties it to a product link, but it largely restates the tool name and never explains what registration actually does (persist a product into tracking, etc.). It offers no differentiation from siblings like get_registration_status or get_product_details, so an agent must infer the boundary.

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

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

Explicit invocation condition: call only when the user explicitly requests registration with a product link, and after calling do not wait for the result but end the conversation. This is strong when-to-use guidance, though it names no alternatives (e.g., the status-check sibling) for follow-up.

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 openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the matching semantics (keywords split on whitespace/commas, line-level match, nearest preceding heading returned), which is non-obvious behavior. It does not cover rate limits, pagination, or what happens with multiple 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?

A single front-loaded sentence with no filler. It is efficient, though the terse phrasing packs matching mechanics and return behavior into one clause without structure, and the essential usage routing is absent entirely.

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

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

An output schema exists, so return formatting need not be described, and annotations cover safety. But with four parameters at 0% schema coverage and no usage guidance, the definition is incomplete: the agent cannot tell how category or product_ids scope the search or when to prefer this over search_products.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden. It partially compensates by explaining that query is split on spaces/commas into keywords, but category, max_results (default 15, max 50) and product_ids receive no explanation at all, leaving three of four parameters semantically opaque.

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 concrete retrieval behavior: it finds lines in the detailed document containing keywords split on spaces/commas and returns the nearest preceding heading. That is a specific verb+resource, but it never distinguishes this from siblings like search_products or get_search_guide, leaving the 'docs vs products vs guide' boundary implicit.

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

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

There is no when-to-use guidance, no mention of the sibling get_search_guide (which is plausibly the entry point for this search flow), and no exclusions. The agent must infer from the name alone whether this or search_products is the right tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add a non-obvious behavioral requirement: 'applied_filters_markdown' must be shown verbatim ahead of the answer. That is real added context, but nothing is said about how filters interact or what happens when conditions conflict.

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 operational purpose is front-loaded and the display instruction follows. Every clause carries information and there is no padding, though the brevity comes at the cost of the missing detail noted elsewhere.

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

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

For a 9-parameter tool with deeply nested filter objects and no parameter descriptions, the description is far too thin; it does not explain how the filter/sort structures relate to the three stated dimensions. The existence of an output schema excuses it from describing return values, but the input side remains largely opaque.

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

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

Schema description coverage is 0% across 9 parameters, several of which are complex nested objects (SortSpec, OfferFilter, ObjectiveFilter, ExperienceTopic, ExperienceCondition). The phrase '객관·판매·리뷰' loosely hints at the three filter families but leaves sort, limit, category, user_request, and interpretation_notes completely unexplained. The description 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?

The description states a specific action (filter and sort) over a meaningful scope ('전체 조건을 받아' – accepting all conditions) broken into three dimensions: objective, sales, and review. This is more than a restatement of the name. However, it never names the sibling tools it must be distinguished from (e.g., compare_products, get_product_details), so an agent must infer the boundary itself.

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

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

There is no statement of when to use this tool versus search_product_docs, compare_products, or get_product_details, and no prerequisites or exclusions. The only directional cue is an output-formatting instruction, not selection guidance. An agent gets no routing help.

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