Server Quality Checklist

Tool Scores

• article_updateC
  2.2/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 that the tool modifies an article, which is already implied by the name. It does not explain whether updates are partial or full, how status transitions work, what error conditions exist, or what the response contains.

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

  Conciseness2/5

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

  The description is a single short sentence with no wasted words, but it is under-specified. It repeats the tool name without adding useful information, failing to earn its place. For an 8-parameter mutation tool, a more informative description would be both concise and valuable.

  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's complexity (8 parameters, 3 enums, no output schema, no annotations), the description is far from complete. It does not explain the update semantics, required identification via 'id', or any constraints or side effects. The rich schema helps, but the description alone leaves major gaps for an agent deciding on 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 has 100% description coverage, with each of the 8 parameters (id, body, tags, style, title, status, language, research_refs) having meaningful descriptions. The description text itself adds no parameter semantics, but the schema already provides the necessary 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.

  Purpose2/5

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

  The description '아티클을 수정합니다' translates to 'Modifies the article,' which directly restates the tool name 'article_update.' It conveys the basic action but provides no differentiation from sibling tools like article_create or delete_content, and doesn't specify what aspects of the article can be updated.

  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?

  There is no guidance on when to use this tool versus alternatives such as article_create, article_get, or article_list. The description gives no context about prerequisites, partial updates, or typical use cases, leaving the agent to infer everything from the name and schema.

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

• article_statsC
  2.6/5.0
  Behavior1/5

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

  No annotations are present, and the description only states the action without any side-effect, permission, rate-limit, or data-scope information. The agent cannot determine if this is a safe read-only operation or if it requires specific context.

  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 a single, succinct Korean sentence that wastes no words. However, it under-specifies the behavior, so while concise, it sacrifices informativeness.

  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?

  With no annotations, output schema, or parameters, the description is the sole source of context. It provides no information about the return format, the nature of the statistics, or how this tool relates to other article tools, making it inadequate for an agent to confidently invoke it.

  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 tool has zero parameters, so the input schema is fully complete. The description adds no parameter information, but the 0-param baseline of 4 applies.

  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 uses the specific verb '조회' (retrieve) and resource '아티클 통계' (article statistics), clearly identifying the tool's action. It distinguishes from sibling tools like get_articles or article_list by focusing on statistics, but it does not specify the exact type or scope of statistics.

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

  Usage Guidelines1/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. There are no conditions, alternative tool references, or exclusions, leaving the agent to infer usage from the name and description alone.

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

• article_listC
  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 responsibility for behavioral disclosure. It only states that it retrieves a list, offering no information about whether it returns only published articles, sorting behavior, pagination defaults, or any side effects. This is minimal but not misleading.

  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 extremely short and not verbose, but it lacks substantive information. It is a single generic sentence that could apply to any list endpoint, so while it is concise, it does not 'earn its place' by providing meaningful specifics.

  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 5 optional filters, no output schema, and multiple closely related sibling tools. The description does not explain the tool's filterable nature, default behavior, or how it differs from 'get_articles'. It is incomplete for effective selection and 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 schema descriptions cover all 5 parameters (limit, style, offset, status, language) with clear definitions and enum values, so the description does not need to repeat them. However, the description adds zero value beyond the schema—it doesn't mention how parameters interact or provide any additional 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 core function: retrieving a list of articles. However, it does not differentiate from sibling tools like 'get_articles' or 'article_search', so it lacks specificity to distinguish among similar operations.

  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. With siblings like 'get_articles', 'article_search', and 'get_web3_news', a user would not know which tool fits their use case, and no exclusions or alternative recommendations are given.

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

• add_to_watchlistC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Add a token to the watchlist for tracking' and does not describe side effects, duplicate handling, permissions, or return value 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, concise sentence with no filler. It communicates the core purpose efficiently.

  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 absence of annotations and an output schema, the description is too sparse. It doesn't explain what happens after adding, potential duplicate behavior, or what the return value represents, leaving the agent without sufficient context for a mutation 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% description coverage for all parameters, so the description doesn't need to add parameter details. The description adds no extra parameter information, so a baseline score of 3 is appropriate.

  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 (add) and resource (token to watchlist). It is distinct from sibling tools like get_watchlist, but it does not explicitly differentiate itself from alternatives, so it doesn't earn 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 simply states what it does, with no mention of use cases, prerequisites, or exclusions.

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

• get_articleC
  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 only states 'Get full article details' without disclosing whether the operation is read-only (though 'Get' implies it), what specific fields are returned, error behavior, or any permissions/rate limits. The phrase 'full article details' is vague and does not convey meaningful behavioral context.

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

  Conciseness5/5

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

  The description is a single sentence that directly states the core function without wasted words. It is concise and front-loaded with the action verb and resource, making it easy to scan and understand.

  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 absence of annotations and output schema, the description is insufficient. It does not specify what 'full article details' includes (e.g., content, metadata, timestamps) or what the return structure looks like. There is also no context about when to prefer this over sibling list/search tools. For a tool with this level of complexity, the description leaves notable 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?

  The schema has 100% description coverage for the single parameter 'id' (Article ID (UUID)). The description's 'by ID' matches the schema but adds no extra meaning. Since the schema fully documents the parameter, a baseline score of 3 is appropriate; the description does not need to compensate.

  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 'Get full article details by ID' clearly states the verb (Get), resource (article details), and scope (by ID), which distinguishes it from the plural sibling get_articles. However, it does not explicitly mention alternatives like article_get, leaving some ambiguity about which tool to use for single-article retrieval among several similarly named 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 get_articles or article_get. There is no mention of prerequisites, filters, or exclusions. The only implicit signal is the 'by ID' scope, but no explicit when/when-not guidance is given.

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

• get_articlesC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it only restates the function. It doesn't mention pagination, default limits, or what 'saved' means, though the schema covers parameters. 'From the database' is a vague filler that adds no transparency.

  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 a single concise sentence, but 'from the database' is unnecessary filler. It is brief, but not maximally informative; still, it earns a 4 for brevity.

  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?

  With 5 optional parameters, no output schema, and no annotations, the description is insufficient for an agent to understand the tool's full behavior. It doesn't explain response format, default behavior, or which sibling tools to prefer. The schema helps, but the description lacks contextual completeness.

  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 thorough descriptions for all 5 parameters (100% coverage), so the schema carries the burden. The description adds no additional parameter context, but the baseline of 3 is appropriate.

  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 retrieves saved articles with the verb 'get' and resource 'articles'. However, it doesn't differentiate from sibling tools like article_list or get_article, which likely have overlapping functionality.

  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 article_list, article_search, or get_article. The description lacks any contextual cues about typical use cases or scenarios.

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

• get_contentC
  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 only states what the tool does, not how it behaves (e.g., return format, error handling, auth requirements). The minimal 'by ID' hints at a simple lookup but does not disclose potential pitfalls or edge cases.

  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 that directly states the purpose. It is appropriately sized for a simple getter tool and avoids verbosity, earning its place without unnecessary words.

  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's simplicity (1 parameter, no output schema) and no annotations, the description should compensate by explaining return values or context. It does not, leaving the agent uncertain about what 'content item' encompasses and how it relates to sibling tools like article_get. The lack of usage context weakens completeness.

  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 the id parameter already described as 'Content ID (UUID)'. The description's 'by ID' aligns with the schema but adds no additional meaning, such as format details, required vs optional, or allowed values beyond what the schema provides.

  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 ('Get') and resource ('content item') with a specific qualifier ('by ID'). It is unambiguous but does not differentiate from sibling tools like get_article or article_get, which may serve similar single-item retrieval purposes.

  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 such as search_content or get_articles. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

• get_token_priceC
  2.9/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 only states the basic action ('Get current price and market data') without detailing what 'market data' includes, whether it makes network calls, or any potential variations in response. The read-only nature is implied but not explicitly stated, and no output schema exists to clarify return values.

  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, tightly written sentence that is front-loaded with the verb and resource. No unnecessary words or repetition exist, making it concise and easy to parse.

  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 absence of an output schema, the description should clarify what 'market data' entails, but it leaves this vague. It also lacks usage context or edge-case information, making it incomplete for a tool with only two parameters and no structured output definition.

  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 both parameters (token_id and currency), covering 100% of the schema. The description's mention of 'market data' adds a slight semantic hint but does not substantially enrich understanding beyond the schema's field descriptions and examples.

  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 function with a specific verb ('Get') and resource ('current price and market data for a cryptocurrency'). It distinguishes from sibling tools like get_trending_tokens or article tools by focusing on price/market data, though it does not explicitly name alternatives.

  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. The description gives no context about use cases, exclusions, or relationships to sibling tools like get_trending_tokens. Only the parameter examples hint at token IDs, but no explicit usage direction exists.

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

• get_web3_newsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does add a small trait by saying 'public sources', implying no authentication or private data, but it omits important behavior such as return format, pagination, error handling, or what 'latest' means. This is insufficient transparency for a tool with no annotations.

  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 a single, front-loaded sentence with no filler words. Every word contributes to stating the tool's purpose. It could be considered slightly under-specified for such a large sibling set, but as a concise purpose statement it is efficient and well-structured.

  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?

  Although the input schema is complete, the tool has no annotations and no output schema, so the description must explain behavior and return values. It only states it fetches latest web3 news from public sources; it does not mention what the response looks like, how limit/category affect results, or any pagination/ordering behavior. This leaves the agent without enough context for a tool surrounded by many content-related 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 100%: limit and category are fully described, including limit's default (5) and category's allowed values (defi, nft, layer2, dao, general). The description adds no parameter information beyond the schema, so the baseline score of 3 applies.

  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 uses a specific verb ('Fetch') and names the resource ('latest web3 news') with a source qualifier ('from public sources'). It clearly states what the tool does and distinguishes it from generic article tools like get_articles and article_list by domain (web3) and source (public). However, it does not explicitly call out an alternative tool, so it stops short of full sibling differentiation.

  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 when-to-use or when-not-to-use guidance is provided. The description does not mention prerequisites, alternatives, or situations where sibling tools like fetch_rss_articles or search_content would be more appropriate. The only implied usage is the purpose itself, which is too weak for a tool with many similar siblings.

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

• mark_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 disclosing behavioral traits. While it states that the tool mutates article read/bookmark status, it does not explain whether the operation is idempotent, whether absent booleans are left unchanged, or any permission requirements.

  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 a single, front-loaded sentence that is easy to parse. It omits unnecessary words, but its brevity may contribute to ambiguity about whether both flags can be set simultaneously.

  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 is simple with only three parameters and no output schema, but the description lacks important context such as whether this is a partial update, how the two booleans interact, and whether the article must already exist. The schema covers parameter types but not these higher-level behavioral 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 parameter descriptions already adequately explain each field. The tool description adds no extra parameter semantics. However, the word 'or' in the description might misleadingly suggest exclusivity, which is a minor negative signal that keeps the score at baseline 3.

  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 function: marking an article as read or bookmarked. The verb 'mark' and resource 'article' are specific, and the two possible actions (read/bookmarked) are identified. However, it does not explicitly differentiate from sibling tools like 'article_update', though the use case is distinct.

  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 such as 'save_content' or 'article_update'. The description does not mention prerequisites, edge cases, or typical scenarios.

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

• save_contentC
  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 must fully disclose behavioral traits, but it only says 'Save web3 content to the database'. It does not mention whether this creates new records, updates existing ones, requires authentication, handles duplicates, or what the return value is. This is a significant gap for a mutation tool.

  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 a single, clear sentence with the verb and object front-loaded and no redundant wording. It could include more usage details, but for basic purpose identification it is appropriately concise.

  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 8 parameters, no annotations, and no output schema, the description is minimally viable: it names the action and object, and the schema covers parameters. However, it lacks critical behavioral context such as update semantics, idempotency, and return values, leaving clear gaps for an agent deciding how to invoke it.

  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 descriptions for all 8 parameters (100% coverage), so the baseline is met. The description adds 'web3 content' context and example types, but these largely echo the schema; notably, the parenthetical omits 'news' which is listed in the schema's content_type description, introducing slight ambiguity.

  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 uses a specific verb 'Save' with a clear resource 'web3 content' and lists content types like article, post, and document, making the primary action and object clear. However, it does not explicitly differentiate this tool from sibling 'article_create', which may overlap in functionality, preventing a score of 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 such as 'article_create', 'update_content', or 'delete_content'. It only states what the tool does, leaving the selection criteria entirely to the agent.

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

• remove_rss_sourceB
  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 of behavioral disclosure. It merely restates the tool's name without mentioning permanence, error handling, side effects, or permissions. This is essentially a tautology.

  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 action verb and contains zero unnecessary words.

  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 mutation tool with no annotations and no output schema, this description is too sparse. It lacks any context about return values, failure behavior, or preconditions, leaving the agent without vital information for safe 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 coverage is 100%, with the 'id' parameter well-documented as a UUID. The description adds no new meaning beyond 'by ID', 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 tool's function: removing an RSS source by ID. The verb 'Remove' is specific and distinguishes it from sibling tools like add_rss_source and list_rss_sources.

  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, nor are there any prerequisites or exclusions mentioned. The usage is only implied by the tool name and description.

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

• article_searchB
  3.1/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 reveals search scope (title+body) but omits key behaviors: whether search is fuzzy, how results are sorted, pagination details, or what fields are returned. This is insufficient 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, focused sentence that states the exact function. No filler or redundant content; every word contributes to understanding.

  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?

  With no output schema and only a minimal description, the tool lacks essential context about return format, result count limits, and search behavior. The schema covers parameter meaning but not the output structure or edge cases.

  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?

  Schema descriptions already define all parameters clearly (query, limit, language). The description adds value by specifying that the query applies to title and body, enriching the meaning of the query parameter beyond the schema's '검색어'.

  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 searches articles, specifying scope as title+body. This distinguishes it from list/retrieve tools like get_articles or get_article, though it does not explicitly name alternatives.

  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 given on when to use this tool versus siblings like search_content or get_articles. The context from sibling names and the description's scope are the only hints, with no explicit when/when-not guidance.

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

• add_rss_sourceB
  3.2/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 responsibility for behavioral disclosure. It only states 'Add' (a mutation) but does not mention idempotency, validation, duplicate handling, auth requirements, or any side effects. This is a significant gap for a write operation.

  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 with zero filler. Every word contributes to meaning, making it exceptionally concise while remaining clear.

  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 is a simple create operation, but there is no output schema and the description does not indicate what the response will be (e.g., created object, confirmation, error format). It also lacks coverage of edge cases like duplicate URLs or required permission levels, making it incomplete for an agent 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?

  The input schema has 100% coverage with descriptions for all four parameters (url, name, language, source_group). The description adds no extra parameter semantics, so the baseline of 3 is appropriate as the schema already documents each field.

  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 'Add a new RSS feed source' uses a specific verb ('Add') and resource ('new RSS feed source'), clearly distinguishing it from siblings like remove_rss_source or list_rss_sources. The intent is unmistakable and immediately actionable.

  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, such as when to use remove_rss_source or fetch_rss_articles. There are no exclusions, prerequisites, or context cues beyond the straightforward action.

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

• search_contentB
  3.2/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. It does not disclose any behavioral traits such as read-only nature, pagination, ordering, authorization requirements, or default behavior when no query is provided. The statement is purely functional.

  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 sentence with no wasted words. It is appropriately front-loaded and direct.

  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 4 optional parameters and no output schema, so the description must explain what the tool returns and how to use it effectively. It only states the search capability, not the response format, result limits, or that it searches metadata vs full text. Lacks comparison to sibling search tools.

  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?

  All four parameters are documented in the schema with descriptions (100% coverage), so the baseline is 3. The description adds a high-level mapping of query to 'keywords', tags to 'tags', and blockchain to 'blockchain', but provides no additional syntax or format details beyond the schema.

  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 a specific verb ('Search') and resource ('stored web3 content') with the available filter dimensions (keywords, tags, blockchain). It is distinct from get_article and save_content, but it doesn't distinguish itself from the sibling article_search, leaving some ambiguity.

  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?

  No explicit guidance on when to use this tool over alternatives like article_search or get_articles. The description implies usage for finding saved content but lacks exclusions or alternative references.

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

• analyze_contentB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it can accept arbitrary text vs. stored content, or what side effects (if any) occur. The phrase 'analyze web3 content' is a purpose statement, not a behavioral 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, front-loaded sentence that clearly communicates the tool's function without any filler or redundant phrasing. It is appropriately sized and well-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?

  The tool has three optional parameters and no output schema or annotations. The description covers the core purpose but omits important context such as how to choose between text and content_id, what the output structure looks like, and any usage disclaimers. It is minimal but not completely inadequate for a simple analysis 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 schema already provides 100% coverage of the three parameters, so the baseline is 3. The description adds some context by mapping 'key insights, sentiment, and topics' to the analysis_type values, but it does not clarify the relationship between 'text' and 'content_id' or when to use each. Thus, it adds marginal value 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 states the tool analyzes web3 content and specifies the output dimensions: key insights, sentiment, and topics. The verb 'analyze' is specific and distinguishes this tool from siblings like 'get_article' or 'search_content', which focus on retrieval rather than analysis.

  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 does not mention prerequisites, exclusions, or how it differs from content retrieval tools. The sibling list includes many content-related tools, but the description offers no situational context for choosing analyze_content.

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

• article_exportB
  3.3/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 fully disclose behavior. It only states the export action but does not indicate whether it is read-only, how the markdown is returned (file, string, download), authentication needs, or side effects. This is 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?

  A single sentence that directly states the purpose. It is concise and front-loaded with no wasted words. While it misses behavioral details, it excels in economy and clarity for its length.

  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 two-parameter tool, this description conveys the core function. However, it lacks details about the return format (e.g., inline markdown vs. attachment) and there is no output schema to compensate. It is sufficient for basic understanding but leaves ambiguity about the expected output.

  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 fully describes both parameters: id as '아티클 UUID' and include_meta with a default of true. The description adds no extra parameter context, but with 100% schema coverage, 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 a specific verb (export), a resource (article), and the output format (markdown). This distinguishes it from sibling tools like get_article and article_get, which likely return the article without format conversion.

  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 about when to use the export tool versus alternatives. The description only states the action, leaving the agent to infer from the tool name and sibling tools. There are no explicit exclusions or mentions of alternative tools.

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

• article_templatesB
  3.3/5.0
  Behavior3/5

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

  With no annotations present, the description must carry the full burden of behavioral disclosure. The verb '조회' (retrieve) conveys that this is a read-only operation, which is useful. However, it does not disclose any other behavioral traits such as authentication requirements, rate limits, or what the response structure looks like. For a simple lookup, the read-only implication is adequate but not exhaustive.

  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 states the tool's purpose without any unnecessary words. It is front-loaded and well-structured for quick comprehension.

  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 is simple (2 optional params, no output schema), but the description is minimal. It does not describe the return format (e.g., list vs. object), nor does it provide usage context with respect to article creation or other workflows. Given the absence of an output schema, this omission leaves some uncertainty about the tool's behavior, though the core purpose is clear.

  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 full descriptions for both parameters, including enums and default values for 'language'. The description itself does not add any information about the parameters beyond what the schema already states, so the baseline of 3 applies.

  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 uses the specific verb '조회합니다' (retrieves) and clearly names the resource as '사용 가능한 아티클 템플릿과 톤앤매너 가이드' (available article templates and tone & manner guides). This distinguishes it from sibling tools that focus on articles, RSS, or analytics. However, it does not explicitly contrast with any sibling tool, so a perfect 5 is not warranted.

  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?

  There is no guidance on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer its usage. No exclusions or prerequisites are mentioned.

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

• fetch_rss_articlesB
  3.3/5.0
  Behavior2/5

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

  Without annotations, the description must disclose behavioral traits. It mentions saving to the database, which is a side effect, but does not clarify idempotency, duplicate handling, authentication requirements, rate limits, or what 'new' means. This leaves significant behavioral uncertainty for a mutation 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 clearly communicates the action and resource. There is no wasted wording 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?

  The description covers the basic action (fetch and save) but omits return value details, error scenarios, and any distinction from sibling tools. Given the moderate complexity and lack of output schema, 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 each parameter (group, source_id) having a clear optional description. The tool description adds no extra meaning about the parameters, so the 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 fetches new articles from RSS sources and saves them to the database. This distinguishes it from sibling tools like get_articles or article_list which likely read from the database, and from RSS management tools like list_rss_sources.

  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. It doesn't mention that get_articles should be used to read saved articles, or that this tool is for ingesting new content. The usage context is implied but not explicitly stated.

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

• delete_contentB
  3.4/5.0
  Behavior2/5

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

  Without annotations, the description carries the full burden of behavioral disclosure. It merely states the action 'Delete' but does not indicate whether the deletion is permanent, reversible, requires specific permissions, or has cascading effects. The agent is left without warnings about consequences, which is critical for a destructive operation.

  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 delivers the core action and target. Every word earns its place, with no redundancy or ambiguity. This is an example of appropriate under-specification rather than a lack of content.

  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 tool with one parameter and no output schema, the description covers the essential aspects: what it does and what input it needs. However, given a destructive operation without annotations, mentioning irreversibility or return behavior could improve completeness. Still, the low complexity and full schema coverage make this largely sufficient.

  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% for the single parameter 'id' (Content ID (UUID)), so the schema already documents it completely. The description adds no extra meaning beyond identifying that the parameter is used to select which content item to delete. Baseline of 3 applies because schema handles the semantics.

  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 'Delete' and the resource 'content item', making the action explicit. It distinguishes itself well from sibling tools like get_content, save_content, and search_content, which perform different operations on content.

  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, nor does it mention any preconditions or exclusions. For example, it does not clarify when a delete might be inappropriate or if there are safer alternatives (e.g., 'mark_article' for non-permanent removal). This is a minimal 'just do it' description with no contextual usage advice.

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

• list_rss_sourcesB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It simply says 'List all configured RSS sources' but fails to mention that the active_only parameter defaults to true, meaning not all sources may be returned by default. This is a behavioral nuance that could mislead an agent. No other traits (read-only, pagination, etc.) are 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?

  A single sentence that is direct and front-loaded. It conveys the core purpose without any filler or redundancy. The structure is clean and efficient.

  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?

  Despite the tool's simplicity, the absence of an output schema and annotations means the description should explain return values or side effects. It only states the operation but does not describe what the response looks like or any default behaviors. This is insufficient for an agent to fully predict 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 coverage is 100%, so the parameters are already described in the input schema. The description adds no additional meaning about the group filter or active_only default. The baseline of 3 is appropriate since the schema handles the parameter documentation.

  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 action ('List') and the resource ('configured RSS sources') with a specific context ('web3 news'). It distinguishes itself from sibling tools like add_rss_source or fetch_rss_articles, which perform different operations.

  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 viewing existing RSS sources, but it does not explicitly state when to use it over alternatives like fetch_rss_articles or get_web3_news. No exclusions or conditional guidance is provided, making it merely implied rather than explicit.

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

• article_getA
  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 must convey behavioral traits. The Korean verb '조회' implies a read-only lookup, suggesting no side effects. However, the description does not disclose return format, error behavior, or other operational details. For a simple get-by-ID, this is somewhat adequate but still minimal.

  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 unnecessary words. It is optimally concise for the tool's simplicity, earning a perfect score.

  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 is low complexity with one parameter and no output schema. The description states the purpose clearly, and the schema covers the parameter. However, the lack of usage guidance and sibling differentiation, combined with no annotations, leaves the description somewhat incomplete in context. A score of 3 reflects that it's adequate but not thorough.

  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 a clear description for the `id` parameter ('아티클 UUID'), and the description text adds no additional parameter information. Given the high schema coverage (100%), a baseline score of 3 is appropriate.

  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 (fetch/lookup) and resource (article) with the method (by ID). It is specific and unambiguous. However, it does not explicitly differentiate from the sibling tool `get_article`, which appears to serve a similar purpose, preventing a perfect score.

  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 provides no guidance on when to use this tool versus alternatives. It only states the core function, so usage is implied (fetch an article when you have its ID). No exclusions or alternative references are given, resulting in minimal guidance.

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

• get_trending_tokensA
  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 the full burden but only states the action and source. It does not disclose return format, rate limits, or whether data is refreshed, offering minimal 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?

  A single, front-loaded sentence with no excess wording effectively communicates the tool's essential purpose.

  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?

  Given zero parameters and no output schema, the description is sufficient for basic understanding, though it lacks details on response structure or limitations.

  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?

  There are no parameters, so the baseline is 4. The description adds no parameter information beyond schema, but none is needed since the schema is empty.

  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 'Get trending cryptocurrencies from CoinGecko', using a specific verb and resource, and differentiates from siblings like get_token_price by focusing on trending tokens rather than price.

  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 get_token_price or get_web3_news, nor any mention of when not to use it.

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

• article_createA
  3.7/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 does disclose the language tone behavior (ko=뉴닉 style, en=Milk Road style), which is useful context, and specifies the Web3 domain. However, it does not mention side effects, return values, or default status, though some of that is covered in 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, front-loaded sentence that communicates the core purpose and a key customization option efficiently. It has no unnecessary words or repetition.

  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 7 parameters, 3 required, and no output schema, the description is somewhat thin. It covers the main purpose and language feature but lacks information about return values, typical workflow, or how it differs from other article tools. The schema fills parameter gaps but does not provide operational 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 description coverage is 100%, with all parameters already having clear descriptions. The description adds no new parameter-specific information beyond what is in the schema; the language tone is already described in the schema's language parameter. 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 '새 Web3 아티클 생성' (create a new Web3 article) with a specific verb and resource. It distinguishes from sibling tools like article_update or article_list by focusing solely on creation. The language tone switch adds a distinct feature.

  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 provides no explicit guidance on when to use this tool versus alternatives like article_update or article_search. Usage is implied: use for creating new articles. No exclusions, prerequisites, or alternative tool calls are mentioned.

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

• get_watchlistA
  4/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 implies a read-only operation and indicates the output includes current prices, but it does not explicitly mention safety, authentication, rate limits, or return structure. The verb 'get' provides some transparency, but additional context would be helpful.

  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 sentence, front-loaded with the core action and resource, followed by a clarifying detail about prices. Every word earns its place with no 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 tool with no parameters and no output schema, the description is largely complete: it states what is returned (all watchlist tokens) and the key attribute (current prices). It could explicitly mention that it returns an array of token objects, but the inference is straightforward.

  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 tool has zero parameters, and the schema is an empty object (coverage 100%). According to the baseline for 0-parameter tools, a score of 4 is appropriate. The description adds no parameter details, but none are needed.

  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 action ('Get'), the resource ('all tokens in the watchlist'), and an additional qualifier ('with current prices'). This distinguishes it from sibling tools like get_trending_tokens or get_token_price, which target different data sets.

  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: use when you need watchlist tokens and their current prices. However, there is no explicit mention of when to prefer this over get_trending_tokens or get_token_price, and no exclusions are provided.

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