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

No annotations are present, so the description carries the full burden. It discloses important non-obvious behaviors: same-category existing parts are replaced (destructive) and compatibility is automatically checked when 2 or more parts are involved. It doesn't mention return values or error behavior, but the key side effects are clearly surfaced.

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 main action, then the replacement rule, then the compatibility behavior. Every sentence earns its place with no filler or repetition.

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

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

For a single-part mutation tool with fully documented parameters, the description covers the operation and its key side effects. It omits return-value details and build-existence assumptions, but given no output schema and available sibling tools like build_status, it is sufficiently complete for correct invocation.

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%, with detailed descriptions for productId, category, name, and price. The description adds no parameter-specific syntax or format details beyond the schema, so the baseline of 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?

The description states a specific verb and resource: 'Adds Danawa parts to the build' (빌드에 다나와 부품을 추가합니다). It also distinguishes from siblings by specifying that same-category parts are replaced and compatibility is checked, which separates it from read/search tools and build_remove.

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?

Usage is implied: an agent should call this when adding a part to a build. The note about automatic compatibility checking for 2+ parts hints at when build_check_compatibility may be redundant, but there is no explicit when-not-to-use or reference to alternatives such as build_remove or build_check_compatibility.

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?

No annotations are provided, so the description carries the behavioral burden. It does disclose an external API dependency (Danawa API) and implies a read-only validation, but it does not explicitly state that the tool has no side effects or what happens if the build has no parts.

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 concise, front-loaded sentences carry clear purpose and relevant examples without filler or redundant restatement. Every sentence 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?

There is no output schema, and the description does not specify the return format or how compatibility results are presented (e.g., list of issues, boolean, warnings). It also does not mention prerequisites such as a non-empty build. For a zero-parameter tool this is a minor but 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?

The input schema is empty with zero parameters, so the baseline of 4 applies. There are no parameter semantics for the description to add, and it correctly avoids introducing nonexistent 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?

The description uses a specific verb and resource: it checks compatibility between parts added to the current build via the Danawa API. It also lists concrete compatibility dimensions (CPU-motherboard socket, CPU-RAM spec, RAM-motherboard slot), which clearly distinguishes it from sibling search and build-management 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 description clearly scopes usage to the current build's added parts, so an agent can infer when this tool is appropriate. It does not explicitly name alternatives or exclusion conditions, so it stops short of full 5-level 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says parts are removed from the build, without stating whether the removal is permanent, whether it removes all parts in the category or a specific one, or what the effect on the build is.

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 short sentence with no filler, and the action/resource are front-loaded. It is efficiently written, though it omits contextual details that would make it more useful.

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

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

The tool is simple, with one fully documented enum parameter and no output schema, so a long description is not required. However, because there are no annotations and the description is ambiguous about the scope of removal, it is only minimally complete for an agent calling the 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?

The schema covers 100% of the parameter: category is required, enum-valued, and described. The description adds no meaning beyond the schema's own description, so the baseline score of 3 is appropriate.

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

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

The description states the action ('removes') and the object ('parts in a category from the build'), which clearly distinguishes it from siblings such as build_add and build_status. An agent can understand the tool's role 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 description implies use when the user wants to remove a category part from a build, but it gives no explicit when-to-use guidance or mention of alternatives. It does not clarify when this tool should be preferred over build_add or other build-related 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb '조회합니다' (queries) clearly communicates a read-only, non-mutating operation, and the description goes beyond a bare statement by listing what the query returns (added parts list, total price). It does not expand on edge cases such as an empty build, but for a zero-parameter read tool this is adequate transparency.

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, compact sentence in Korean that front-loads the key action ('현재 빌드 상태를 조회합니다') and parenthetically includes the important output details. There is no redundant information or filler, making it highly concise and easy to parse.

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

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

Given the tool's low complexity—zero parameters, no output schema, and a simple read-only purpose—the description is complete enough for an agent to invoke it correctly. It states what the tool does and what information it returns, which is all an agent needs to know to make a successful call.

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

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

The input schema has zero properties, so there are no parameter semantics to document. Per the baseline for 0 parameters, the description does not need to explain parameters. The description instead focuses on the output content, which is appropriate since schema coverage is vacuously 100%.

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

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

The description uses a specific verb '조회합니다' (queries) with a specific resource '현재 빌드 상태' (current build status), and explicitly names what the status contains: '추가된 부품 목록, 합계 가격' (list of added parts, total price). This clearly distinguishes it from sibling tools like build_add, build_remove, and build_check_compatibility, which all involve mutation or validation rather than simple status lookup.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. However, the purpose is clearly a read-only query of the build state, so an agent can infer it should be used when needing to see added parts or total price. Sibling names like build_add and build_remove further imply this is the status-check tool, but the guidance remains implicit rather than stated.

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

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

There are no annotations and no output schema, so the description carries the full burden of explaining behavior. It only says 'compares', without stating what the returned data looks like, whether it fetches live prices, or how it handles cases where the same product is not available on both sites.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and readable, but it is so brief that it omits useful usage and output context.

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 that there is no output schema and no annotations, the description is not complete enough for an agent to confidently call the tool. It lacks return-value expectations, failure behavior, and explicit guidance about when to choose this tool over related 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 coverage is 100%, so the schema already documents query and category. The description adds meaningful nuance by emphasizing 'same product', which tells the agent the query should be a specific product identifier rather than a broad search term.

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

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

The description uses a specific verb ('compares') and a precise resource ('prices between Danawa and Computzone for the same product'). It distinguishes the tool from siblings like get_price_history and find_lowest_price by explicitly scoping it to a two-retailer comparison.

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

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

No guidance is provided for when to use this tool versus alternatives such as find_lowest_price or get_price_history. The description says what the tool does but not which situations call for it or when a sibling would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait beyond the name: the result is an integrated ('통합') lowest price aggregated across Danawa and Compuzone, and the operation is implicitly a safe lookup. However, it does not cover staleness/caching, failure or empty-result behavior, or response shape, leaving notable gaps for a tool with zero annotation 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?

A single Korean sentence that conveys the object, scope, and outcome without wasted words. The part scope is front-loaded and every element 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 and no annotations, the description should carry more context, but it omits the return value shape (does the result include a price figure, product ID, link, or source?), how category affects results, and edge-case behavior. For an agent that may need to chain into get_product_detail or get_price_history, knowing what identifier the result carries matters, and that is absent.

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

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

Schema description coverage is 100%, so the schema already documents both query and category, which sets the baseline at 3. The description adds no parameter-level meaning beyond that — it does not explain how to phrase the query or that category narrows/disambiguates the search, so it neither gains nor loses relative to baseline.

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

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

The description states a specific verb ('찾습니다' — finds) and a precise resource: the integrated lowest price across Danawa and Compuzone for a specific part. This is clear and hints at differentiation from siblings by naming the two sources and the '통합 최저가' outcome, but it never explicitly names a sibling it is not (e.g., compare_prices), so it falls 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 guidance about when to use this tool versus overlapping siblings such as compare_prices, search_parts, or get_price_history, nor any exclusion conditions. '특정 부품' (specific part) implies a query scenario, but that is a property of the input, not actionable routing 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?

With no annotations available, the description carries the behavioral burden. It conveys a read-only lookup ('조회') of a specific product's price history from Danawa, which adds useful context, but it does not disclose return format, data freshness, pagination, or external-site dependence.

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 short Korean sentence that is front-loaded and free of filler. Each element — source, scope, and operation — 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?

Given there are no annotations and no output schema, the description is too thin to be contextually complete. It does not explain what the returned history contains, how period affects results, or when to select this tool over price-related 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 the schema already documents productCode and period. The description adds no new parameter-level semantics beyond matching 'specific product' to productCode, so the baseline of 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?

The description states a specific action ('조회합니다' / retrieves) and a clear resource ('price fluctuation history for a specific product on Danawa'). It differentiates from siblings like compare_prices and find_lowest_price by focusing on historical changes, though it does not explicitly name an alternative.

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

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

No guidance is provided about when to use this tool versus related siblings such as get_product_detail, compare_prices, or find_lowest_price. The description only states the operation; it does not give selection criteria 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?

With no annotations, the description must carry behavioral disclosure. It does convey that this is a read-only 'query' operation and indicates the returned content (specs, seller-specific prices), but it does not mention error behavior, missing products, or external source implications. This is minimum viable transparency.

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 Korean sentence that front-loads the operation and parenthetically scopes the returned information. No filler, no repetition of parameter or schema details.

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 two-parameter read tool, the description is mostly adequate: it names the product identifier and source, and indicates the result content. However, with no output schema and several price-focused siblings, it fails to clarify what the price data represents or how this tool differs from price-history/comparison tools.

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 adds little beyond the schema: it loosely connects 'seller-specific prices' to the source parameter, but doesn't explain how productCode and source shape the response beyond what the schema already states.

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

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

The description uses a specific verb ('조회합니다' - retrieves) with a clear resource: detailed information about a specific product, including specs and seller-specific prices. This distinguishes it from sibling tools like search_parts and get_price_history, which serve different purposes.

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 vs alternatives. The description does not mention when not to use it or point to siblings like compare_prices, find_lowest_price, or get_price_history, leaving the agent to infer 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?

There are no annotations, so the description bears the behavioral disclosure burden. It does disclose that this is a read-only listing ('조회합니다') scoped to a category with popular/price ordering. However, it does not clarify output shape, default sorting behavior, or pagination, leaving those to schema defaults.

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 in Korean, front-loaded with the action and scope, no redundant phrases or filler. It 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?

The tool is simple and the schema covers parameters, but with no output schema and no annotations, the description leaves out any statement about when to choose list_by_category over search_parts/find_lowest_price, and does not hint at result granularity beyond 'list'. Adequate for basic invocation, but 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 100%, and each parameter already has a description plus defaults/enums; the baseline is 3. The description adds no independent parameter semantics beyond noting 'popular/lowest-price', which mirrors sortBy values, so no additional value.

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?

Description uses a specific verb ('조회합니다' = retrieves) and names a precise resource: a PC-part list grouped by category with popular/lowest-price ordering. This semantic scope ('카테고리별', '인기/최저가') clearly separates it from siblings like get_product_detail (single item) and search_parts (keyword-based search).

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

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

The category and sorting context ('by category', 'popular/lowest-price') implies this tool is for browsing parts by category, but it gives no explicit when-to-use instruction and never names alternatives or exclusions relative to search_parts/find_lowest_price. This is implied usage, not explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that this is a read-only status check by using '확인' and lists the exact dimensions of information returned. It does not mention whether a live connection test is performed or whether the status is cached, but for a no-parameter status tool the description is reasonably transparent.

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, focused sentence that leads with the action and object, then adds the three key aspects shown. Every word contributes meaning, with no filler or repetition.

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

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

For a no-input status tool without an output schema, the description is complete: it states what the tool checks and enumerates the specific information the agent can expect. There are no parameters, annotations, or nested structures that create additional context requirements.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. There are no parameter semantics to explain, and the description correctly focuses on the tool's informational output rather than any input details.

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

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

The description uses a specific verb ('확인합니다' / checks) and a clear resource ('현재 프록시/차단 상태'), then enumerates what is covered: Zyte API key configuration, per-site block status, and automatic proxy switching. This fully distinguishes the tool from the sibling product-search and build tools, which address completely different concerns.

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

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

The description implies that the tool is for checking the current proxy/block status, but it does not explicitly state when to prefer it over alternatives or provide any exclusions. Since the sibling tools are unrelated to proxy/block status, no direct alternative is named, but the guidance remains implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool searches, without describing result format, pagination, source-specific behavior, rate limits, or whether the search is read-only. The source options are the only extra behavioral nuance.

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 short and front-loaded, conveying the core action and the two selectable sources in one efficient sentence. It is concise, though it sacrifices some useful context that could have been added without much length.

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

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

The tool has four parameters, two enums, and no output schema, but the description provides only the bare search behavior. It omits return value shape, how source selection affects results, and any search-specific edge cases, making it insufficient for an agent to fully anticipate the tool's behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description aligns with the query and source parameters by mentioning keyword and source options, but it does not add meaningful detail about limit or category beyond what the schema already documents.

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

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

The description clearly states the verb and resource: search PC parts by keyword, with the ability to search Danawa, Compuzone, or both. It is understandable and distinct from list-based browsing, though it does not explicitly name or differentiate itself from sibling 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 description gives no guidance about when to choose this tool over alternatives like list_by_category, get_product_detail, or find_lowest_price. It mentions the searchable sources but does not explain use cases, exclusions, or prerequisites.

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