Server Quality Checklist

Tool Scores

• search_bookB
  3/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic search function and does not mention pagination, result limits, output format, required permissions, or any other behavioral traits. This is a significant gap for a search API.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that immediately identifies the tool's purpose. It is concise with no wasted words or redundancy.

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

  Completeness2/5

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

  Given the tool has four parameters, no annotations, and no output schema, the description is minimal. It does not explain the return value structure, the meaning of result ordering, or any usage constraints beyond what the schema lists. This leaves the agent without enough context to fully understand the tool's behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all four parameters already have meaningful descriptions. The tool description adds no additional parameter-level information beyond what the schema provides, placing it at the baseline for high-coverage schemas.

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

  Purpose5/5

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

  The description clearly states the tool performs a 'Naver book search' and lists the specific fields it searches (book info, author, ISBN, publisher). This distinguishes it from sibling tools like search_news or search_shop, which target different content types.

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

  Usage Guidelines2/5

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

  No explicit guidance is given on when to use this tool versus alternatives. While the name 'search_book' implies book-related queries, there is no mention of when not to use it or what other tool might be more appropriate for non-book searches.

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

• datalab_shopping_keyword_by_ageB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool analyzes but does not disclose how the results are presented, what age groups are included, aggregation behavior, or any limitations. The description adds little beyond the tool's name.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the main purpose. There is no repetition or unnecessary detail.

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

  Completeness2/5

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

  For a tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the output format, expected input ranges, or how the analysis is scoped. It provides only a high-level statement, leaving significant gaps for an agent to use the tool correctly.

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

  Parameters2/5

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

  The schema covers only 57% of parameters, so the description needs to compensate, but it does not. It adds no explanation for device, gender, timeUnit, category, or keyword beyond what the schema already states. The description's phrase 'specific category keyword' is vague and does not clarify parameter usage.

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

  Purpose5/5

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

  The description clearly states the tool analyzes click ratios by age group for a specific category keyword, with a specific verb ('analyzes') and resource ('shopping keyword click ratio'). The age-specific scope distinguishes it from sibling tools like datalab_shopping_keyword_by_gender and datalab_shopping_keyword_by_device.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention that this tool is for age breakdowns as opposed to gender/device breakdowns, nor any prerequisites or scenarios where it should be preferred.

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

• datalab_shopping_categoryB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states that it 'analyzes click volume trends' without disclosing behavioral aspects such as maximum category count (3), date range constraints, or output format. This is a significant gap for a data analysis tool.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the core purpose and adds a brief use-case note. No redundant words or repetition of schema details.

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

  Completeness2/5

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

  For a tool with 7 parameters and no output schema, the description is too sparse. It does not explain return values, data granularity, category limits, or how to interpret results. The description is insufficient for a complex analytical tool.

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

  Parameters3/5

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

  Schema description coverage is 100% (all 7 parameters have descriptions), so the description adds no extra parameter meaning. Baseline 3 applies as the schema already documents parameters well.

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

  Purpose4/5

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

  The description clearly states it analyzes Naver Shopping category click volume trends ('카테고리별 클릭량 추이를 분석합니다') and mentions use cases ('시장 규모 파악 및 카테고리 비교'). It distinguishes from sibling keyword-focused tools by explicitly focusing on categories, though it does not name alternative tools.

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

  Usage Guidelines4/5

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

  The description provides clear use cases (market size understanding and category comparison) that imply when to use this tool, but it does not give explicit exclusions or mention alternative tools like keyword trend tools.

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

• datalab_shopping_keyword_by_deviceB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the analysis intent, but fails to disclose return format, read-only nature, limitations, or any effects. This is a significant gap for a tool with no output schema.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the core purpose. No wasted words or redundant information.

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

  Completeness2/5

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

  The tool has 6 parameters and no output schema, yet the description provides no information about return values, example usage, or constraints. The description is too minimal to fully prepare an agent for invocation.

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

  Parameters3/5

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

  Schema description coverage is 67%, with startDate, endDate, keyword, and category described. The description adds no additional parameter semantics beyond the schema, and timeUnit/gender remain unexplained. The coverage is moderate, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool analyzes Naver shopping keyword click ratios by device (PC vs mobile), using specific category keywords. This verb+resource+scope distinguishes it from sibling tools like datalab_shopping_keyword_by_age and by_gender.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when analyzing device-specific click distribution for shopping keywords, but it does not explicitly state when to use it over alternatives or provide exclusions. The context is clear from the purpose, but no explicit alternatives are mentioned.

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

• search_blogB
  3.4/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states what is searched and does not mention read-only nature, pagination limits, result format, error behavior, or any constraints.

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

  Conciseness5/5

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

  The description is a single, concise sentence in Korean with the key action and resource front-loaded. It contains no redundant or filler information, earning high marks for efficiency.

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

  Completeness2/5

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

  The tool has no output schema and no annotations, and the description provides only the bare purpose. It lacks information about return value structure, pagination behavior, or any usage caveats, leaving the agent with an incomplete picture for successful invocation.

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

  Parameters3/5

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

  The input schema already provides descriptions for all four parameters (100% coverage), and the description adds no extra meaning about sort, start, display, or query semantics. This meets the baseline but does not enhance understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly identifies the tool as a Naver blog search ('네이버 블로그 검색') with a specific content focus (real reviews, personal experiences, tutorials). This verb+resource formulation distinguishes it from sibling tools like search_news or search_cafearticle.

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

  Usage Guidelines3/5

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

  The description implies usage for finding blog posts in Naver, but provides no explicit when-to-use guidance, exclusions, or alternative tool mentions. The intended use case is only inferred from the resource and content description.

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

• search_newsB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, and the description only states the basic search function. It does not disclose behavioral traits such as result format, pagination behavior, sorting defaults, rate limits, or authentication requirements. For a search tool with no annotation support, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the tool name and purpose. There is no redundant or filler content; it is efficient and to the point.

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

  Completeness2/5

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

  For a tool with no output schema and a simple search function, the description does not explain return values or how output is structured. It also does not mention how to use pagination parameters (start, display) effectively. This leaves significant contextual gaps for an agent selecting and invoking the tool.

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

  Parameters3/5

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

  The input schema provides 100% coverage of all four parameters, including complete descriptions and an enum for sort. The description itself adds no additional parameter semantics, but given the thorough schema, no further detail is necessary.

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

  Purpose5/5

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

  The description clearly identifies the tool as a Naver News search, using the specific verb '검색' and resource '네이버 뉴스', and explicitly defines the content domain (latest news, current issues, policy changes). This distinguishes it from sibling search tools such as search_blog and search_shop.

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

  Usage Guidelines3/5

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

  The description implies usage context—when you need news-related search results—but it does not explicitly contrast with alternatives like search_blog or search_cafearticle, nor does it state when not to use this tool. The guidance is based primarily on the tool's name and domain.

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

• search_errataA
  3.5/5.0
  Behavior3/5

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

  The description discloses the return value ('errata' - corrected search term), which is useful behavioral information. However, since no annotations are present, it is the sole source of transparency. It does not cover edge cases (e.g., no typo found), error behavior, or explicitly state that the operation is read-only, leaving some behavioral gaps.

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

  Conciseness5/5

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

  The description is exceptionally concise and front-loaded. It states the core function in the first phrase and follows with the return value. Every word serves a purpose with no redundancy or unnecessary detail.

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

  Completeness3/5

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

  For a simple tool with one parameter and no output schema, the description provides the basic purpose and return value. However, it misses usage context (e.g., use it as a preprocessing step for search tools) and behavioral details like behavior for well-formed queries. It is adequate but not fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the 'query' parameter already described as '교정할 검색어' (search term to correct). The description reinforces this meaning but does not add additional constraints, examples, or syntax guidance beyond what the schema provides, so it meets the baseline without adding extra value.

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

  Purpose5/5

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

  The description explicitly states the tool corrects typos in search terms ('오타 교정 — 검색어의 오타를 교정합니다'). The verb and resource are clear, and it is distinctly different from sibling search tools which execute searches rather than correct input.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool compared to alternatives. It does not mention that it should be used before other search tools to fix user typos, nor does it exclude any context. The description lacks explicit contingency and alternative references.

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

• search_imageA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output format (returns image URL, thumbnail, source), which is useful, but does not mention any limitations, permissions, rate limits, or side effects. For a non-destructive search tool, this is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the tool's purpose and output without any waste. Every word earns its place.

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

  Completeness3/5

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

  Given the tool has 5 parameters and no output schema, the description provides essential return information (URL, thumbnail, source) but lacks details on pagination, default sorting, or result structure. This is a reasonable but not fully comprehensive description for a search tool.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptions for all 5 parameters, including enums for sort and filter. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states '네이버 이미지 검색' (Naver image search) and specifies the return fields (image URL, thumbnail, source), distinguishing it from sibling search tools for web, blog, news, etc. The verb '검색' (search) is specific and the resource is unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternative search tools (e.g., search_webkr, search_blog). It simply describes the action without context, exclusions, or preferred use cases.

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

• search_kinA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'searches' and gives no information about output format, pagination behavior beyond what schema parameters imply, or any access/auth requirements. The lack of any behavioral context makes this a minimal disclosure.

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

  Conciseness5/5

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

  The description is a single, focused sentence that immediately communicates the tool's purpose. It is concise with no filler words, and the Korean phrasing is natural and front-loaded with the service name.

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

  Completeness3/5

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

  For a search tool with a well-documented schema, the description is adequate but minimal. It does not explain return value structure or pagination details beyond the schema's parameter descriptions, and there is no output schema to compensate. The description is complete enough for basic invocation but lacks richer context expected for a search tool with many siblings.

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

  Parameters3/5

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

  The schema description coverage is 100%, with each parameter clearly described (query as '검색어', sort with enum values, start position, display count). The description itself adds no additional parameter meaning beyond what the schema already 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.

  Purpose5/5

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

  The description clearly states the tool searches Naver Knowledge iN (지식iN) for Q&A-style professional answers and life information, using a specific verb 'searches' and a distinct resource that differentiates it from sibling search tools like search_blog or search_news.

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

  Usage Guidelines3/5

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

  While the description implies usage for finding Q&A content on Naver Knowledge iN, it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The context is clear enough for a basic search scenario but lacks explicit guidance on 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.

• datalab_shopping_keyword_by_genderA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the tool analyzes gender click ratios but gives no additional behavioral information such as return format, required permissions, or data limitations. This is a minimal restatement of purpose with no extra transparency.

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

  Conciseness5/5

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

  The description is a single, focused sentence in Korean, front-loading the tool's purpose without wasting words. It earns its place with specific terminology.

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

  Completeness2/5

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

  Without an output schema, the description should clarify what results the agent will receive, such as percentage breakdowns or time series. It only states the analysis goal, leaving the response structure unspecified. This is insufficient for a tool with six parameters and no output schema.

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

  Parameters3/5

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

  Schema descriptions cover 67% of parameters (startDate, endDate, keyword, category) with enums for timeUnit and device. The description adds context that the keyword is for a specific category and that the analysis is gender-based, but does not explain individual parameters beyond the schema. It adds moderate value but doesn't compensate fully for the missing timeUnit/device descriptions.

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

  Purpose5/5

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

  The description clearly states the tool analyzes Naver shopping keyword gender click ratios, using the Korean verb '분석합니다' (analyzes). It distinguishes from sibling tools by specifying '성별' (gender), differentiating it from age/device variants.

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

  Usage Guidelines4/5

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

  The description provides clear context that this is for gender-specific analysis but does not explicitly name alternative tools or state when not to use it. It implies the use case (comparing male vs. female clicks) but lacks exclusionary guidance.

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

• search_encycA
  3.6/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It only states the search action without disclosing result format, pagination behavior, or any limitations. The read-only nature is implied but not explicitly disclosed.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no redundant information, effectively conveying the tool's purpose.

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

  Completeness2/5

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

  Given the lack of output schema and annotations, the description should explain return values or behavioral details. It only states what is searched, leaving the expected result structure and pagination behavior unspecified.

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

  Parameters3/5

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

  Schema covers all parameters with descriptions (100%), so baseline is 3. The description adds that the query targets concepts/terms/people, giving semantic context for the 'query' parameter, but does not enhance understanding of 'start' or 'display'.

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

  Purpose5/5

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

  The description clearly states the tool searches Naver encyclopedia and specifies the content types (concepts, terms, people), which differentiates it from sibling search tools like search_blog or search_news.

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

  Usage Guidelines4/5

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

  The content specification provides clear context for when to use this tool (encyclopedia lookups) versus other search tools, though it does not explicitly mention alternatives or exclusions.

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

• search_localA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It states the return fields (address, phone, category), but does not mention that this is a read-only search, any rate limits, or pagination behavior (such as start/display constraints). It omits details like default sort behavior or the fact that results may be limited, leaving the agent without critical context for safety and expectations.

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

  Conciseness5/5

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

  The description is a single clear sentence with no redundant wording. It front-loads the tool's purpose ('네이버 지역 검색') and includes the essential output information, making it efficient and well-structured.

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

  Completeness4/5

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

  Despite the lack of annotations and output schema, the description provides key return information (address, phone, category) and clearly defines the search scope. Combined with a complete input schema, it gives sufficient context for an agent to invoke the tool correctly, though it could be enhanced with pagination or sort behavior details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add any additional explanation of parameters beyond what is already in the schema; it merely mentions output fields. Since it adds no extra semantics to the parameters, the baseline score is appropriate.

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

  Purpose5/5

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

  The description clearly states it performs Naver local search for places like restaurants, shops, and hospitals, explicitly bound to the '지역 검색' (local search) scope. This distinguishes it from sibling tools like search_blog, search_news, etc., by specifying the resource type (places) and return fields (address, phone, category).

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

  Usage Guidelines3/5

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

  Usage is implied by the local search description and the mention of place types, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The description does not reference sibling tools or provide decision rules, so it only hints at its niche.

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

• search_webkrA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions content scope but not behaviors like pagination limits, result formatting, or any side effects. For a search tool, the read-only nature is obvious, but other behavioral traits are undisclosed.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently states the tool's purpose and content scope. No filler or redundancy.

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

  Completeness4/5

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

  For a simple search tool with a concise schema, the description adequately covers purpose and scope. It lacks sibling differentiation and usage guidance, but these are partially accounted for by visible sibling names. Overall, it is sufficiently complete for a low-complexity tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters (query, start, display) are documented in the schema. The description does not add additional parameter-level context beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool performs web document searches using Naver, specifying content types (official sites, references, web pages). This distinguishes it from sibling tools that target specific content types like blogs, news, or shops.

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

  Usage Guidelines3/5

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

  Usage context is implied by the description (general web search), but there is no explicit guidance on when to prefer this tool over siblings or any exclusions. For a tool among many sibling search variants, this is a gap.

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

• datalab_shopping_keywordsA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the basic comparison of trends and does not disclose additional behaviors such as data source restrictions, rate limits, or the fact that the output is a time series. Without annotations, this is a significant gap.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the tool name and a dash-separated summary. Every sentence adds value: the first explains the core function, the second adds a use case. No redundancy.

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

  Completeness3/5

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

  For a tool with 8 parameters, no output schema, and no annotations, the description provides the core purpose and a use case but lacks guidance on how it relates to the sibling datalab_shopping_keyword_by_age/by_gender/by_device tools. It also does not explicitly state the return format (e.g., a time series), leaving the agent to infer from the word 'trend'.

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

  Parameters3/5

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

  Schema descriptions cover 63% of parameters (startDate, endDate, timeUnit, category, and keyword are described; ages, device, and gender are not). The description adds context for category and keyword ('within a specific category' and 'by keyword') but does not explain the optional filter parameters or the keyword group structure, which is only present in the schema.

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

  Purpose5/5

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

  The description states it 'compares click volume trends by keyword within a specific category' (특정 카테고리 내 키워드별 클릭량 추이를 비교합니다). This clearly identifies the verb (compare), resource (keyword click volume trends), and scope (within category), distinguishing it from sibling tools like datalab_shopping_category, datalab_shopping_keyword_by_age, etc.

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

  Usage Guidelines4/5

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

  The description says it is 'useful for competitive keyword analysis' (경쟁 키워드 분석에 유용합니다), providing a clear use case. However, it does not explicitly state when not to use it or mention alternatives among the closely related sibling datalab_shopping_keyword_by_* tools.

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

• search_cafearticleA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states that it searches posts, without disclosing behavior like sorting, pagination, rate limits, auth requirements, or return format. This is a significant gap for a search tool.

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

  Conciseness5/5

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

  A single, front-loaded sentence that directly states the tool's purpose. There is no wasted text or redundancy.

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

  Completeness3/5

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

  Given the simple search tool and complete parameter schema, the description is adequate but lacks behavioral context such as response structure or pagination behavior. It is acceptable for basic use but could be more informative.

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

  Parameters3/5

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

  The input schema provides 100% coverage for all four parameters, including enums for sort. The description adds no extra parameter semantics beyond what is already documented, so the baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool searches Naver Cafe posts and specifies the content types (community opinions, experiences, club info). This distinguishes it from sibling search tools like search_blog and search_news.

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

  Usage Guidelines4/5

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

  It implies use for community/cafe content, which helps differentiate from alternatives. However, it does not explicitly say when not to use it or name alternative tools, so the guidance is implicit rather than explicit.

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

• datalab_searchA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It mentions 'relative search volume changes' (상대적 검색량 변화), which is a key behavioral trait, but does not describe the output format, rate limits, authentication requirements, or limitations like date range constraints. It provides minimal but relevant context 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.

  Conciseness5/5

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

  The description is two sentences, front-loading the core function and immediately giving use cases. Every clause adds value; there is no redundancy, fluff, or repetition of schema information. It is concise yet informative.

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

  Completeness3/5

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

  The tool has a moderate complexity (7 params, nested keywordGroups) and no output schema, so the description should explain return values more explicitly. It mentions analyzing changes but doesn't describe the response format (e.g., time series data) or operational constraints like max keyword groups. However, the schema covers parameters comprehensively, and the use case hint adds context.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed descriptions for every parameter (e.g., dates, timeUnit, keywordGroups). The description adds general context but no specific parameter-level details beyond what the schema already provides. The baseline of 3 applies since the schema fully documents parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: analyzing relative search volume changes by keyword group ('키워드 그룹별 상대적 검색량 변화를 분석합니다'). This specific verb+resource combination distinguishes it from sibling tools like search_* (which search documents) and datalab_shopping_* (which focus on shopping data).

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

  Usage Guidelines4/5

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

  The description gives practical use cases ('마케팅 시즌 파악, 트렌드 비교에 유용합니다') indicating when to use it. It does not explicitly mention alternatives or exclusions, but the sibling tools are functionally distinct enough to imply appropriate usage contexts.

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

• search_adultA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It explicitly discloses the return value semantics ('adult: 0 normal, 1 adult') and the classification scope. It does not mention error handling, but for a simple classifier this is acceptable and adds value 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.

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the main purpose and includes the return format. No wasted words; every element contributes meaningful information.

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

  Completeness4/5

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

  The tool is simple with one required parameter and no output schema. The description adequately explains the return value and classification intent. It lacks explicit usage context, but the purpose is clear enough for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% — the only parameter 'query' is described as '판별할 검색어' (the search term to classify). The description adds no extra parameter semantics 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.

  Purpose5/5

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

  The description uses a specific verb '판별' (classify/discriminate) with a clear resource '성인 검색어' (adult search term), and states the binary outcome (0: general, 1: adult). This clearly distinguishes it from sibling search tools that return content.

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

  Usage Guidelines3/5

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

  The description implies the tool is for classifying adult content but does not explicitly state when to use it compared to alternatives like search_webkr or search_blog. The purpose is self-evident but no when-to-use or when-not-to-use guidance is provided.

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

• search_docA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the burden of behavioral disclosure. It simply states the search function, which is self-evident and non-destructive. It does not add any extra context about rate limits, result limits, or authentication requirements, but for a read-only search tool, the basic behavior is transparent enough.

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

  Conciseness5/5

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

  The description is a single, concise sentence that immediately conveys the tool's purpose. It has no filler or redundant information.

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

  Completeness4/5

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

  This is a simple search tool with a rich schema (100% coverage) and no output schema. The description adequately identifies the content domain, which is sufficient for an agent to decide when to invoke the tool. A slight deduction for not mentioning any search-specific nuances, but overall it is complete for its complexity.

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

  Parameters3/5

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

  The schema covers 100% of parameters with descriptions (query, sort, start, display). The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb (검색합니다/searches) and resource (전문자료/professional documents) with specific types (학술자료, 논문, 공문서). This distinguishes it from sibling search tools like search_blog or search_news.

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

  Usage Guidelines4/5

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

  The description provides clear context on what content is covered (academic materials, papers, public documents), making it obvious when to use this tool. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.

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

• search_shopA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions key return fields (lprice, hprice, mallName), which gives useful output context. However, it does not explicitly state that this is a safe read-only operation, nor does it mention rate limits, authentication, or error behavior. For a search API, these omissions are notable but not fatal.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the purpose and includes the key return fields. Every part contributes value, with no redundancy or filler. It is optimally sized for a straightforward search tool.

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

  Completeness4/5

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

  The description, combined with the fully documented schema, covers the essential aspects: purpose, use cases, and return fields. Since there is no output schema, mentioning lprice, hprice, and mallName helps fill that gap. However, it does not mention pagination behavior or API-specific constraints beyond what the schema provides, which is a minor gap.

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

  Parameters3/5

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

  The input schema covers all four parameters with descriptions, achieving 100% schema coverage. The tool description does not add any extra parameter semantics beyond what the schema already provides. Since the schema handles parameter documentation fully, the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description explicitly states '네이버 쇼핑 검색' (Naver Shopping search) and lists concrete use cases: product info, price comparison, market price. This clearly differentiates it from sibling search tools like search_blog or search_news. The verb '검색' plus the specific resource '쇼핑' make the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool ('상품 정보, 가격 비교, 시세 파악에 사용합니다') and implies its niche among the sibling search tools. However, it does not explicitly mention alternatives or when not to use it, which would merit a 5.

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