APICK Web

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the non-obvious cost signal '[호출당 20포인트]' (20 points per call), which is real behavioral context an agent needs and cannot get from structured fields. It still does not describe rate limits or error 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?

Content is front-loaded with the retrieval scope before the field list, and each element earns its place. The main inefficiency is full duplication across English and Korean, which pads length without adding 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?

With no output schema, the description's enumeration of returned fields (title, price, rating, reviews, availability, seller, features, images) usefully compensates by telling the agent what a call yields. Combined with annotations covering the open-world read profile and the stated per-call cost, it is largely complete for a simple two-parameter lookup.

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

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

Schema description coverage is 100% and the schema already states that one of url or asin is required (including the /dp/ASIN format and ASIN length). The description merely restates 'URL or ASIN' without adding syntax or precedence beyond what the schema provides, 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?

States a specific verb (조회/retrieve) and a specific resource (Amazon product), and it enumerates the exact fields returned (title, price, rating, reviews, availability, seller, features, images). The Amazon/URL-or-ASIN scoping distinguishes it from generic search siblings like google_shopping_search, though it never names an alternative 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?

The 'by URL or ASIN' phrasing implies the input condition under which the tool is used, but there is no explicit guidance on when to prefer it over google_search, google_shopping_search, or how it relates to amazon_reviews_create. Usage is implied 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context not present in structured fields: the per-call cost (30 points) and a full enumeration of returned fields in the absence of an output schema. It does not cover failure modes for bad URLs/IDs, which keeps it 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?

The field list is front-loaded and informative, but the entire description is duplicated verbatim in English and Korean, roughly doubling its length without adding information. Placement of the cost note at the end is reasonable, but the redundancy is a real efficiency 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 no output schema, the description correctly compensates by enumerating the returned fields, and it adds cost information the annotations lack. Combined with annotations covering the read-only/open-world profile, an agent has nearly everything needed; only error behavior and invalid-input handling 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 100%, so the schema already documents url and product_id, including the 'one of these is required' constraint in Korean. The description only restates the two input modes ('by URL or product id') without adding syntax, format, or precedence rules, so 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?

The description names a specific resource (Coupang product) and enumerates the exact data returned (title, prices, discount, rating, reviews, stock, seller, options, categories, images), so the agent knows exactly what it retrieves. The vendor name implicitly separates it from amazon_product and naver_shopping_product siblings, but it never explicitly contrasts them, 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 statement of when to use this tool versus amazon_product or naver_shopping_product, and no prerequisites or exclusions are given. The only usage-adjacent information ('by URL or product id') is really input format, not selection guidance, so an agent must infer the Coupang-only scope from the name.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-fetch behavior are covered. The description usefully adds the per-call cost ('[호출당 40포인트]'), which annotations cannot express, but says nothing about how many 'latest' videos are returned or any fetch/rate constraints.

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 bracketed cost marker, front-loaded with the purpose before the cost. The English and Korean sentences are semantically duplicates, which is mild redundancy but justified for a bilingual audience.

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 should say more about what comes back – profile fields, number of videos, ordering, or truncation. It covers the input and the cost adequately but leaves the return contract underspecified for an agent that must consume the result.

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 a single required user_id whose description already enumerates accepted forms (handle, channel ID, URL, e.g. CNN). The description adds no parameter meaning beyond the schema, so 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 ('look up') and resource ('YouTube channel profile and its latest uploaded videos'), and adds scope beyond a plain channel-info lookup by including recent videos. However, it never distinguishes itself from the sibling youtube_channel (or youtube_search), so an agent must guess which one to pick for basic channel data.

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, no prerequisites, and no mention of alternatives despite several obvious siblings (youtube_channel, youtube_search, youtube_metadata). The only routing-adjacent information is the cost note, which tells the agent nothing about 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral context beyond that: it discloses that pagination is supported via page and that each call costs 40 points ([호출당 40포인트]), which is a meaningful operational constraint not present in 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?

The core information is front-loaded in the first sentence, which is good. However, the Korean sentences mostly restate the English content (returned fields, pagination), creating duplication that wastes space without adding new meaning.

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 must describe return values; it does so by naming image URL, source page link, and title. It also covers pagination and cost. For a simple two-parameter read-only search tool, this is largely complete, with only edge-case behavior (e.g., invalid page handling) left 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 description coverage is 100%, so the schema already documents both keyword and page (including the 1–5 range and 20 results per page). The description's mention of pagination reinforces the page parameter's purpose but adds no syntax or format detail beyond the schema, so 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 and resource ('Google image search by keyword') and lists the returned fields (image URL, source link, title). It does not explicitly differentiate itself from other Google search siblings like google_search or google_lens_search, so it falls short of a 5, but the purpose is unambiguous.

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 on when to use this tool versus alternatives such as google_search, google_lens_search, or google_shopping_search. The pagination note describes how to use the page parameter, not when to choose this tool over siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and non-determinism. The description adds allowed formats and a cost note ('60 points per call'), but it does not disclose much beyond that; the 'upload an image' wording also conflicts slightly with the URL-based input in the schema. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core action, then adds format/cost constraints. The Korean sentence largely restates the English part with a slightly expanded output list, introducing minor redundancy, but overall it remains appropriately sized.

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 one-parameter read-only tool, the description covers the purpose, a broad output description, and constraints. However, because there is no output schema, it should do more to describe what the returned labels or pages look like, and it never clarifies that the 'upload' is actually a URL reference rather than a file upload.

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

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

Schema description coverage is 100%, and the schema already documents the downloadable https URL, allowed MIME types, and 50MB limit. The description only reiterates the image-format restriction and does not add meaning beyond schema, so it meets the baseline for a fully covered schema.

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

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

The description opens with 'Reverse image search' and clearly states the action: provide an image and get visually matching web pages and labels. It is specific about verb and resource, but it does not distinguish itself from the sibling google_image_search, which appears to serve a very similar purpose.

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 use case is implied by 'reverse image search' and the Korean phrase '이미지로 검색', and the only exclusion is that only image-format files are allowed. There is no explicit guidance on when to prefer this over google_image_search, google_search, or image_similarity, so an agent must infer the appropriate 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?

The annotations already establish that this is a read-only, open-world search, but the description adds valuable behavioral context beyond them: a maximum of 20 results, an expected processing time of 30–60 seconds, and a cost of 15 points per call. These are important for planning and cost awareness, though permission or failure behavior is not covered.

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-loads the core purpose, latency, and cost, which is good. However, the same content is repeated in Korean and English, making it less efficient than it could be, even if the bilingual format is intentional.

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 one simple required parameter, a clear list of returned fields, no output schema, and annotations covering safety, the description provides enough context to call the tool correctly. The main omission is routing guidance relative to similar search tools, but the core operational details are present.

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 single 'keyword' parameter is already fully documented in the schema. The description reinforces that this is a keyword search but does not add syntax, format, or interpretation details beyond what the schema provides, making the baseline 3 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 and resource ('Google Maps place search') and lists the returned fields, so an agent can understand what the tool does without the schema. It does not explicitly distinguish itself from similar siblings such as geo_place_search or geo_address_search, 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 on when to use this tool instead of similar sibling tools like geo_place_search, geo_address_search, or location. Usage is only implied by the keyword-place-search phrasing, which is insufficient given the crowded sibling set.

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 openWorldHint=true, so safety is covered. The description adds genuinely new context: the list of returned fields (there is no output schema) and the quota cost of 7 points per call — an important operational constraint. It doesn't mention page-size limits or result ordering, but that is minor against what it does disclose.

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 definition is short and front-loaded, with purpose first and cost last. The English and Korean sentences duplicate the same content, which is a small space cost but is plausibly intentional for a bilingual service.

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, 2-parameter, read-only search tool with no output schema, the description covers the return fields and the per-call cost — the two things an agent can't read from structured data. Nothing critical, such as pagination limits, remains 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 coverage is 100%: keyword (1–200 chars) and page (1–10, default 1) are both documented in the schema. The description adds nothing about either parameter, so 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?

The description pairs a specific verb and resource ('Google News search') with the exact fields returned (title, publisher, published time, link), so the agent knows precisely what comes back. It does not, however, explicitly distinguish itself from google_search, google_image_search, or google_shopping_search, which are the closest siblings.

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 about when to use this tool versus the other search tools in the catalog, and no prerequisites or exclusions. The only usage signal is the tool name and the mention of news fields, which the agent must infer.

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?

Beyond readOnlyHint/openWorldHint, the description discloses pricing (70 points per call) and a non-obvious failure mode: if the scan cannot cover all ranges needed to determine rank, the call fails with no result and no charge. It stops short of describing the return payload for a tool with no 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 core purpose is front-loaded in the first sentence, followed by operational constraints. The English/Korean duplication is expected for a bilingual catalog but does add length without adding 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?

For a two-parameter read-only lookup with full schema coverage, the definition covers purpose, cost, and failure semantics. The main remaining gap is that, with no output schema, it does not say what a successful result contains beyond an implied rank position.

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% and both parameters are documented with an example and a length bound, so the schema carries the semantics. The description adds no parameter-level detail beyond what the schema already states, making the baseline 3 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 precise verb and resource — find where a domain ranks (1-100) in Google results for a keyword — with explicit scope (top 100) and inputs (keyword, domain). This is clearly distinct from siblings like google_search or google_image_search, which return results rather than a rank position.

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 establishes clear operating context: a per-call cost of 70 points and the condition under which the call fails without being charged. It does not explicitly name alternatives (e.g. google_search for raw SERP data) or state when not to use it, so it falls short of a full when/when-not treatment.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a concrete cost of 7 points per call and explains how results are paged. That is real operational context an agent cannot get from the annotations or schema. It stops short of stating per-page result counts or any pagination ceiling.

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 purpose and return fields, and every sentence adds something (return shape, paging, cost). The English/Korean duplication is slightly redundant for an agent but aids the service's bilingual audience.

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 names the returned fields (link, title, snippet), plus pagination and cost. Missing only secondary details such as results per page or how deep paging is supported for a two-parameter open-world search 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 100%, with both `keyword` and `page` documented inline, so the schema carries the parameter burden. The description only adds the notion of stepping through pages, which the schema's 'page (default 1)' already implies.

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 ('Google keyword search') and enumerates the return shape (link, title, snippet), which lets an agent distinguish it as general web search from the image/news/shopping/lens search siblings. It never names those siblings explicitly, so differentiation is by inference 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?

Usage is implied by the word 'web' against siblings like google_news_search or google_image_search, and paging via `page` is described. However, there is no explicit statement of when to choose this over the other Google search tools, nor any exclusion or prerequisite.

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 read-only and open-world behavior, so the bar is lower; the description adds a concrete cost signal ('호출당 7포인트'), which is genuinely useful behavioral context an agent cannot get from structured fields. It does not discuss result volume, pagination behavior, or failure modes.

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 verb and resource in the first clause, followed by return fields and cost — a sensible priority order. The Korean restatement duplicates the English, which is a small amount of redundancy but serves a bilingual audience.

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 compensates by naming the returned fields, and it discloses the per-call point cost. Only soft gap is that it says nothing about result count or page traversal, though the schema documents the page parameter.

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% (keyword 1~200 chars, page 1~10 default 1), so the schema already carries parameter meaning. The description only restates 'for a keyword' and adds nothing beyond it, which is the baseline 3 case.

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 ('Google Shopping search') and enumerates the returned fields (title, price, shop, rating, link), so an agent knows exactly what kind of result it gets. It does not, however, distinguish itself from the shopping siblings (naver_shopping_product, coupang_product, amazon_product) which are the most likely source of confusion.

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 by 'for a keyword' — i.e. use this when you have a product search term — but there is no explicit guidance on when to prefer it over naver_shopping_product or coupang_product, and no mention of prerequisites. Adequate for a simple, self-evident search tool, but no routing help.

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 cover readOnlyHint and openWorldHint, so the safety profile is already handled. The description adds genuinely new behavioral context: the exact fields returned and a per-call cost ('[호출당 10포인트]'), which functions like a rate/cost disclosure the schema and annotations do not carry.

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 resource and return fields, and the cost note is placed at the end. The English/Korean duplication doubles the token count, but it appears intentional rather than 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 listing the returned fields in the description is the right compensation, and the cost note rounds it out. It omits failure behavior (private/deleted posts, invalid URLs), which is the main remaining 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?

Only one parameter with 100% schema description coverage, including format examples (/p/코드/ or /reel/코드/). The description restates that the URL points to a post or reel but adds no syntax or format detail beyond the schema — 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-implied resource ('Instagram post or reel by URL') and enumerates exactly what is retrieved (likes, comments count, views, caption, hashtags, media URLs). This clearly separates it from the sibling instagram_profile, which is profile-scoped rather than post-scoped.

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 'by URL' framing implies the precondition (you already have a post/reel URL), but no when-to-use/when-not statement or alternative routing (e.g., instagram_profile for accounts) is given. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: 40-60 second processing time and a 20-point cost per call, which an agent needs to budget correctly.

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 front-loaded with the return payload first, then latency and cost. It is efficient, though the Korean sentence largely restates the English one rather than adding information, which inflates length slightly.

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 return values and does so well by listing the fields. Combined with timing and cost, an agent has enough to call it correctly, though error/private-account behavior is 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 100% and both url and username are documented in the schema, including the 'username or url required' constraint. The description adds nothing to parameter meaning, so 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?

The description names a specific resource (Instagram public profile) and enumerates exact fields returned: followers, following, posts count, bio, verification, and 12 latest posts. It is clearly distinct from instagram_post by resource type, though it never explicitly names the sibling to differentiate.

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 qualifier 'public profile' implies the tool only works on public accounts, which is a useful usage constraint, and the cost/latency note helps a caller judge invocation. However, there is no explicit when-to-use vs instagram_post or tiktok_profile, nor a statement of when-not to use it.

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?

The readOnlyHint annotation already indicates a safe read operation, and the description adds beyond that: the scope constraint that subdomains are not tracked, and the cost signal of 100 points per call. It does not describe the exact return shape, but for a simple read-only lookup with annotations present, the added context is meaningful.

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 with the main purpose. The Korean sentence largely repeats the English sentence, which is mild redundancy, but the scope caveat and cost note are valuable additions. It is appropriately sized overall, with only one repetitive sentence keeping it from a top score.

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 one-parameter, read-only lookup with no output schema and no nested objects, the description covers the essential context: what the tool does, the domain scope, and the cost. It does not specify the output format in detail, but 'historical IP address changes' sufficiently conveys what the agent should expect.

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 already documents the single 'domain' parameter at 100% coverage with an example. The description adds important semantic nuance not in the schema: the query is based on the top-level domain and subdomains are not tracked, which tells the agent to provide an apex domain like 'apick.app' rather than a subdomain.

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 opens with a specific verb and resource: 'Look up the historical IP address changes of a domain.' This clearly distinguishes the tool from siblings like nslookup (current DNS), reverse_ip (IP-to-domain), and whois (registration info), since it is specifically about historical IP changes. The Korean sentence reinforces the same purpose without ambiguity.

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 intended use is clear: use it when you need historical IP changes for a domain. The description also gives an explicit exclusion: subdomains are not tracked and lookup is based on the top-level/apex domain. It does not explicitly name alternative tools for other lookups, but the historical vs. current distinction is implied well enough.

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, openWorldHint), so the bar is lower. The description adds genuine context beyond them by disclosing the per-call cost ('[호출당 30포인트]') and the exact field set returned, which is behavior the annotations do not convey.

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 is front-loaded and content is compact; the field list and cost note are useful rather than filler. The English and Korean halves are largely parallel translations, which adds length but is localization rather than true redundancy.

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

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

No output schema exists, but the description enumerates the returned fields (name, about, industries, size, headquarters, followers, employees, updates), compensating adequately. Combined with annotations covering safety and the cost note, an agent has what it needs to invoke the tool correctly.

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

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

Schema description coverage is 100% and the single 'url' parameter is documented in the schema with a concrete example, so the schema does the heavy lifting. The description only echoes 'by URL' without adding format or validation detail beyond the schema, so 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 and resource ('LinkedIn company page by URL') and enumerates the returned fields, so the agent knows exactly what it retrieves. The resource (company) reads distinctly from siblings linkedin_profile and linkedin_job, though the description never names those alternatives directly.

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 by the required LinkedIn company URL, which naturally scopes when the tool applies. However, there is no explicit when-to-use guidance, no exclusions, and no routing to linkedin_profile/linkedin_job for other LinkedIn entities.

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 openWorldHint=true, so the safety profile is covered structurally. The description adds one genuinely useful piece of behavioral context not present in annotations: the 30-point cost per call, which lets the agent weigh invocation. It says nothing about auth needs, behavior on invalid/expired/private postings, or rate limits, so it earns a moderate rather than high score.

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 English field list is front-loaded and information-dense, with the cost note correctly trailing. The Korean sentence is a full restatement rather than a complement, which is redundancy for a bilingual audience but consumes space without adding new semantic content.

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

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

With no output schema, the description carries the return-value burden and discharges it by enumerating the nine returned fields, and it discloses the call cost — both things an agent needs. It lacks only error/edge-case behavior for a single-parameter scrape tool, which is a minor gap at this complexity.

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

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

Schema description coverage is 100% and the single url parameter is documented in the schema with a concrete example format (https://www.linkedin.com/jobs/view/{번호}). The description adds no syntax, canonicalization, or accepted-URL-variant guidance beyond that, so 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+resource ('LinkedIn job posting by URL') and enumerates the exact fields returned (title, company, location, employment type, seniority, industries, description, posted date, applicants), which makes the resource unmistakable against siblings like linkedin_company and linkedin_profile. It does not explicitly name those siblings to draw the boundary, 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, when-not-to-use, or alternative-tool guidance. The agent must infer from the name and the URL parameter alone that this is the tool for a single job posting rather than a company or profile lookup. The only supplementary note is the per-call cost, which is pricing rather than selection 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 and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral trait — a cost of '30 points per call' — but says nothing about failure modes, auth, or rate limits beyond cost.

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 in one English sentence plus a parallel Korean sentence, with the cost tagged at the end. Efficient overall, though the bilingual duplication conveys the same content twice.

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-parameter lookup with full schema coverage and no output schema, the definition is essentially complete: it names the source, the input form, the returned fields, and the call cost. Only usage routing to sibling tools 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% and there is a single required 'url' parameter with its own example in the schema. The description only confirms it operates 'by URL' and adds no syntax or format detail beyond the schema, so 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 and resource — retrieves a LinkedIn public profile by URL — and enumerates the returned fields (name, position, experience, education, followers, connections, recent posts). This is clear and concrete, though it does not explicitly name its closest siblings (linkedin_company, linkedin_job) to differentiate scope.

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 or when-not-to-use guidance and no mention of alternatives, despite several near-neighbors (linkedin_company, linkedin_job, other *_profile tools). The URL requirement is conveyed only implicitly via the schema, not as usage direction.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context by explaining that a domain is resolved to its IP before lookup and that each call costs 30 points; it does not detail output format or error 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?

It is short and front-loaded in English, but the Korean text largely duplicates the English sentence, creating redundancy. The cost note is useful but placed at the end; a single-language version would be tighter.

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 one-parameter, read-only lookup tool with no output schema, the description provides enough to call it: input type, resolution behavior, cost, and result concept. It could be more explicit about the return structure, but the low complexity keeps this from being a serious 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 coverage is 100% and the address property is already described as 'domain or IP' with an example. The description adds a small amount of process information (domain-to-IP resolution) but does not materially expand parameter meaning.

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 ('Look up') and resource ('geographic location of a domain or IP') and adds the domain-resolution behavior. It clearly states the tool's function but does not explicitly differentiate it from sibling lookup tools like nslookup or whois.

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 about when to prefer this tool over nslookup, whois, or reverse_ip is provided. The closest signal is the phrase 'geographic location,' which implies a use case but never states exclusions or alternatives.

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 openWorldHint=true, so safety is covered. The description adds a meaningful piece of behavioral context the schema cannot: a cost of 30 points per call, which directly affects invocation decisions. It stops short of describing failure modes (e.g., invalid/non-brand-store URLs).

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 resource and return fields, and the cost note is placed at the end. The bilingual English/Korean duplication roughly doubles the text for the same content, which is a minor redundancy but justified for a Korean-market tool.

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

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

For a single-parameter read-only tool with no output schema, the description covers source scope, returned fields, and cost. It is nearly complete; only edge-case behavior for malformed or non-brand-store URLs is 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?

Only one parameter, and schema coverage is 100% with the URL format and an example already documented in the schema. The description's 'by URL' phrasing adds no syntax detail beyond what the schema provides, so 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 (retrieve) and resource (Naver brand store product) scoped by URL, and enumerates exactly which fields come back (title, prices, discount, reviews, sellers, product info, tags, images). The 'Naver brand store' qualifier cleanly distinguishes it from siblings like amazon_product and coupang_product.

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 says nothing about when to choose this tool over the other product-retrieval siblings (amazon_product, coupang_product) or when a URL is out of scope. Usage is only inferable from the name; no explicit conditions or alternatives are given.

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

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

Annotations already indicate read-only and open-world behavior, and the description adds value beyond that by stating that invalid non-domain inputs return an error and that results reflect currently registered IPs. It does not mention empty-result handling or DNS resolver details, but those are minor for a simple read-only tool.

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 appropriately short and front-loaded, with the core action in the first sentence followed by validation behavior and cost. No unnecessary background or fluff is included.

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 one-parameter, read-only DNS lookup with no output schema, the description provides enough context: what input is required, what output to expect (list of currently registered IP addresses), and what error to anticipate for invalid input. Nothing essential 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?

The only parameter, domain, already has 100% schema coverage with a clear description and example (apick.app). The tool description reinforces that the value must be a domain, but it does not add substantial meaning 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?

The description uses a specific verb and resource: 'Resolve a domain name to its currently registered IP addresses (DNS lookup).' This clearly distinguishes it from sibling tools such as reverse_ip (IP-to-domain lookup) and whois (domain registration metadata).

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 use case is explicitly clear: invoke it when given a domain and needing its current IP addresses. It also states that non-domain values produce an error, which is a useful when-not-to-use signal. However, it does not explicitly mention alternatives like reverse_ip or whois.

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 openWorldHint=true, so the safety profile is covered. The description adds two useful behavioral details beyond annotations: calls cost 100 points each, and the input must be in IP-address format only. It still does not describe output size, pagination, or result freshness, which keeps it 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?

The definition is short and front-loads the core operation, then adds the format constraint and cost. The English and Korean lines partly duplicate each other, but the overall length remains efficient 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?

For a simple read-only, one-parameter lookup, the description covers what the tool returns (domains hosted on the IP), the input restriction, and the per-call cost. Without an output schema, it could say a bit more about result shape or historical coverage, but it is otherwise sufficient to call 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 100%, so the schema already defines the single ip parameter and gives an example. The description still adds a meaningful constraint by saying only IP-address format is accepted, which clarifies that hostnames or domains are not valid inputs.

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: reverse IP lookup that lists domains hosted on a given IP address. It is clear enough to separate from nslookup and whois by implication, but it does not explicitly distinguish itself from the nearby sibling ip_history, especially since the Korean text refers to domain history information.

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?

Use is implied by the operation name and the statement that only IP address format is allowed. However, there is no explicit guidance on when to choose reverse_ip over alternatives such as ip_history, nslookup, or whois, and no exclusions are stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description is not obligated to restate that. It adds genuine non-schema context: the credit cost of 20 points per call and a preview of the returned metric set. It stops short of describing failure modes for private/deleted accounts, which holds it below 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?

The English sentence is well front-loaded and information-dense, but the Korean sentence is a near-complete duplicate rather than a distinct constraint, so half the body repeats without adding new semantics. The cost tag is compact and useful, keeping the overall structure acceptable.

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?

This is a simple two-parameter read tool with fully documented inputs; the description compensates for the absent output schema by listing the returned fields (followers, likes, video count, bio, recent popular videos). An agent has enough to invoke and interpret it, though account-state edge cases 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 100%, and the schema already documents both url (with a format example) and username (with the '@ optional, either/or requirement). The description adds no parameter-level meaning beyond the schema, so 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 and resource ('TikTok public profile') and enumerates exactly what is returned: followers, likes, videos count, bio, and recent popular videos with view and engagement counts. It is unmistakable against the sibling instagram_profile or crawl_youtube because the platform 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?

The word 'public' implicitly scopes usage to public accounts, and the cost tag hints at a quota consideration, but there is no explicit when-to-use, when-not-to-use, or pointer to the sibling instagram_profile for other platforms. Usage must be inferred from the name and the public/private qualifier.

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 openWorldHint=true, so the safety profile is covered. The description usefully adds the 5-point-per-call cost, but says nothing about rendering behavior (JS execution, timeouts, error modes for unreachable pages), so it adds only modest value.

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?

Very short and front-loaded, with the core action stated first and cost last. The English and Korean sentences are essentially duplicates, a minor redundancy, but there is no padding otherwise.

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 1-parameter, read-only tool with no output schema and annotations covering safety, the description gives enough to invoke it correctly: action, return type, and cost. It omits edge-case behavior (unreachable URLs, JS rendering) 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?

Only one parameter exists and schema description coverage is 100% (with an example URL), so the schema fully carries parameter meaning. The description adds nothing beyond restating that a URL is supplied, matching the baseline 3 for schema-documented params.

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: fetch a web page and return its rendered HTML source, which is clearly distinct from url_screenshot (image) and html_to_pdf (conversion). It does not explicitly name those siblings, 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?

No guidance on when to use this tool versus alternatives like url_screenshot or google_search, nor any prerequisites. The only contextual note is the per-call cost, which is pricing rather than 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 and openWorldHint, so the description only needs to add extra behavioral context. It adds the JPEG output format and the per-call cost of 5 points, which are useful operational details beyond the schema.

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

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

The description is compact, with a clear English sentence, a Korean equivalent, and the cost note. The bilingual repetition is somewhat redundant but serves accessibility and remains concise overall.

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 one-parameter, read-only tool, the description adequately covers input, output format, and cost. Missing details like viewport size or page-load behavior would be nice but are not essential for basic 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?

The input schema covers the only parameter fully with a description and example URL, so the tool description does not need to add parameter semantics. The description adds no new meaning about the url parameter beyond what the schema already 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 clearly states the action (capture a screenshot), the resource (a web page URL), and the return type (JPEG image). This distinguishes it from sibling tools like url_html and url_similarity, 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?

The description implies the tool is for capturing visual screenshots, but it does not explicitly state when to choose it over alternatives such as url_html or url_similarity. There is no exclusionary guidance or mention of when not to use it.

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 set readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the cost detail ('[호출당 5포인트]') and says a similarity result is returned, but it does not describe the output shape, scale, or whether the pages are fetched server-side. This is acceptable 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?

The description is short and front-loaded with the core purpose in the first English sentence. There is some bilingual redundancy (the Korean sentence restates the English one), but the added use case and cost bracket are useful and keep it compact.

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 two-parameter read-only tool with annotations, the description covers purpose, use cases, and cost. However, with no output schema, it leaves the exact meaning of 'similarity result' undefined (e.g., numeric score, percentage, label), which an agent may need to interpret the response confidently.

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%: url1 and url2 are each documented as the first/second page URL to compare. The tool description adds only the general concept of page similarity, not new parameter-level meaning, so the schema carries the load and 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 operation ('Compare two web pages and judge how similar they are') with a clear resource (two page URLs), and the Korean phrase '두 사이트 페이지의 유사 여부를 분석' reinforces that it analyzes page similarity. This is distinct from sibling tools like image_similarity, which compare images rather than web pages.

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 an explicit use case ('피싱·복제 사이트 판별 등에 활용할 수 있습니다' - can be used to identify phishing/clone sites), which tells an agent when it is appropriate. It does not discuss when not to use it or mention alternatives such as image_similarity, so it stops short of full 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 readOnlyHint and openWorldHint already covering the safety profile, the description adds genuinely new behavioral context: the cost ('[호출당 100포인트]') and the breadth of queryable targets including AS numbers. It still omits behavior on invalid input or rate limits, but the paid-call disclosure is valuable context 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?

Front-loaded with the English purpose followed by a faithful Korean restatement plus coverage and cost notes. Every sentence carries information, though the bilingual duplication slightly inflates length for a one-parameter tool.

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

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

No output schema exists, but the description states the return content (registration and ownership information) and the supported query scopes, which is sufficient for a single-parameter lookup. It is complete 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 100%, so the baseline is 3, but the description adds meaning beyond the schema's generic 'domain or IP' by declaring that AS numbers (AS9318), .kr/.한국 domains, and domestic IPs are all valid address values. That expands the accepted input semantics for the single 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?

States a specific verb and resource ('WHOIS lookup for a domain or IP address, returning registration and ownership information') and is easily distinguished from siblings like nslookup and reverse_ip by the WHOIS resource itself. An agent can identify what it does 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 enumerates the input scopes it supports (.kr/.한국 domains, domestic IPs, AS numbers like AS9318), which implies when it is the right tool, but it never names an alternative such as nslookup or reverse_ip, nor states any exclusion. Usage is implied rather than directed.

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 openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful cost signal ('[호출당 10포인트]' – 10 points per call), but says nothing about failure modes for private/deleted posts or any 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?

Front-loaded with the resource and the returned fields, then the cost note last, which is the right order. The English and Korean sentences are verbatim translations of each other, so roughly half the text is duplicated for the bilingual audience.

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 enumerates the return fields (text, time, likes, reposts, replies, views, hashtags, media URLs) and discloses the per-call cost. For a one-parameter read tool this is nearly complete; only error/edge-case behavior 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% and the single parameter carries its own example URL, so the schema does the heavy lifting. The description only restates 'by URL' and adds no format or validation nuance beyond what is already structured.

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 ('X (Twitter) post by URL') plus the exact fields returned, so the agent knows it retrieves a single post's content and metrics. It does not distinguish itself from the sibling x_profile (profile-level vs post-level), leaving minor ambiguity in a crowded social-media toolset.

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 alternatives such as x_profile, instagram_post, or tiktok_profile, and no prerequisites or exclusions. The URL requirement is implied only by the schema, not framed as 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 and openWorldHint=true, so the safety profile is covered. The description adds two useful pieces beyond that: it is limited to *public* profile data, and it discloses a per-call cost of 20 points, which is real operational context. However it omits auth requirements, error behavior for invalid/nonexistent handles, and rate-limit details.

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 resource and returned fields, with the cost tag placed at the end where it is easy to scan. The content is duplicated verbatim in English and Korean, which is redundant for a monolingual reader but clearly intentional for the bilingual audience, so it is not penalized heavily.

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 return values and does so by enumerating the fields returned. Combined with the cost disclosure and annotation-covered safety profile, an agent has enough to invoke it correctly, though error/failure cases 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 coverage is 100%, so both url and username are already documented in the schema, including the 'username or url required' constraint. The description adds no syntax or format guidance beyond the schema, so 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?

Names a specific verb (조회/retrieve) and resource (X public profile) and enumerates the exact data returned: followers, following, post count, bio, verification, and recent posts with engagement. The platform-qualified resource ('X (Twitter) public profile') lets an agent distinguish it from instagram_profile/tiktok_profile, though it never explicitly contrasts with the sibling x_post (single post) tool.

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 only implied by the resource name; there is no explicit when-to-use statement, no condition for choosing between url and username inputs, and no exclusions (e.g., private vs public accounts). An agent can infer the purpose but gets no routing guidance against profile-fetching siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral fact, the 20-point cost per call, but says nothing about pagination, rate limits, or behavior when a channel is not found.

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 core sentence is front-loaded and efficient, but the same content is then repeated verbatim in Korean, roughly doubling the length without adding information. The cost note is well placed but the duplication dilutes conciseness.

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

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

With no output schema, the description correctly carries the burden of describing returns (name, handle, subscribers, description, and tab items). The main omission is guidance on which sibling to pick for adjacent YouTube tasks, but for calling this tool correctly it is largely 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 100%, so tab, count and channel are all documented in the schema with defaults and ranges. The description reinforces the meaning of the tab values and the returned fields but adds no format or syntax detail beyond 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 and resource (look up a YouTube channel) and enumerates what it returns (name, handle, subscribers, description) plus the tab listings. It is clear what the tool does, but it never names or distinguishes itself from near-neighbors like youtube_search, youtube_playlist, or crawl_youtube.

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 when-to-use or when-not-to-use guidance. With siblings such as youtube_search, youtube_playlist and crawl_youtube in the same family, the agent must infer from the name alone which one applies, which is exactly the ambiguity the description should resolve.

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 openWorldHint=true, so safety is covered. The description adds genuinely useful context beyond them: the operation only works on public videos, and it costs 30 points per call, which is a real invocation-side constraint. It does not describe pagination or what happens when a video has no comments.

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 English statement of scope and return fields, followed by the Korean equivalent and a bracketed cost tag. Efficient overall, though the bilingual duplication means the same content is effectively delivered twice.

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 summarises the return shape (author, text, likes, pinned/hearted flags, replies), and with 100% schema coverage the parameter side is handled. Only pagination/edge-case behaviour is left unspecified, which is minor for a list tool with a bounded count parameter.

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

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

Schema description coverage is 100%, so all four parameters (url, sort, count, replies) are already documented in the schema, including defaults and limits. The description only restates the sort modes and the notion of optional replies, adding no format or edge-case detail beyond 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 and resource ('List comments of a public YouTube video') and even enumerates the returned fields (author, text, likes, pinned/hearted flags, replies). It is clearly distinguishable from other YouTube siblings like youtube_subtitle or youtube_metadata, though it doesn't explicitly name an alternative it is not.

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 rather than stated: use it when you need comments, with 'top' or 'new' ordering. There is no when-not guidance (e.g. private/age-restricted videos, or how it relates to crawl_youtube), and no prerequisites beyond the implicit 'public' qualifier. The per-call point cost is the only usage-relevant caveat given.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the billing/rate constraint '[호출당 20포인트]', which is genuinely useful behavioral context not present in any structured field. It still says nothing about pagination or return shape.

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, front-loaded sentences with the action first and the cost caveat last. The Korean mirrors the English for audience reasons, which is slight redundancy but not 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?

With a complete schema and read-only annotations, the definition is callable as-is, but with no output schema it also doesn't hint at what a returned video entry contains, and it leaves the agent to infer how this differs from youtube_search.

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

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

Schema description coverage is 100%, and the schema itself documents both the 'count' range/default and the 'hashtag' format (# optional). The description adds no parameter-level meaning beyond that, so 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 and resource: 'List videos on a YouTube hashtag page.' The 'hashtag page' scope distinguishes it implicitly from youtube_search, but it never names a sibling to make the boundary explicit, which keeps it from 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?

Usage is only implied — an agent can infer you call it when you want videos tied to a hashtag. There is no explicit when-to-use, no when-not-to-use, and no pointer to youtube_search/youtube_channel for the overlapping cases.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds two genuinely useful facts beyond the annotations: the target must be a public video, and the call costs 20 points — a cost signal that affects invocation decisions and appears nowhere in structured fields. It stops short of describing failure behavior on private/removed videos, keeping it off 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?

Front-loaded with the verb and key resource, which is good, but the same field list is repeated verbatim in Korean, doubling length without adding information for a given reader. The trailing point-cost tag is useful but the bilingual duplication is not fully earning its place.

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

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

For a single-param read-only lookup with no output schema, the description is close to sufficient: it names the returned fields, the accessibility constraint, and the cost. Nothing essential for correct invocation is missing, though a note on behavior for non-public videos would close the last 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 coverage is 100% and the schema already documents the accepted URL/ID formats, so the description correctly defers to it. The description adds no syntax or format detail beyond what the schema param description provides — the baseline 3 for a fully-covered single param.

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 ('Look up metadata') and resource ('public YouTube video'), then enumerates the exact fields returned (title, channel, duration, views, likes, upload date, description, tags, chapters, thumbnails). This lets an agent distinguish it from siblings like youtube_subtitle, youtube_thumbnail, or download_youtube_video 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 description scopes usage to 'public' videos, which implicitly tells the agent when it will and won't work, but it never names an alternative or states when to prefer crawl_youtube or youtube_subtitle instead. Usage is implied rather than routed.

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 openWorldHint=true, so safety is covered. The description adds value beyond them by specifying the 'public' scope constraint and disclosing a per-call cost (20포인트), which is exactly the kind of operational context annotations do not carry. It does not discuss pagination or truncation 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?

Front-loaded with the verb and payload in the first sentence, then the Korean equivalent and the cost note. The bilingual restatement is redundant for an English reader but serves the target audience and remains compact.

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 readOnly/openWorld annotations covering safety and no output schema, the description supplies the missing pieces: the returned fields, the public-only scope, and the cost. A complete picture for a simple 2-parameter read tool, though usage routing against siblings and any list-size limits remain 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 100%, and both parameters (url with list=/PL... example, count with 1~200 default 50) are fully documented in the schema. The description adds no parameter-level meaning beyond that, so 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 and resource ('Look up a public YouTube playlist') and enumerates the return payload (title, channel, video count, video list), which clearly separates it from siblings like youtube_channel or youtube_comments. It stops short of naming any alternative tool, so sibling differentiation is implicit rather than explicit.

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 on when to use this tool versus youtube_channel, youtube_search, youtube_metadata or crawl_youtube, and no stated prerequisites. The only contextual cue is 'public' playlist, which hints at a scope limit but is not framed as a usage rule.

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 establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context: the per-call cost ('[호출당 20포인트]') and the fact that sorting and filtering are supported, which matters for budgeting and for deciding whether one call suffices.

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 English sentence is front-loaded with the verb, resource, and return fields, and the cost note is appended cleanly. The Korean sentence largely restates the English one rather than adding information, which is mild redundancy but justified for a bilingual audience.

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 compensates by listing the fields returned (title, channel, duration, views, thumbnail) and by noting sort and filter support. It omits pagination or continuation behavior, but for a single-call search tool with fully documented parameters this is close to 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 four parameters carry enums with inline descriptions, so the schema already does the heavy lifting. The description restates sort options and filter categories but adds no syntax, default, or interaction detail beyond the schema, making 3 the correct 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 names a specific verb and resource ('Search YouTube by keyword') and enumerates the result kinds (videos, shorts, channels, playlists) and returned fields, so the agent knows exactly what this tool produces. It does not explicitly contrast itself with near-neighbors like youtube_channel, youtube_playlist, or crawl_youtube, which keeps it 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?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named despite several overlapping siblings (youtube_channel, youtube_playlist, youtube_hashtag, crawl_youtube). The agent must infer that this is the general keyword-search entry point from the description alone.

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 and openWorldHint. The description adds value beyond them by disclosing the cost (30 points per call) and the constraint to public videos, plus the dependency on youtube_subtitle_list. It doesn't describe the returned file/payload structure, but the safety profile is already covered.

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 purpose sentence, then a prerequisite and a cost note; no wasted framing. The bilingual duplication adds length but serves the Korean-facing audience and mirrors the schema 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 read-only download tool with no output schema, the description covers purpose, formats, prerequisite, and cost. Return-value details are not strictly required, leaving only minor gaps such as error behavior for videos lacking subtitles.

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 url, lang, type, and format in detail, including the translated-subtitle caveat. The description adds nothing beyond the schema, so the 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 (download) and resource (subtitles of a public YouTube video) and enumerates the output formats (VTT, SRT, plain text). It also routes the agent to the sibling youtube_subtitle_list for language discovery, distinguishing it from download_youtube_video and youtube_metadata.

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 clear prerequisite workflow: check available languages via youtube_subtitle_list before calling. This is the key 'when/how' guidance for this tool, though it does not state explicit exclusions (e.g., videos without subtitles).

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, openWorldHint=true), so the lower bar applies. The description adds useful non-obvious context beyond those annotations: the video must be public, subtitles covered include both manual and auto-generated, and a per-call cost of 20 points. It does not describe return format, but that is acceptable for a simple read.

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, front-loaded with the purpose, then scope, then cost. The Korean sentence repeats the English content, which is redundant for a bilingual audience but not wasteful enough to harm usability. Nothing else is superfluous.

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 one-parameter read tool with full annotation coverage and no output schema, the description supplies the essentials: scope, subtitle types, and cost. It could say more about how to use the result versus youtube_subtitle, but nothing critical to issuing a correct call 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?

Only one parameter exists and schema description coverage is 100% ('유튜브 영상 URL 또는 11자리 영상 ID'), so the schema already documents the accepted input forms. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 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 and resource: 'List the manual and auto-generated subtitle languages available for a public YouTube video.' This clearly distinguishes the tool's output (a list of available subtitle languages) from the content-fetching intent implied by the sibling youtube_subtitle. It stops short of explicitly naming that sibling, so it is clear but not perfectly differentiated.

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

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

Usage is only implied: it applies to 'a public YouTube video,' which is a real constraint, but there is no explicit when-to-use/when-not statement or reference to alternatives such as youtube_subtitle for retrieving subtitle content. An agent can infer the context but must open the sibling set to know which tool to pick.

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 and openWorldHint, so the bar is lower, and the description still adds genuinely useful facts beyond them: the per-call cost of 20 points, the fixed output format (JPG), the 'largest available' resolution guarantee, and the restriction to public videos. It does not explain what happens on private/deleted videos or where the image is delivered, which keeps 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 bracketed cost note, with the core action front-loaded; the Korean mirror is a reasonable cost for a bilingual service rather than filler. Slightly redundant across languages, but no wasted explanatory prose.

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 one-parameter, non-destructive download tool with annotations covering safety, the description supplies the essentials: source restriction, format, resolution, and cost. The remaining gap is the return channel (URL vs binary payload) with no output schema to cover it, but that is a minor omission.

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

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

Schema description coverage is 100% and the single 'url' parameter is fully documented there (YouTube URL or 11-character video ID), so the schema does the heavy lifting and the description adds nothing about the parameter. Baseline 3 for a single fully-documented 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?

Specific verb+resource with useful scoping: 'Download the largest thumbnail of a public YouTube video as a JPG image' tells the agent what is produced, at which resolution, and from what kind of source. It does not name the closely related sibling extract_video_thumbnail, so an agent still has to infer which of the two to call, which keeps this at 4 rather than 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?

Usage is only implied: the 'public YouTube video' qualifier signals applicability and the 11-char video ID hints at accepted input, but there is no explicit when-to-use, when-not-to-use, or alternative (e.g. extract_video_thumbnail, download_youtube_video). Nothing is misleading, but the routing decision 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.