Server Quality Checklist

Tool Scores

• search_localC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions display/page limits and sort options, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what the output contains. For a search tool with zero annotation coverage, this is inadequate.

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

  Conciseness3/5

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

  The description is brief but poorly structured: the parenthetical note about display/page is awkwardly placed and unclear. It's front-loaded with the core purpose, but the additional details are cryptic and could be better organized for clarity.

  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 an output schema (which handles return values), the description's gaps in parameter semantics and behavioral transparency are partially mitigated. However, for a search tool with 4 parameters and no annotations, it should provide more context on usage and limitations to be fully complete.

  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?

  Schema description coverage is 0%, so the description must compensate but adds limited value. It explains that 'sort' supports 'random'/'comment', which isn't in the schema, but doesn't clarify 'query' semantics, 'display'/'page' constraints beyond maxima, or parameter interactions. With 4 parameters and poor coverage, this is insufficient.

  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 the verb ('searches for') and resource ('local business information'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'search_shop' or 'search_cafe_article', which might have overlapping domains, so it misses the highest score.

  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 alternatives like search_shop or search_cafe_article. It mentions technical constraints (display maximum 5, start maximum 1) but doesn't explain the context or scenarios for choosing this tool over others.

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

• search_webkrC
  2.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 full burden. It mentions 'page navigation' which hints at pagination behavior, but doesn't disclose other important traits like rate limits, authentication needs, what 'web documents' includes (e.g., HTML pages, PDFs), or the search scope. For a search tool with no annotation coverage, this leaves significant 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.

  Conciseness4/5

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

  Two sentences that are reasonably efficient. The first sentence states the core purpose, and the second adds parameter context. While it could be more front-loaded with key details, there's minimal waste, and each sentence adds value.

  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 an output schema (which reduces need to describe return values) but no annotations and 3 parameters with 0% schema coverage, the description is moderately complete. It covers the basic purpose and hints at pagination, but lacks details on search behavior, result format, or differentiation from siblings, leaving room for improvement.

  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 0%, so the description must compensate. It adds meaning for the 'page' parameter ('allows for page navigation'), but doesn't explain 'query' (beyond 'given keyword') or 'display' at all. With 3 parameters and poor schema coverage, the description provides only partial semantic context, meeting the baseline for minimal compensation.

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

  Purpose3/5

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

  The description states 'Searches for web documents using the given keyword' which provides a clear verb ('searches') and resource ('web documents'), but it doesn't distinguish this tool from its many siblings (e.g., search_blog, search_news, search_image) that also search different types of content. The purpose is understandable but lacks differentiation from similar tools.

  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 alternatives like search_blog or search_news. It mentions page navigation but doesn't explain when this tool is appropriate compared to other search tools in the sibling list. There's no context about use cases or exclusions.

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

• search_bookC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions page navigation but doesn't cover rate limits, authentication needs, error handling, or what the search returns beyond 'book information'. This is inadequate for a search tool with 4 parameters.

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

  Conciseness4/5

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

  The description is appropriately brief with two sentences. The first sentence states the core purpose, and the second adds parameter context. However, the second sentence could be more informative about other parameters.

  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's moderate complexity (4 parameters, no annotations, but has output schema), the description is minimally adequate. The output schema reduces the need to describe return values, but the description lacks crucial context about search scope, limitations, and parameter semantics.

  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?

  Schema description coverage is 0%, so the description must compensate but only adds meaning for the 'page' parameter. It doesn't explain 'query' (search keyword), 'display' (results per page), or 'sort' (ordering criteria), leaving 3 of 4 parameters semantically unclear.

  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 the action ('searches for book information') and target resource ('on Naver'), distinguishing it from siblings like search_blog or search_news. However, it doesn't explicitly differentiate from search_webkr or other search tools, keeping it 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.

  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 alternatives like search_webkr or search_doc. It mentions page navigation but offers no context about appropriate use cases or exclusions.

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

• correct_errataC
  2.9/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 states the tool 'converts' errors, implying a transformation or correction action, but doesn't specify whether this is a read-only operation, if it requires authentication, rate limits, or what the output entails. The description lacks details on behavioral traits beyond the basic purpose.

  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 extremely concise and front-loaded: 'Converts Korean/English keyboard input errors.' It's a single sentence that directly states the purpose without any waste, making it efficient and easy to parse. 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's complexity (a conversion tool with 1 parameter) and the presence of an output schema (which should cover return values), the description is minimally complete. It states what the tool does but lacks details on usage, parameters, and behavior. With no annotations and low schema coverage, it's adequate but has clear gaps, meeting the baseline for a simple tool.

  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 input schema has 1 parameter ('query') with 0% description coverage, meaning the schema provides no details about this parameter. The description does not add any meaning beyond the schema; it doesn't explain what 'query' should contain (e.g., text with keyboard errors) or its format. With low schema coverage, the description fails to compensate, leaving the parameter poorly defined.

  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 the tool's purpose: 'Converts Korean/English keyboard input errors.' It specifies the action ('converts') and the resource/scope ('Korean/English keyboard input errors'), making the function understandable. However, it doesn't differentiate from sibling tools, which are all search-related (e.g., search_blog, search_news), so it's not a perfect 5.

  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 alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, such as when input errors are suspected or how it compares to other tools. This leaves the agent with minimal direction.

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

• search_blogC
  2.9/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 mentions pagination via the page parameter but doesn't disclose other behavioral traits such as rate limits, authentication needs, result format, or error handling. For a search tool with zero annotation coverage, 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.

  Conciseness4/5

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

  The description is concise with two sentences, front-loading the main purpose. However, the second sentence about page navigation could be integrated more smoothly, and there's room to add critical details without sacrificing brevity.

  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 complexity of a search tool with 4 parameters, no annotations, and an output schema (which reduces the need to describe return values), the description is incomplete. It lacks details on parameter usage, behavioral context, and differentiation from siblings, making it minimally adequate but with clear gaps.

  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 0%, so the description must compensate. It explains the page parameter for navigation but doesn't cover query, display, or sort parameters. The description adds minimal value beyond the schema, failing to fully address the coverage gap, resulting in a baseline score.

  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 the action ('searches for blogs') and the target resource ('on Naver'), distinguishing it from sibling tools like search_news or search_image. However, it doesn't explicitly differentiate from other search tools like search_webkr or search_local, which might also use keywords.

  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 alternatives like search_news or search_webkr. It mentions page navigation but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

• search_cafe_articleC
  2.9/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 mentions page navigation and sort options, which adds some context, but fails to cover critical aspects like rate limits, authentication needs, pagination behavior, error handling, or what the output contains. For a search tool with 4 parameters, this leaves significant gaps in understanding how it behaves.

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

  Conciseness4/5

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

  The description is appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds parameter context. There's minimal waste, though it could be slightly more structured (e.g., bullet points for parameters). It earns its place by conveying essential information efficiently.

  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's moderate complexity (4 parameters, no annotations, but has an output schema), the description is partially complete. It covers the basic purpose and some parameter semantics, but gaps remain in usage guidelines, behavioral transparency, and full parameter documentation. The output schema existence means return values don't need explanation, but overall it's adequate with clear room for improvement.

  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 description adds meaning for 'page' (navigation) and 'sort' (supported values 'sim'/'date'), which helps interpret these parameters beyond their schema titles. However, with 0% schema description coverage and 4 parameters total, it doesn't fully compensate: 'query' and 'display' are left unexplained, and it lacks details like format constraints or default behaviors. The baseline is 3 due to partial compensation.

  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 the action ('Searches for cafe articles') and resource ('on Naver'), making the purpose immediately understandable. It distinguishes from siblings by specifying 'cafe articles' rather than other content types like blogs, news, or images. However, it doesn't explicitly contrast with similar tools like search_blog or search_webkr beyond the resource type.

  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 alternatives. It mentions 'sort' options but doesn't explain when to choose 'sim' (likely similarity) versus 'date', nor does it compare to sibling tools like search_blog or search_news for different content types. Usage is implied by the keyword search functionality but lacks explicit context or exclusions.

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

• search_docC
  2.9/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 mentions 'page navigation' for pagination, which adds some behavioral context, but fails to disclose critical traits like whether this is a read-only operation, rate limits, authentication needs, or what the search returns (though an output schema exists). For a search tool with zero annotation coverage, this is inadequate.

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

  Conciseness4/5

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

  The description is concise with two sentences that are front-loaded: the first states the core purpose, and the second adds pagination context. There is no wasted text, but it could be slightly more structured by explicitly listing parameters or usage scenarios.

  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's moderate complexity (3 parameters, no annotations, but with an output schema), the description is minimally complete. It covers the basic purpose and pagination, but lacks details on search scope, result format, or error handling. The presence of an output schema mitigates the need to explain return values, but more context on behavior and parameters is needed for full adequacy.

  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 0%, so the schema provides no parameter descriptions. The description adds minimal semantics: it explains that 'page parameter allows for page navigation,' giving context for the 'page' parameter. However, it does not cover 'query' or 'display' parameters, leaving two of three parameters without semantic explanation. This partial compensation results in a baseline score.

  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 the tool's purpose: 'Searches for academic papers, reports, etc. using the given keyword.' It specifies the verb ('searches'), resource ('academic papers, reports, etc.'), and scope ('using the given keyword'). However, it does not explicitly differentiate from sibling tools like search_blog or search_book, which lowers it from a 5.

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

  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 alternatives. It mentions 'page navigation' for pagination but does not specify contexts, exclusions, or comparisons to sibling tools such as search_blog or search_news, leaving the agent with no usage direction.

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

• search_encyclopediaC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only mentions page navigation. It lacks critical behavioral details such as rate limits, authentication needs, result format, or whether it's read-only. This leaves significant gaps in understanding how the tool behaves beyond basic functionality.

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

  Conciseness4/5

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

  The description is concise with two sentences, front-loading the main purpose. However, the second sentence about page navigation could be integrated more smoothly, and it lacks efficiency by not covering other parameters or usage context.

  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 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It doesn't explain parameter meanings or behavioral traits, though the output schema may cover return values. This results in a minimally adequate but gap-filled description.

  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 0%, so the description must compensate. It only explains the 'page' parameter ('allows for page navigation'), ignoring 'query', 'display', and 'sort'. This adds minimal value beyond the schema, failing to fully address the coverage gap, warranting a baseline score.

  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 the action ('Searches for encyclopedia information') and the target resource ('on Naver'), distinguishing it from siblings like search_blog or search_news. However, it doesn't specify the exact scope of 'encyclopedia information' (e.g., entries, articles) or differentiate from similar tools like search_doc, which slightly reduces specificity.

  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 alternatives like search_webkr or search_kin. It mentions page navigation but doesn't explain when to use this tool over other search tools, leaving the agent without context for selection among siblings.

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

• search_imageC
  2.9/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 mentions pagination and sorting/filtering options, which adds some context, but fails to cover critical aspects like rate limits, authentication needs, error handling, or what the search results entail (e.g., format, source). For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness4/5

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

  The description is appropriately sized with two sentences that are front-loaded (starting with the core purpose) and avoid unnecessary fluff. Each sentence adds useful information about functionality and parameters, making it efficient, though it could be slightly more structured for clarity.

  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's moderate complexity (5 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and some parameter details, but lacks usage guidelines and full behavioral context. The presence of an output schema mitigates the need to explain return values, but overall, it's adequate with clear gaps 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?

  Schema description coverage is 0%, so the description must compensate. It adds value by explaining that 'page' allows for navigation and listing valid values for 'sort' and 'filter' (e.g., sort='sim'/'date', filter='all'/'large'/'medium'/'small'), which clarifies beyond the bare schema. However, it doesn't cover 'query' or 'display' parameters, leaving 2 of 5 parameters without semantic context, resulting in partial compensation.

  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 the tool's purpose as 'Searches for images using the given keyword,' which is a specific verb+resource combination. It distinguishes from most siblings (e.g., search_blog, search_news) by specifying 'images,' though it doesn't explicitly differentiate from all possible image-related tools that might exist elsewhere.

  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 alternatives. It mentions parameters like sort and filter but doesn't indicate scenarios where this tool is preferred over other search tools (e.g., search_webkr for web content) or when not to use it, leaving the agent without contextual usage cues.

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

• search_kinC
  2.9/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 mentions that the tool supports page navigation and sort options ('sim'/'date'/'point'), which adds some context about functionality. However, it doesn't cover critical aspects like rate limits, authentication needs, error handling, or what the output contains (though an output schema exists). For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness4/5

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

  The description is concise and well-structured in two sentences. The first sentence states the core purpose, and the second adds important parameter details. There's no wasted language, and it's front-loaded with the main functionality.

  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's moderate complexity (4 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and some parameter semantics, but lacks usage guidelines and full behavioral transparency. The existence of an output schema means the description doesn't need to explain return values, but other gaps remain for a search tool with multiple 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?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds some semantic value by explaining that 'page parameter allows for page navigation' and 'sort='sim'/'date'/'point' is supported,' which clarifies the purpose of two parameters (page and sort). However, it doesn't explain the 'query' parameter beyond 'given keyword' or the 'display' parameter at all, leaving half the parameters with minimal context.

  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 the tool's purpose: 'Searches for knowledgeiN Q&A on Naver using the given keyword.' It specifies the verb ('Searches'), resource ('knowledgeiN Q&A on Naver'), and mechanism ('using the given keyword'). However, it doesn't explicitly differentiate from sibling tools like search_blog or search_news, which likely search different content types on the same platform.

  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 alternatives. It mentions 'page navigation' and 'sort' options but doesn't explain when to choose this tool over other search siblings (e.g., search_blog for blog posts, search_news for news articles). There's no mention of prerequisites, typical use cases, or exclusions.

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

• search_newsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose rate limits, authentication needs, error handling, or response format (though an output schema exists). The mention of sort and page parameters adds some context but is insufficient for a mutation-like search operation.

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

  Conciseness4/5

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

  The description is brief and front-loaded with the core purpose. Both sentences add value: the first defines the tool, and the second clarifies parameter usage. No wasted words, though it could be more structured.

  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 4 parameters with 0% schema coverage and no annotations, the description is incomplete—it misses details on 'query' and 'display'. However, an output schema exists, reducing the need to explain return values. The tool's moderate complexity warrants more guidance on usage and 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 0%, so the description must compensate. It explains 'page' for navigation and 'sort' with values 'sim'/'date', covering 2 of 4 parameters. However, 'query' and 'display' are not explained, leaving gaps. The baseline is adjusted upward due to partial coverage.

  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 the action ('Searches for news') and resource ('on Naver'), specifying the platform and content type. It distinguishes from siblings like search_blog or search_image by focusing on news, though it doesn't explicitly contrast with them.

  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 versus alternatives like search_webkr or search_blog. The description mentions sort options but doesn't explain when to choose 'sim' versus 'date' or when pagination is needed, leaving usage context implicit.

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

• search_shopB
  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 mentions that 'page parameter allows for page navigation' and 'sort='sim'/'date'/'asc'/'dsc' is supported,' which adds some operational context. However, it doesn't cover important behavioral aspects like rate limits, authentication requirements, error handling, or what the output contains. For a search tool with no annotation coverage, this leaves significant gaps.

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

  Conciseness4/5

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

  The description is appropriately concise with two sentences that each add value. The first sentence establishes the core purpose, and the second provides important parameter details. There's no wasted language, and information is front-loaded with the main function stated first.

  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 that there's an output schema (which means the description doesn't need to explain return values) and no annotations, the description provides basic operational context but leaves gaps. It covers the main purpose and some parameter semantics, but doesn't address behavioral aspects like rate limits or error conditions. For a search tool with 4 parameters and no annotations, this is minimally adequate but could be more comprehensive.

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

  Parameters4/5

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

  The description adds meaningful context beyond the input schema. While the schema has 0% description coverage (only titles), the description explains that 'page parameter allows for page navigation' and specifies valid sort values ('sim'/'date'/'asc'/'dsc'). This clarifies the purpose of the 'page' and 'sort' parameters that the schema only lists by title. However, it doesn't explain the 'display' parameter or provide examples for the 'query' parameter.

  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 the tool's purpose: 'Searches for shopping product information on Naver using the given keyword.' This specifies the verb ('searches'), resource ('shopping product information'), and platform ('Naver'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_blog' or 'search_news' beyond mentioning 'shopping product information'.

  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 alternatives. It mentions 'shopping product information' which implies a context, but doesn't specify when to choose this over other search tools like 'search_webkr' or 'search_local'. There's no mention of prerequisites, exclusions, or comparative use cases with sibling tools.

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

• check_adult_queryB
  3.2/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 states what the tool does but lacks details on how it works: e.g., what criteria define 'adult,' whether it's a classification or binary check, error handling, or performance traits. This leaves significant gaps for an agent to understand its behavior.

  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 wasted words. It's front-loaded with the core purpose, making it easy to parse. Every word earns its place by directly contributing to understanding the tool's function.

  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's moderate complexity (classification task), no annotations, and an output schema (which likely handles return values), the description is minimally adequate. It states the purpose but lacks usage context, behavioral details, or parameter nuances. It meets the baseline for a simple tool but doesn't fully address potential agent confusion.

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

  Parameters4/5

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

  The description adds meaning beyond the input schema, which has 0% description coverage. It clarifies that the 'query' parameter is an 'input query' to be evaluated as an 'adult search term,' providing context not in the schema. With only one parameter, this is sufficient to compensate for the low schema coverage, though it doesn't detail format or constraints.

  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 the tool's purpose: 'Determines if the input query is an adult search term.' It specifies a verb ('determines') and resource ('adult search term'), making the intent unambiguous. However, it doesn't differentiate from sibling tools (e.g., search_webkr, search_image), which might also handle queries, so it's not a perfect 5.

  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 alternatives. It doesn't mention sibling tools or contexts where this tool is preferred (e.g., for content filtering vs. general search). Without such information, agents may struggle to select it appropriately among the many search-related siblings.

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