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=false, idempotentHint=true and openWorldHint=true, but the description adds substantive behavior the annotations cannot convey: immediate job_id return, the polling handoff, and the point-billing model (base 10P per job, 5P per result, reserve-then-charge-actual semantics). Auth requirements and rate limits are not covered, so a 4 rather than 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 async contract and cost are front-loaded in the first sentences, and every sentence carries information. The English/Korean duplication of the same two facts is mildly redundant, though defensible 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 naming the return value (job_id) and the follow-up tool for results, and it discloses the cost model. It stops short of covering failure/retry behavior beyond what idempotency_key implies.

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/asin exclusivity, the 1-100 range for max_results, and the idempotency key format. The description only restates the max_results reservation behavior already present in the schema, adding no new parameter-level meaning; 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 ('Collect Amazon product reviews') with explicit scope ('up to 100') and enumerates the returned fields (rating, title, text, date, verified purchase, helpful count). This clearly separates it from the sibling amazon_product, which fetches product data rather than reviews.

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

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

Explicitly tells the agent the tool is asynchronous and routes it to the sibling scrape_jobs_status for retrieving results, which is the key decision an agent must make here. It lacks a when-not condition (e.g., when to prefer a synchronous alternative), so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-network behavior are covered. The description usefully adds the per-call cost (40 points) and the fact that both profile and recent video data are returned, but it omits how many videos, whether results are paginated, 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?

Two short bilingual sentences plus a bracketed cost note, with the core purpose front-loaded in the first sentence. Every sentence carries content, though the full Korean restatement is somewhat redundant with the English.

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 explain the return shape, and it does name the two data sets (profile + recent videos). However it leaves the volume/format of returned videos unspecified, and gives no guidance for choosing it over sibling youtube tools.

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

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

Schema coverage is 100% and the single parameter's schema description already enumerates the accepted forms (channel ID, handle, channel ID UC…, or URL). The description adds nothing 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 (collect) and resource (YouTube channel profile + latest uploaded videos), naming both artifacts returned. It does not, however, differentiate itself from siblings like youtube_channel or youtube_metadata, which the agent would have to disambiguate on its own.

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

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

There is no when-to-use guidance and no mention of alternatives among the many youtube_* siblings (youtube_channel, youtube_metadata, youtube_search). The only usage signal is the point cost, which is a pricing hint rather than a selection 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 only declare readOnlyHint and openWorldHint, so the description carries real added weight: it discloses the 1-hour link expiry, the base-fee-plus-per-10MB billing model, the 30-point per-call charge, and the public-video restriction. It omits failure behavior (geo-blocked, private, age-gated videos) and any rate limits, which keeps it short of a 5.

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

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

Front-loaded with the core action and scope in the first clause, then billing and the youtube_formats pointer, which is a sensible priority order. The full Korean restatement duplicates every fact already given in English, which is defensible for the audience but adds bulk.

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 describing the return value (a download link valid for 1 hour) and the cost model, so the agent knows what it gets and what it pays. The only remaining gap is error/failure semantics for unavailable videos, which is minor for a 5-parameter, mostly self-documenting tool.

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

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

Schema description coverage is 100%, so the schema already documents url, quality, start, end, and codec with examples and defaults. The description only restates 'chosen quality (up to 4K)' and 'optionally only a time range' at a high level, adding no syntax or edge-case detail beyond the schema (e.g., what happens if start exceeds end). 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 (download a public YouTube video) plus the output format (MP4), the quality ceiling (up to 4K), the optional time-range trimming, and the returned artifact (1-hour download link). An agent can distinguish this from youtube_audio_download, video_to_mp3, and youtube_formats without opening any schema.

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

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

Explicitly routes the agent through youtube_formats first to inspect sizes and estimated costs, which is a concrete usage prerequisite rather than a vague hint. It also implies the scope limit (public videos only) and that billing scales with file size, but it never states when-not to use it (e.g., versus the audio-only or subtitle 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, so the safety profile is covered. The description adds genuinely new behavioral context: a per-call cost of 20 points and the 20-results-per-page pagination limit, which are not derivable from structured fields. It omits any note on rate limits or failures, but the added cost signal is valuable.

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 facts (keyword search, returned fields, pagination, cost) are front-loaded and useful, but the same content is restated in both English and Korean, which doubles length without adding information. Structure is acceptable but not tight.

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, a fully documented 2-param schema, and no output schema, the description covers purpose, return fields, pagination range, and cost. Only the routing to sibling search tools is missing, which is a minor gap for a callable search endpoint.

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

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

Schema description coverage is 100%, so both keyword and page are already documented in the schema. The description only adds that page ranges allow iterating through results, which the schema already implies (1~5, 20/page). Baseline 3 is appropriate when the schema carries the 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?

States a specific verb+resource ('Google image search by keyword') and enumerates the returned fields (image URL, source link, title), which distinguishes it from google_search and google_news_search by the 'image' resource. However, it never explicitly names those siblings or clarifies the boundary with google_lens_search, so differentiation is implicit.

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

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

The description explains pagination mechanics ('page 로 결과 페이지를 넘겨 가며 조회') but gives no when-to-use guidance, no exclusions, and does not route the agent to or away from alternative search tools. An agent must infer the choice purely from the resource noun.

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?

Goes well beyond the annotations by disclosing the asynchronous job pattern (returns job_id immediately, results via scrape_jobs_status), the output language (English), and the billing behavior ('Charged 20 points only when the place is found', full refund on failure). Annotations confirm idempotentHint=true while the schema supplies idempotency_key, and readOnlyHint=false (a job is created) is consistent with the description rather than contradicted.

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 portion is dense and front-loaded: capabilities first, then inputs, then the async contract, then cost. It is somewhat inflated by a near-full Korean restatement of the same facts, which is redundant for a single-language reader, though it does not obscure the critical leads.

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 still fully covers the call contract: where inputs come from, the immediate job_id return, the required polling tool, the result language, and the cost/refund rule. Nothing an agent needs to invoke and then retrieve results is missing.

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

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

Schema description coverage is 100%: url, place_id (with pattern) and idempotency_key (with pattern) are all documented in the schema itself. The description only restates the source of place_id/url ('from google_maps_search, or a Google Maps place URL'), adding no new syntax or format guidance beyond what the schema already gives. Baseline 3 applies when the schema carries the parameter burden.

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 precise verb+resource ('Google Maps place details') and enumerates the exact payload it retrieves: rating, reviews count, star distribution, top reviews, opening hours, busy hours, similar places, photos. It is clearly distinguishable from sibling google_maps_search, which supplies the input rather than the details. An agent can select it without opening a schema.

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

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

Gives clear operational context: obtain place_id from google_maps_search, or pass a Google Maps place URL, then poll scrape_jobs_status for the result. This routes the agent to both the upstream and downstream sibling. It stops short of an explicit when-not condition (e.g. use search instead of this tool when you only need the place_id), but the sourcing guidance is unambiguous.

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 still adds material context beyond them: a hard 20-place cap, an expected 30-60 second latency, and a cost of 10 points per call. Only the return format/pagination is left unspecified.

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 front-loaded and the field list is useful, but the same content is restated verbatim in Korean and English. The repeat is not pure waste (latency and point cost appear only in the Korean sentence) yet it inflates the description noticeably 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?

For a one-parameter, no-output-schema lookup with annotations carrying the safety profile, the description supplies return fields, result limits, latency, and cost — everything needed to call it correctly and budget for it. It is complete for its complexity level.

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?

With a single parameter and 100% schema description coverage, the schema already documents 'keyword' including its length bound and example. The description adds no syntax or format detail beyond restating that a keyword drives the search, 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 ('Google Maps place search') and enumerates the returned fields (name, address, phone, rating, reviews, hours, coordinates) plus the 20-result cap for a keyword. The 'Maps' qualifier implicitly separates it from siblings like google_search, google_news_search, and 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 description says what the tool returns but gives no guidance on when to choose it over google_search, search_juso, or location, and no exclusion conditions. Usage is only inferable from the word 'place search'.

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 safe, external-fetch nature is covered structurally. The description adds one genuinely useful behavioral datum — the 5-point cost per call — but says nothing about result caps, pagination limits, or what happens when a keyword returns no news.

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 tool's function and return shape, then the Korean mirror and cost. The bilingual duplication is a deliberate pattern but does slightly inflate length; the English sentence alone carries the full payload.

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 returned fields, and it discloses the cost. It falls short only on pagination/result-volume expectations and any failure behavior for a keyword with no results.

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

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

Schema description coverage is 100%, so both parameters (keyword 1~200 chars, page 1~10) are already documented in the schema. The description only says results are returned 'for a keyword' and adds nothing about the keyword length limit or the page parameter, 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?

The description states a specific verb+resource ('Google News search') and enumerates the returned fields (title, publisher, published time, link), which is more than a bare restatement of the name. It implicitly distinguishes itself from the other search siblings by scope ('news'), but it never explicitly names or contrasts with google_search, google_image_search, or google_shopping_search.

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

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

There is no when-to-use guidance, no when-not-to-use, and no alternatives named among the many sibling search tools. The only supplemental guidance is the per-call cost, which is a pricing fact rather than 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 declare readOnlyHint and openWorldHint, covering the safety profile. The description adds valuable behavioral context beyond annotations: rank range 1-100, failure if all needed segments cannot be checked, no charge on failure, and 50-point cost per call. Output shape and rate limits are still unspecified.

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 core purpose, but the Korean sentence largely duplicates the English meaning, and the pricing/failure notes are separate. Every sentence is relevant, yet the bilingual redundancy reduces 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?

No output schema exists, but the description covers success intent (rank 1-100), failure behavior, and billing. It could specify the exact return shape (e.g., rank number or not-found result), but for a two-parameter read-only tool it is mostly 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%, so the schema already documents keyword (1-200 chars) and domain (including subdomains). The description adds no syntax or constraints beyond what the schema provides; 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 (find where a domain ranks) and resource (Google results for a keyword) with scope (1-100). It implicitly distinguishes itself from general google_search by rank-tracking intent, even though it does not name a sibling 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?

No explicit when-to-use or when-not-to-use guidance, and no alternative sibling such as google_search is referenced. The implied use case is clear from the purpose, but the agent receives no routing instructions.

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 concrete behavior: returned fields are limited to link/title/snippet, pagination is possible via page, and each call costs 5 points. 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 short and front-loaded with the core function and output shape. The bilingual repetition (English and Korean) adds minor redundancy, but it is compact and includes only useful operational notes like pagination and 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?

For a simple read-only lookup with full parameter documentation, the description covers the required keyword, optional page paging, and result fields. It does not detail edge cases like empty results or error formats, but those are not necessary for correct selection and invocation.

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

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

Schema description coverage is 100%, so both keyword and page are already documented in the schema. The description adds only a small amount of extra context about using page to navigate result pages, which is helpful but not essential.

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 ('return'), a clear resource ('Google web search results'), and the exact output fields (link, title, snippet). The 'keyword' qualifier distinguishes it from sibling image/lens search tools like google_image_search and google_lens_search.

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

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

The description implies usage through the keyword-search framing and gives pagination guidance with page, but it never explicitly says when to choose this tool over alternatives or when not to use it. Sibling differentiation is left to the reader.

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 two useful pieces beyond that: the exact result fields (compensating for the absent output schema) and a per-call cost note '[호출당 5포인트]', which is real behavioral context an agent should weigh. It omits pagination behavior despite the page parameter, keeping it short of a 5.

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

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

Core purpose is front-loaded in the first sentence, with output fields and cost trailing efficiently. The bilingual Korean duplication repeats identical content, which is justified for a Korean-language service but is redundancy nonetheless, keeping it from a 5.

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

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

For a simple two-parameter search tool this is largely complete: it states the return fields (important since no output schema exists), the cost, and the parameter intent, while annotations cover the read-only/open-world nature. Pagination semantics and any result-count limits remain unstated.

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 both keyword and page already documented (including the 1~10 page range), so the schema does the heavy lifting. The description only echoes 'for a keyword' and adds no format or constraint 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?

The description gives a specific verb and resource ('Google Shopping search: return product results ... for a keyword') and even enumerates the returned fields, so the tool's function is unmistakable. It does not, however, distinguish itself from the many sibling search tools (google_search, google_image_search, google_news_search, google_lens_search), leaving that separation to the tool name alone.

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

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

There is no when-to-use guidance and no named alternative. An agent scanning the large sibling set of Google search tools gets no signal about when Shopping is preferred over general, image, or news search. The purpose statement implies a product-search use case but stops short of 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?

Annotations declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true, and the description is consistent with all three rather than contradicting them. Beyond that, it adds real behavioral context an agent cannot get from annotations: the 15-item cap, that only public usernames are returned, the immediate job_id handoff, and the cost model (points reserved up to max_results, only actual results charged, 5P per result plus a 50P base from 2026-11-06).

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 purpose, then the async return contract, then the billing caveat; each sentence carries information. The bilingual English/Korean blocks are largely parallel and partly redundant, but the Korean block uniquely carries the point pricing, so the duplication is not pure waste.

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 an async job-submission tool with no output schema, the description covers everything needed to call it correctly: the async pattern, the polling target, the result content limitation (public usernames only), the result cap, and the cost implications of max_results. Remaining unknowns (job TTL, failure modes) are minor.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description earns a bump by tying max_results to billing behavior ('max_results 만큼 예약하고 실제 결과 건수만 차감합니다' plus the 5P/50P pricing), which informs how an agent should size the parameter. It adds little about url or idempotency_key beyond what the schema already documents.

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

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

States a specific verb and resource with scope: 'Collect the latest comments (up to 15) of an Instagram post or reel.' This is clearly distinguishable from sibling tools such as instagram_posts_create (posts) and tiktok_comments_create (other platform), and it names the accepted URL forms implicitly via the schema's /p/ or /reel/ restriction.

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

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

Gives explicit operational context: 'Returns job_id immediately; poll scrape_jobs_status for the result,' which tells the agent the tool is asynchronous and names the required follow-up sibling. It does not, however, state when this tool should be preferred over alternatives or any exclusions (e.g., private accounts), so it stops short of a full when/when-not rubric.

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?

The description adds real behavioral context beyond the annotations: the async job pattern (immediate job_id, poll for result), the points-billing model (5P per result, 10P base per job, effective date), and the reserve-then-deduct behavior. It does not address rate limits or auth requirements, so not a full 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 what the tool does, followed by the async workflow and then billing. The English/Korean duplication of the job_id/polling sentence adds some redundancy, but the ordering and content are efficient 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?

With no output schema, the description carries the return-value burden and does so: it tells the agent the response is a job_id to be resolved via scrape_jobs_status. Combined with billing and scope details, an agent has enough to call it correctly, though auth/rate-limit context is absent.

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

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

Schema description coverage is 100%, so the schema already documents url, username, max_results, and idempotency_key. The description's note that max_results is reserved and only actual results are deducted essentially restates the schema's own max_results description, adding little new semantic value.

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

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

States a specific verb and resource: 'Collect recent posts and reels of a public Instagram account (up to 100)'. The 'public' qualifier and the (up to 100) scope are concrete. It does not explicitly contrast with siblings like instagram_post or instagram_profile, so it falls just short of 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?

Gives clear workflow context: it returns a job_id immediately and the caller must poll scrape_jobs_status for the result, which is essential for invoking an async tool correctly. It does not name explicit alternatives or when-not conditions, so it is clear context rather than full 5-level 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?

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 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 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the lookup returns domain history, explicitly restricts input to IP address format, and states a per-call cost of 100 points. These details help the agent anticipate constraints and side effects without contradicting 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?

The description is compact and front-loaded with the core operation in English, followed by a Korean restatement, an input constraint, and cost. The bilingual redundancy is slightly unnecessary but does not bloat the entry; every part adds functional value.

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 lookup with no output schema, the description covers the operation, input constraint, cost, and expected result type (list of domains). It omits pagination or error behavior, but these are not critical for a simple lookup of this nature.

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 ip parameter already includes an example, so the baseline is 3. The description adds the explicit constraint that only IP address format is accepted, reinforcing input validation semantics 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 opens with a specific verb and resource: 'Reverse IP lookup: list domains that have been hosted on a given IP address.' It clearly distinguishes from siblings like nslookup and whois by focusing on reverse mapping from IP to domains, and the Korean line reinforces the historical domain registration aspect.

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

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

No guidance is given on when to use this tool versus alternatives such as ip_history, nslookup, or whois. The only usage-related statement is the input constraint 'IP 주소 형식만 허용됩니다' (only IP address format is allowed), which addresses validation rather than tool selection.

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 traits, so the bar is lower, and the description adds genuinely useful billing behavior: it settles the charge to the actual result count on completion and refunds the remaining reservation, and the lookup itself is free. That is real side-effect disclosure beyond the annotations. It stops short of describing job states or failure 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?

The content is front-loaded and the length is acceptable, but the English and Korean sentences are near-verbatim duplicates and '무료' is stated twice ('조회는 무료입니다. [무료]'). Roughly half the text is redundant restatement rather than new 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 carries the burden of explaining what 'status and results' look like, and it does not: no enumeration of job states (running/done/failed), no mention of partial results or polling cadence, and no failure/refund edge cases. The billing semantics are complete, but the return-shape guidance an agent needs is missing.

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

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

Schema description coverage is 100% and the single job_id parameter is already documented in the schema with its 32-char hex pattern. The description adds no format or sourcing detail beyond that, so the baseline 3 for schema-covered parameters is correct.

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 gives a specific verb+resource ('Get the status and results of a ... collection job') and names the covered platforms (Instagram, TikTok, Amazon, Google Maps). It is clearly the polling counterpart to the *_create siblings, but it never names or contrasts an actual sibling tool, so the 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?

Usage context is only implied: the job_id pattern and the settlement/refund language signal this is called after submitting a collection job. The '무료/[무료]' note adds a cost caveat, but there is no explicit when-to-use, when-not-to-use, or alternative (e.g., how to cancel or re-fetch) 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?

Adds substantial context beyond the annotations: asynchronous job pattern (job_id returned, poll scrape_jobs_status), a data limitation (commenters returned as public usernames only), and billing semantics (max_results reserved, only actual count charged, 5P per result with a 10P base from 2026-11-06). The annotations only flag openWorld/idempotent/non-destructive, so the description carries real additional value. Consistent with readOnlyHint=false (it creates a billed job) and idempotentHint=true.

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 async/polling instruction and pricing note are front-loaded and useful, but the Korean sentences restate the same facts already given in English ('접수 즉시 job_id 를 돌려주며 결과는 scrape_jobs_status 로 조회합니다' mirrors the English), so not every sentence earns its place. Bilingual framing may be intentional for a Korean-titled tool, but it is still duplicated 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 correctly explains the return path (immediate job_id, later polling via scrape_jobs_status) and the billing model, which is what an agent needs to call it correctly. It stops short of describing the shape of the final comment payload beyond 'public usernames only', a minor gap for a creation tool.

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

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

Schema description coverage is 100%, so url, max_results, and idempotency_key are already documented in the schema, and the description's mention of the reservation/charge behavior for max_results duplicates the schema text rather than extending it. Baseline 3 is appropriate; idempotency_key is not elaborated in the prose.

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

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

States a specific verb+resource: 'Collect comments of a TikTok video (up to 100)', and immediately disambiguates against the sibling it depends on by naming scrape_jobs_status for retrieval. The scope limit and the fact that only public usernames are returned are stated up front, so an agent can tell it apart from tiktok_search_create/tiktok_video_create without opening a schema.

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

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

Gives clear operational context: the tool returns a job_id immediately and the caller must poll scrape_jobs_status for the result, which is exactly the workflow an agent needs. It does not, however, state when NOT to use it (e.g. versus the Instagram/X comment siblings) or any platform prerequisites, so it stops short of explicit alternatives/exclusions.

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

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

Annotations already cover the safety profile (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?

Beyond the annotations (which already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses the async job_id return, the required polling step, and the point-cost model (5P per result, 10P base, reserving max_results). That billing and async behavior is genuinely additive context the 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?

Purpose is front-loaded, but the English and Korean sentences are near-verbatim duplicates (the job_id/polling statement appears twice), and the point-cost note appears only in Korean, so information is unevenly distributed. Efficient in intent but with redundant phrasing.

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 an async job-submission tool with no output schema, the description covers the essentials an agent needs: what it searches, that it returns a job_id, and where to retrieve results. It stops short of describing pagination, result limits per job, or error/partial-failure behavior.

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

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

Schema description coverage is 100%, so keyword, max_results, and idempotency_key are already documented in the schema. The description restates the reservation behavior ("max_results 만큼 예약하고 실제 결과 건수만 차감"), adding marginal value but no syntax or format detail beyond the schema. 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 ("Search TikTok videos by keyword or hashtag") plus scope ("up to 50") and the returned fields (views, likes, comments, shares). It also flags the create-job pattern and names the sibling to poll (scrape_jobs_status), so an agent can distinguish this from tiktok_profile and the *_create posting tools without opening a schema.

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

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

Explicitly tells the agent this is asynchronous and to "poll scrape_jobs_status for the result," which is real routing guidance. It does not, however, state when to prefer this over other search tools or any exclusion conditions, so it falls short of full when/when-not coverage.

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?

Adds materially beyond annotations: the asynchronous pattern (returns job_id immediately), the billing model (10P reserved at submission, refunded if not found, charged only when found), and it aligns with idempotentHint via the idempotency_key. It does not describe result shape or polling cadence, but annotations already cover safety/read-write profile.

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?

English content is well front-loaded and dense, but the entire passage is then duplicated in Korean, restating the same facts (job_id immediate, 10P billing/refund). That redundancy wastes space 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 an async job-creation tool with no output schema, it covers the essential lifecycle: submit here, poll scrape_jobs_status, billing semantics. It stops short of describing the eventual result payload, but with no output schema this is largely acceptable.

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 are documented in-schema (url format, idempotency_key pattern). The description adds no syntax or format 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 ('Get TikTok video details by URL') and enumerates the exact fields returned (views, likes, comments, shares, saves, description, hashtags, duration, author). An agent can distinguish it from siblings like tiktok_profile and tiktok_search_create without opening a schema.

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

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

Explicitly names the follow-up tool and condition ('poll scrape_jobs_status for the result') and gives the cost condition for use. However, it does not differentiate when to choose this over tiktok_profile or tiktok_search_create, which are the closest 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?

The readOnlyHint and openWorldHint annotations align with the described fetch behavior. The description adds useful context beyond annotations by disclosing JavaScript rendering support and a per-call cost, both of which help the agent anticipate 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?

The key purpose is front-loaded in English, and the Korean sentence repeats the same idea but is short. The JavaScript rendering and cost details are valuable. Minor redundancy prevents a higher 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 single-parameter, read-only tool with no output schema, the description covers what it does, what it returns, dynamic rendering behavior, and cost. It is sufficiently complete for an agent to invoke 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?

The single URL parameter is already fully documented in the schema with a description and example, so the description adds little beyond restating '입력한 URL.' With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the verb and resource: 'Fetch a web page and return its rendered HTML source.' It distinguishes itself from a screenshot tool by emphasizing HTML source rather than an image, though it does not explicitly name sibling tools.

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

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

The description implies a use case by noting that pages requiring JavaScript rendering are handled, but it does not explicitly state when to prefer this tool over alternatives like url_screenshot or provide any exclusions.

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

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

Annotations already declare readOnlyHint 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?

Annotations already declare readOnlyHint and openWorldHint, so this is clearly a safe read operation. The description adds useful non-annotated context: Korean resources are queried via KISA/KRNIC original data, and each call costs 100 points. No contradiction exists.

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 primary purpose. The bilingual repetition is somewhat redundant but understandable for a Korean-facing tool, and the cost note is compactly appended without disrupting clarity.

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 lookup with full schema coverage, the description covers the accepted input types, special Korean source behavior, output purpose, and cost. It does not detail output structure or error behavior, but that is not critical for invoking this 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?

The schema already documents the single 'address' parameter with 100% coverage and an example. The description adds extra meaning by noting that AS numbers, such as AS9318, are also accepted and that Korean .kr/.한국 domains and domestic IPs resolve through KISA/KRNIC.

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: 'WHOIS lookup for a domain or IP address, returning registration and ownership information.' This clearly distinguishes it from sibling tools like nslookup or reverse_ip, which serve different DNS/reverse-lookup 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 gives clear context about when to use the tool: for WHOIS registration and ownership data, including special support for Korean domains, domestic IPs, and AS numbers. It does not explicitly name alternatives or exclusion cases, but the intended use is obvious from the WHOIS-specific wording.

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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavior beyond them: the return value is a download link valid for exactly 1 hour, and pricing is a base fee plus per-10MB plus 20 points per call. It omits failure behavior (private/age-restricted videos), maximum size, and whether delivery is synchronous.

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 the cost/expiry facts earn their place, but the entire text is duplicated in Korean and English, roughly doubling token cost with zero new information for the agent. The trailing point-cost tag is useful but bolted on.

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-input, no-output-schema tool the description covers the essentials: input source, output form, link lifetime, and cost model. Missing pieces are edge-case behavior (private videos, size limits, async vs sync delivery) that a paid download tool would ideally state.

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 five parameters are already documented in the schema and the baseline is 3. The description restates format options and mentions the optional time range but says nothing about the bitrate parameter or its MP3-only constraint, so it adds no 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 gives a specific verb and resource ('Download only the audio of a public YouTube video as MP3, M4A or Opus') and the word 'only' implicitly separates it from the sibling download_youtube_video. It never names a sibling or contrasts itself explicitly, so an agent must still infer the boundary against download_youtube_video and video_to_mp3.

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 'public YouTube video' qualifier implies a usable scope (public sources, audio-only) and the time-range option implies partial extraction. However, there is no explicit when-to-use/when-not guidance and no routing advice versus download_youtube_video or video_to_mp3, which are the most likely confusions.

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 genuine behavioral trait by disclosing the per-call cost ('호출당 20포인트'), but says nothing about pagination, result caps beyond count, or response 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?

Purpose and returned fields are front-loaded in the first sentence. The Korean sentence is a near-verbatim translation, which doubles length without adding information, but the structure remains clear and scannable.

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

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

With no output schema, the description usefully enumerates the returned channel fields and the four tab types. The only notable gap is the absence of any statement about result pagination or how count interacts with the listed items.

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 the enum, count range, and the accepted channel formats (URL, @handle, UC... ID) all documented in the schema. The description only restates the tabs and returned fields, adding no syntax or format 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 ('look up') and resource ('YouTube channel') and enumerates the returned fields (name, handle, subscribers, description) plus the tab-listing capability. An agent can distinguish it from the many sibling search/download tools, though it never explicitly names an alternative for sibling routing.

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 what it does but never states when to use it versus alternatives like youtube_search, youtube_metadata, or youtube_playlist. No prerequisites, no exclusions, no indication that 'channel' must already be known.

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 genuine value beyond them: it restricts scope to PUBLIC videos, enumerates the response fields, and discloses a per-call cost ('호출당 30포인트'). It does not mention pagination limits or the reply-cap behavior, keeping 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 purpose is front-loaded in the first clause and the whole thing is three short segments. The Korean sentence restates the English one and the cost tag is appended, which is mild redundancy, but for a Korean-market toolset the bilingual phrasing is defensible rather than wasteful.

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 does so by listing the fields each comment includes plus the optional replies. All four parameters are covered by the schema and safety is covered by annotations. What remains thin is pagination/ordering behavior across large comment sets, which is not addressed.

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, sort, count and replies with defaults and ranges. The description only echoes the sort choices ('top or newest') and the optional replies, adding no syntax or format detail beyond the schema. Baseline 3 is correct.

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 gives a specific verb and resource: 'List comments of a public YouTube video', and even enumerates the returned fields (author, text, likes, pinned/hearted flags). The 'comments' resource is inherently distinct from all ~20 sibling youtube_* tools (search, metadata, channel, playlist, subtitle), so an agent can route to it correctly. It stops short of naming a sibling to avoid, so it lands 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 hints at the access constraint and the sort options are stated, but there is no explicit when-to-use/when-not guidance and no alternative named (e.g. youtube_metadata for video info, youtube_search for discovery). The purpose is self-evident enough that an agent can infer the trigger, which is the definition of a 3.

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 safe-read profile is covered. The description adds genuinely useful context by disclosing the billing cost ('호출당 10포인트') and that per-quality cost estimates are returned, but says nothing about rate limits, auth, or failure modes for private/unavailable videos.

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 front-loads what is listed and what is returned. The full Korean restatement and the bracketed point-cost note add bulk but serve a bilingual, cost-sensitive API audience, so the duplication is defensible rather than wasteful.

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 tool with no output schema, the description adequately enumerates the returned fields (resolution, fps, codec, size, audio formats, per-quality cost), so an agent knows what to expect. Minor gaps remain around pagination and error behavior for non-public videos.

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 in the schema (URL or 11-char video ID). The description adds only the 'public YouTube video' constraint, which is marginal value beyond the schema; 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 ('List') and a precisely enumerated resource (downloadable video qualities: resolution, fps, codec, size, audio formats, cost per quality) for a public YouTube video. This clearly separates it from download_youtube_video or youtube_audio_download, though it never names a sibling to make the contrast 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 when-to-use guidance and no mention of alternatives or prerequisites. The likely workflow (call this before download_youtube_video to choose a quality) is left entirely to inference, and the 'public' restriction is the only contextual hint.

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 fact, the 20-point-per-call cost, but says nothing about return format, pagination, or rate limits beyond the cost note.

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: the purpose sentence comes first, followed by the bilingual restatement and the cost marker. Nothing is wasteful, though the Korean translation duplicates the English sentence rather than 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 simple read-only listing tool with a complete input schema and annotation coverage, the description supplies what an agent needs, including the cost consideration. It is not required to explain return values since no output schema exists, but a brief note on result shape would have made it fully complete.

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

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

Schema description coverage is 100%, so both the hashtag format (optional #) and the count range/default are already fully documented in the schema. The description adds no parameter detail 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?

The description states a specific verb and resource ('List videos on a YouTube hashtag page'), which clearly scopes the tool to hashtag feeds rather than keyword search. It does not explicitly name the obvious sibling (youtube_search) to sharpen 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?

Usage is implied by the resource scope — an agent can infer this is for hashtag-based browsing — but there is no explicit when-to-use, when-not-to-use, or reference to alternatives like youtube_search or youtube_playlist. It relies on inference.

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 the safety profile is covered. The description adds two genuinely useful behavioral facts not in the structured fields: only public playlists are accessible, and each call costs 20 points. It still doesn't say anything about how the video list is ordered or truncated beyond the count cap.

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

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

Front-loaded and short: purpose first, then the returned fields, then cost. The only waste is the Korean sentence restating the identical English content verbatim, which adds length without new information for a non-Korean reader.

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

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

With no output schema, the description usefully enumerates what comes back (title, channel, video count, video list), and the annotations plus the cost/access notes cover the rest of what an agent needs. Minor gaps remain on result ordering and behavior for private or invalid playlist URLs.

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 both url and count fully documented in Korean including format examples and the 1-200 range with a default of 50. The description adds no parameter-level 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 (look up) and resource (public YouTube playlist) and even enumerates the returned fields (title, channel, video count, video list). It does not, however, explicitly distinguish itself from close siblings such as youtube_channel, youtube_metadata, or youtube_subtitle_list, so an agent must infer the boundary.

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

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

Usage is only implied: the word 'public' signals that non-public/unlisted playlists are out of scope, and the schema shows a playlist URL or ID is required. There is no explicit when-to-use statement and no named alternative for related lookups (e.g., youtube_channel for channel data).

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.