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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the critical requirement of an AMAP_API_KEY, which is beyond what annotations provide. No contradiction is present. A slightly higher score is warranted because the API key is a significant behavioral prerequisite.

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

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

The description is a single sentence that front-loads the purpose and includes the essential API key requirement. Every word serves a purpose, with no redundancy or extraneous information.

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

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

Given the tool's simplicity (2 parameters, no output schema, rich annotations), the description is sufficiently complete. It specifies the input requirements and the general outputs, though it could optionally mention output format or error handling. The API key note is a critical addition.

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

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

The input schema has 100% description coverage for both parameters, clearly explaining their meaning (address and optional city). The description does not add any additional semantics beyond what the schema already provides, 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.

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

The description uses a specific verb '解析' (parse) and clearly states the resource '中国地址' and the outputs '经纬度、行政区划和标准化地址'. It effectively distinguishes from siblings like cn_amap_regeocode (reverse geocoding) and cn_amap_place_search (place search).

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

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

The description mentions the need for an AMAP_API_KEY, which is a crucial usage requirement. While it doesn't explicitly state when not to use this tool or provide alternatives, the sibling tool names (e.g., cn_amap_regeocode) imply the context for each, making the guideline adequate.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the important context that an AMAP API key is required, which is a behavioral constraint not covered by annotations. It does not detail pagination or rate limits, but the key requirement is a valuable addition.

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

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

The description is two concise sentences with no extraneous information. It front-loads the core purpose and quickly covers the two modes and the API key requirement. Every sentence earns its place.

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

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

Given the tool has 7 parameters and no output schema, the description covers the essential missing pieces: dual search modes, parameter dependencies, and API key requirement. It does not explain the output format, but for a search tool the agent can infer a list of places. The annotations further reduce the need for behavioral detail.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the dependency between radius and coordinates ('需配合经纬度'), and implicitly groups parameters into city-mode (keywords + city) and coordinate-mode (keywords + longitude/latitude + radius). This goes beyond the schema's standalone descriptions.

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

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

The description clearly states '搜索中国 POI/地点' (search Chinese POI/places) and specifies two search modes (by city or near coordinates). It distinguishes from sibling tools like cn_amap_geocode and cn_amap_regeocode which handle geocoding and reverse geocoding, not POI search.

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

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

The description implicitly guides usage by stating the two search modes (city or coordinates). It does not explicitly exclude alternatives, but the sibling tool names and context make it clear that this tool is for POI search, not geocoding or other functions. A more explicit when-not-to-use statement would improve this.

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

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

Annotations already indicate readOnly, non-destructive, idempotent, and open world behavior. The description adds the critical requirement of an AMAP_API_KEY, which is not in annotations. This provides additional behavioral constraint beyond what annotations offer. No contradictions.

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

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

Two short, front-loaded sentences: first states purpose, second states prerequisite. No wasted words.

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

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

Despite clear purpose and good schema, the description lacks any indication of the output format or structure. With no output schema present, the description should at least mention what kind of data is returned (e.g., province, city, district). This gap reduces completeness for an AI agent.

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

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

Schema coverage is 100% (all 3 parameters have descriptions). The description does not add any parameter-specific information beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool converts coordinates to Chinese address and administrative division, using a specific verb '反查'. It distinguishes from sibling tool cn_amap_geocode (which does the reverse) by mentioning '反查', implying the opposite direction.

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

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

The description implies usage for geocoding coordinates to Chinese addresses and mentions a prerequisite (AMAP_API_KEY), but does not provide explicit when-to-use or when-not-to-use guidance versus alternatives. The usage is clear from context but not elaborated.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Description adds the crucial authentication requirement (AMAP_API_KEY), which is beyond annotations. No contradictions.

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

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

Two very concise sentences. No wasted words: purpose, parameter hint, and authentication requirement are all front-loaded and clear.

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

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

For a simple tool with 2 parameters, rich annotations, and no output schema, the description is sufficiently complete. It explains purpose, parameter usage, and authentication. It could mention return format, but not required.

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

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

Schema covers both parameters with clear descriptions (e.g., city examples, extensions enum with defaults). Tool description adds no new parameter info beyond the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool queries real-time weather or forecast for Chinese cities. It specifies the verb '查询' (query) and resource '天气' (weather), and distinguishes from sibling tools (none are weather-specific).

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

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

Provides clear instructions: city can be name or adcode, extensions parameter explains base vs all, and mentions the AMAP_API_KEY requirement. No explicit alternatives or exclusions, but context is adequate.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by stating it does not simulate login or download restricted content, reinforcing the read-only and compliant nature. This provides extra context beyond annotations.

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

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

The description is two short, focused sentences without any fluff. The first sentence delivers the core purpose, and the second adds behavioral constraints. Every word serves a purpose.

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

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

Considering the simple read-only nature, full schema documentation, and informative annotations, the description is largely complete. It lacks details about the return format or field contents, but given the openWorldHint=true annotation and the tool's straightforward purpose, this is acceptable. A perfect score would require mention of typical response fields.

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

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

Schema description coverage is 100%, with both parameters having clear descriptions: 'input' as BV号/AV号/link and 'includePages' as boolean default true. The description does not add further semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states '获取 Bilibili 公开视频基础信息。' (Get Bilibili public video basic information), specifying the verb 'get', resource 'Bilibili video', and scope 'public'. Among the sibling tools (Amap, express, holiday, IP, etc.), this uniquely targets Bilibili video, making it easily distinguishable.

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

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

The description includes '只访问公开信息，不模拟登录、不下载受限内容。' (Only access public info, no simulated login, no downloading restricted content), which tells the agent when to use (for public info) and implicitly when not to use (for restricted content). However, no explicit alternative tool is named among siblings, though none exist for Bilibili video.

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

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

Annotations already indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that the tool requires authorization and does not scrape, providing useful behavioral context beyond annotations. No contradictions.

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

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

The description is extremely concise with two sentences: the first states the primary purpose, and the second provides critical usage context. No redundant words.

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

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

For a tool with 3 parameters, 100% schema coverage, and clear annotations, the description is sufficiently complete. It explains the core function and an important constraint (authorization required). No output schema exists, but the description does not need to detail return format.

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

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

The input schema covers all three parameters with descriptions (100% coverage). The description does not add new parameter-level details, so it meets the baseline expectation without exceeding it.

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

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

The description clearly states the verb '查询' (query) and the resource '中国快递物流轨迹' (Chinese express logistics tracking), distinguishing it from sibling tools which cover other Chinese services like maps, weather, and video info.

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

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

The description notes that it supports authorized configuration via Kuaidi100 or Kuaidiniao and explicitly states it does not do unauthorized scraping, guiding the agent to use it only when proper authorization is available. However, it does not explicitly mention when not to use it or compare with alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by specifying the data is built-in for 2025/2026, implying static data and no external API calls. This contextual detail goes beyond annotations.

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

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

Two well-structured sentences. The first sentence states the core query capabilities, the second provides data scope. No superfluous text.

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

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

Given the simple input (one parameter) and no output schema, the description lists the types of information returned (weekday, weekend, workday, holiday, compensatory workday), which is sufficient for agent understanding of outcomes.

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

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

The schema covers the date parameter with format and description. The description adds that data is built-in for 2025/2026, indicating the valid date range. This extra context helps agents understand that dates outside this range may not return meaningful results.

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

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

The description clearly states the tool queries Chinese date info (weekday, weekend, workday, holiday, compensatory workday) with built-in 2025/2026 data. The verb '查询' (query) and specific resource '中国日期信息' make it distinct from sibling tools like geocode or weather.

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

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

The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool's purpose, but no guidance on exclusions or when not to use it is provided.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world hints. The description adds valuable context about the default behavior when no IP is provided, and what information is returned, which goes beyond the annotations.

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

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

Two short sentences, no extraneous words. The information is front-loaded and every sentence adds value.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, parameter semantics, default behavior, and output contents. It is fully adequate.

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

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

The schema has 100% description coverage for the single optional parameter, including the default behavior. The tool description adds the list of returned fields (country, region, city, ISP, ASN), enriching understanding beyond the schema alone.

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

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

The description clearly states it queries geolocation info (country, region, city, ISP, ASN) for a given public IP, and defaults to the current egress IP if none is provided. This is specific and distinguishes it from sibling tools like cn_amap_geocode which handle address geocoding.

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

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

The description explains when to use: for IP geolocation lookup or to check the current egress IP. While it does not explicitly exclude other tools, the context and sibling names make it obvious that this is for IPs, not addresses or weather. The default behavior is also clarified.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying that it extracts lightweight data like title, description, site name, canonical, and favicon. No contradictions, and it clarifies the scope of extraction.

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

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

The description is a single sentence that efficiently conveys the tool's purpose, scope, and use case without unnecessary words. It is front-loaded with key information.

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

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

Given the simple input (one parameter) and the presence of annotations, the description provides adequate context including the output fields and use case. It could be more complete if it described the output format, but the listed fields partially compensate for the lack of an output schema.

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

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

The input schema is fully covered (100%) with a clear description for the single 'url' parameter. The tool description adds no additional parameter meaning beyond the schema, 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.

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

The description clearly specifies the verb 'extract' and the resource (公开网页标题、描述、站点名、canonical 和 favicon). It also distinguishes the tool from siblings like cn_webpage_extract by noting it's '轻量' (lightweight) and suitable for group chat link previews.

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

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

The description indicates the use case ('适合群聊链接预览'), providing clear context for when to use. However, it does not explicitly state when not to use or mention alternative tools, missing some differentiation guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that it reads public feeds and returns specific fields but does not disclose additional traits like network behavior, caching, or error handling. With annotations covering safety, the description offers moderate added value.

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

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

The description is a single sentence that is front-loaded with the core purpose. It is concise and efficient, though it could optionally include a second sentence for usage guidelines.

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

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

Given the well-annotated read-only and idempotent nature, and full schema coverage, the description adequately covers the return fields and scope. It lacks details on error handling or non-RSS feeds but is sufficient for a simple fetch tool.

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

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

Schema coverage is 100%, so the input schema already describes all four parameters. The description does not add meaning beyond what the schema provides, resulting in a baseline score.

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

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

The description clearly states the verb (读取), resource (公开 RSS/Atom 订阅), and the returned data (标题、链接、发布时间、摘要). It also specifies suitability for Chinese blogs, media, and tech sites, differentiating it from sibling tools like cn_webpage_extract and cn_link_preview.

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

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

The description implies usage context by stating its suitability for Chinese blogs, media, and tech sites, but it does not explicitly state when to use it versus alternatives or provide exclusions. Guidance is 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.

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

Annotations indicate readOnly, non-destructive, idempotent behavior. The description adds specific transformations (normalization, masking) that occur, which is beyond the annotations. No contradiction with annotations.

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

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

The description is a single sentence with a list of operations. It is front-loaded with the main purpose and every phrase is meaningful. No redundant information.

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

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

While there is no output schema, the description implies the result is the cleaned text. With rich schema and annotations, the description is complete enough for an agent to understand functionality. Minor gap: return format not detailed.

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

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

Schema coverage is 100% with each parameter described in Chinese. The description provides a summary but does not add new parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool normalizes Chinese text with specific operations (whitespace normalization, full/half-width conversion, control character removal) and optional masking of sensitive data. The verb '清洗' (clean) and resource '中文文本' (Chinese text) are specific. No sibling tool performs text normalization, so it is well-distinguished.

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

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

The description implies when to use the tool: for cleaning Chinese text and optionally masking personal information. It does not explicitly state when not to use or provide alternatives, but given no similar sibling tools, the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by detailing the specific output formats (ISO, local Chinese, day of week, timestamp) beyond what annotations provide. No behavioral quirks or contradictions.

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

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

The description is a single concise sentence that covers all essential information: timezone, output formats, and purpose. No unnecessary words, and the information is front-loaded.

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

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

Despite lacking an output schema, the description explicitly lists the return value formats (ISO, local Chinese, day of week, timestamp), which is sufficient for this simple tool. No required parameters, so the description is complete and meets all informational needs.

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

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

Schema description coverage is 100%, with the only parameter 'now' described as a placeholder not needing to be passed. The description adds no further information on parameters, which is acceptable since the schema already clarifies their purpose. Baseline score of 3 applies.

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

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

The description clearly states the verb (获取, 'obtain') and resource (当前时间, 'current time') with specificity about timezone (Asia/Shanghai) and output formats (ISO, local Chinese, day of week, timestamp). It fully captures the tool's purpose and distinguishes it from siblings, none of which are time-related.

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

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

The description does not explicitly state when or when not to use this tool, nor does it mention alternatives. While the sibling list contains no time tools, the description could be improved by adding guidance, such as noting that this is for China time only.

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

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

Annotations already provide readOnlyHint, destructiveHint false, idempotentHint true, and openWorldHint true. The description adds valuable behavioral context about SSRF protection (blocking localhost/intranet). No contradictions. Could mention other behaviors like rate limits or error handling, but current info is sufficient.

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

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

Two sentences, front-loaded with the core action. No unnecessary words. Very efficient.

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

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

Given the rich schema and annotations, the description covers the main behavioral detail (SSRF protection). Some information like error handling or return format is missing, but for a read-only tool with openWorldHint, this is acceptable.

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

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

All parameters are described in the schema (100% coverage). The description does not add extra detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it reads title, description, and body excerpt of public web pages. The sibling tools cover distinct domains (maps, video, weather, etc.), so this tool's purpose is well differentiated.

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

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

The description explicitly mentions default blocking of localhost/intranet/private addresses to reduce SSRF risk, providing context. It does not explicitly state when to use versus siblings, but the tool's purpose is clear enough.

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