Folsn Own-Store Products

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered. The description adds the returned fields and notes coupon is null when absent, which is useful, but since an output schema exists this return-value detail is largely redundant.

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 content is front-loaded and each sentence is informative, but the entire text is duplicated in Korean and English, roughly doubling the length without adding information. The bilingual mirror is the main structural cost.

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 a 1-parameter schema at full coverage, complete annotations, and an output schema covering return values, the description is essentially complete; it briefly enumerates the returned fields for orientation. Only the missing failure/edge-case guidance (invalid or stale SKU) keeps it from 5.

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

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

Schema description coverage is 100% for the single parameter, and the description's SKU definition plus the {"product_id": "13300090680"} example duplicate what the schema already provides in its description and examples array. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (가져옵니다/get) and resource (one Folsn product's sale terms) keyed by SKU, and explicitly contrasts with the sibling by saying the SKU comes 'from search_folsn_products'. An agent can distinguish this single-item lookup from the search tool 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?

The description establishes the workflow context — the product_id comes from search results — which effectively routes the agent to search_folsn_products first. It does not state when not to use it or what happens if the SKU is unknown/missing, so it stops short of explicit alternatives 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely useful behavior beyond that: the ambiguity-handling contract (matchStatus=needs_clarification with clarificationFields) and the fact that prices are point-in-time snapshots with a source field. Some of the returned-field enumeration overlaps the output schema, 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?

Dense and front-loaded, with the scope statement and the negative boundary arriving before the result-field list. The Korean/English duplication doubles the length, which is justified for a bilingual audience but adds no new information per language.

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 2-parameter read-only search with an output schema and full annotation coverage, the definition is essentially complete: scope, exclusions, clarification behavior, and example invocation are all present. Re-describing return fields is mild redundancy given the output schema exists, but nothing an agent needs is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes slightly beyond it by expanding what 'options' means (volume, count, color, model number) and by giving concrete query examples. The limit parameter's semantics are left entirely to 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 (search) and resource (products Folsn sells directly on its Naver Smart Store), and explicitly carves out scope by saying it does not return other stores' prices or market-wide lowest prices. An agent can distinguish this filtered Folsn-only search from a broader offer lookup 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?

Clear about the condition that selects this tool (Folsn-direct listings only) and states what it will not return, which functions as a when-not rule. It never explicitly names the sibling get_folsn_product_offer as the tool to use for a single offer, so alternative routing is left to inference.

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