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

No annotations are provided, so the description carries the full burden. It discloses pagination (about 30 per page), return structure (topic_count, list, next-page flag), and topic fields (category, min_trust_level). It also specifies output formatting (Markdown table, full title, no emoji). This goes beyond a bare description, but it omits edge behavior (e.g., empty category, invalid ID) and does not explicitly state read-only nature, though it is implied.

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 organized into short clauses that each add distinct value: purpose, return behavior, parameter lookup, topic content, and formatting rules. It is front-loaded with the core action and avoids redundancy. Slightly verbose in listing display details, but each 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's simplicity (2 integer params, no output schema, no annotations), the description covers most operational needs: what it returns, how to get the required parameter, and display format. The main gap is the undocumented 'page' parameter and any error/empty-state behavior. Overall, it is fairly complete for a listing operation.

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 0%, so the description must explain parameters. It clarifies category_id by instructing to query it via list_categories, but it does not describe the 'page' parameter at all—its role, defaults, or bounds. One of two parameters is left unexplained, which is a significant gap for a tool with zero schema 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 explicitly states '列出指定类别下的话题' (list topics under a specified category), giving a clear verb and resource scope. It further distinguishes the tool by detailing the return payload (topic_count, topic list, next-page flag) and referencing display conventions from latest_topics, so an agent can differentiate it from siblings like tag_topics or latest_topics.

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

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

The description gives context on how to obtain category_id via list_categories, implying the tool is used when a category is known. However, it does not explicitly state when to prefer this over alternatives (e.g., tag_topics, latest_topics) or provide negative usage conditions. It offers some guidance but not exclusions.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool pre-formats results into Markdown and is intended for direct display, which is useful. However, it does not mention side effects, pagination behavior, or any operational constraints beyond formatting.

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?

A single concise sentence that front-loads the core comparison with search and then states the key output behavior. Every word adds value and there is no redundancy.

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?

The description is sufficient for basic tool selection and the output schema likely covers return structure, but it omits parameter semantics and any behavioral caveats. For a tool with no annotations and 0% schema description coverage, this is a noticeable gap.

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

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

Schema description coverage is 0%, so the description should compensate for parameter meaning. It does not explain query, page, or pages at all; it only refers to search. The query parameter is inferable, but page/pages semantics remain undocumented.

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 what the tool does: it behaves like search but returns ready-to-render Markdown with title, URL, and summary list. This explicitly distinguishes it from the raw search sibling, so an agent can understand its unique purpose.

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

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

It names the sibling alternative (search) and describes the differentiating use case: use this when you want display-ready Markdown rather than raw results. It lacks an explicit when-not-to-use statement, but the contrast with search provides clear decision context.

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

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

With no annotations, the description carries the full burden. It discloses the output format and the URL auto-parsing behavior, but does not mention error handling, authentication, rate limits, or whether the operation is read-only. These gaps matter because no annotations are present.

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 sentences with no filler. The first sentence front-loads the core purpose and output format, and the second efficiently covers all parameter semantics.

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?

The description is largely complete for a formatting tool: it explains output, parameters, and pagination, and an output schema exists to cover return structure. It relies on get_topic for underlying behavior and omits edge cases or limits, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains topic_id accepts either a numeric ID or a linux.do URL, posts means number of floors, and start is a 1-based starting floor for pagination with an example. Every parameter is given meaningful semantics.

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 that this tool behaves like get_topic but returns pre-assembled Markdown with a source header and per-post table, which distinguishes it from its sibling get_topic. The purpose is specific and actionable.

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 frames format_topic as an alternative to get_topic, indicating it is for clients that want display-ready Markdown. It does not explicitly state when not to use it or mention other alternatives, but the comparison to get_topic gives clear usage context.

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

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

无注释，描述承担全部负担。它披露了topic_id的URL自动提取、分页参数及返回含total_posts，但未说明错误行为、权限要求或只读确认。对于只读操作，信息基本足够但不够深入。

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?

描述紧凑无冗余，先说明核心用途再详述参数，所有句子都承载信息。没有浪费字符。

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?

无输出模式，描述提到返回含total_posts但未描述完整结构。对于3个参数的简单只读工具，基本信息具备，但未覆盖错误处理或与其他工具的区分，完整性中等。

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?

模式覆盖率为0%，描述完全补偿。它解释了topic_id可接受数字或URL并自动提取ID，以及posts和start的用途、默认值和分页语义，远优于模式本身的类型定义。

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?

描述明确说明工具读取指定话题的详情与楼层正文，动词'读取'加资源'话题'，并解释了topic_id可传数字或URL。它清楚区分了基本功能，但未直接提及与兄弟工具如format_topic的差异，因此未达到最高分。

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?

描述提供了参数用法（posts、start）但未说明何时使用此工具而非search、format_topic等。没有上下文或排除条件，代理只能推测其适用场景。

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 的情况下，描述承担了行为披露责任并做得较充分：说明了每条约 30 条、条目已含 category 与 min_trust_level、Markdown 表格列格式、禁用 emoji 的原因及 null 等级显示规则。未明确提及认证、错误行为或排序细节，但「获取」一词已暗示只读，且格式细节远超一般描述。

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?

内容按核心功能、数据保证、展示约定分层组织，核心动词和分页信息前置，没有冗余。展示约定部分较长但都为正确调用和输出服务，整体结构清晰。

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?

对于只有一个可选参数、无输出 schema、无 annotations 的简单列表工具，描述已覆盖列表范围、分页、条目字段和输出格式，调用所需信息基本齐全。页码语义和异常行为等轻微缺口不影响低复杂度工具的整体可用性。

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?

唯一参数 page 是带默认值 1 的整数，且 schema 描述覆盖率为 0%。描述补充了「每页约 30 条」的分页事实，但未说明页码如何从 1 开始、如何翻页或边界情况，属于部分弥补而非完整说明。

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?

描述以明确动词「获取」和资源「首页「最新」话题列表」开头，并说明分页规模，目的非常具体。它还通过与 get_topic 的对比（无需逐条查分类）帮助 agent 区分该工具与兄弟工具。

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?

描述了清晰的适用场景（首页最新列表），并明确给出一个排除性指引：无需再调用 get_topic 获取分类或等级字段。但没有明确说明与 search、category_topics、top_topics 等兄弟工具的选用关系，仍留有一定推断空间。

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?

No annotations are provided, so the description carries the full burden. It discloses the output content (all categories with topic_count and post_count) and implies a read-only listing, but it does not mention pagination, ordering, or any other behavioral caveats. For a zero-parameter list operation this is adequate but not rich.

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 efficient sentence that front-loads the primary action and resource, then adds the return-relevant counts. Every word earns its place with no redundancy or filler.

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 zero-parameter, read-only listing tool, the description is nearly complete: it states the scope ('all categories') and the notable fields in the result. The lack of an output schema is not a serious gap given the simplicity, though ordering or pagination details would make it fully complete.

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

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

The input schema is empty with zero parameters, so there are no parameter semantics to document. The baseline for zero parameters is 4, and the description correctly avoids inventing parameter details.

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 ('列出' / list) with a clear resource ('所有板块/类别' / all categories) and names the key included fields (topic_count and post_count). This distinguishes it from sibling tools like category_topics, which operate on topics within a category rather than listing categories themselves.

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

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

The use case is implied: call this when you need all categories with their counts. However, there is no explicit guidance about when not to use it or which sibling tool should be chosen instead, such as category_topics for topics inside a category.

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?

With no annotations, the description carries the full behavioral burden. It conveys a read-style enumeration and the returned fields, but does not disclose ordering, pagination, or how counts are computed. That is adequate for a simple list tool, but adds no behavioral context beyond the obvious.

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?

A single compact Chinese sentence with zero filler; the verb and resource appear first, with the count detail following, and the parenthetical '(count)' usefully signals the response field name. Every word 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?

Despite having no parameters, no output schema, and no annotations, the description covers scope ('所有') and return contents (tags with counts), which is nearly all an agent needs to invoke the tool. Only ordering or pagination behavior is left unspecified — a minor gap for a trivial enumeration.

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 tool has 0 parameters, which sets the rubric baseline at 4. The description correctly adds no parameter detail and instead uses the space to describe the response contents (tags plus topic counts), which the empty schema cannot convey.

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 ('列出'/list) with an explicit resource ('所有标签'/all tags) and states the return payload — each tag's topic count. This distinguishes it from sibling tools like list_categories (categories, not tags) and 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?

No explicit when-to-use or when-not-to-use guidance appears, and no sibling alternatives are named. The intended usage is reasonably implied by the scoped phrasing 'all tags', but an agent gets no routing hints to separate it from list_categories, category_topics, or tag_topics.

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?

With no annotations provided, the description carries the full behavioral burden and it delivers: it discloses that pages fetches consecutively at ~50 items per page and sets explicit display conventions (Markdown table/list, full titles, no emoji because of encoding issues). This surfaces pagination behavior and output quirks the schema cannot convey, though it remains silent on auth or rate limits.

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

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

Three sentences with no filler: purpose first, then parameter meaning, then output formatting. Every sentence earns its place, and the most decision-relevant information (what is searched and how) 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?

For a search tool with no output schema and no annotations, the description covers the essentials: purpose, query syntax, pagination behavior, and presentation format. The unaddressed page parameter and the absence of any note on limits or errors are the remaining gaps, but the explicit display conventions partially compensate for the missing 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?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains query with concrete Discourse syntax examples (order:latest, #分类, @用户, tags:, after:, in:title) and explains pages (consecutive pages, ~50 items each), but the page parameter is never mentioned, leaving one of three parameters undocumented.

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

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

The description opens with '全量搜索 linux.do' (full-text search over linux.do), a specific verb plus resource, and the query-syntax detail makes the scope concrete. It does not explicitly name a sibling to contrast with, but the 'full search' framing implicitly distinguishes it from the listing tools (latest_topics, top_topics, category_topics).

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

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

No guidance on when to choose this tool over its 12 siblings; it never names alternatives such as format_search or latest_topics, nor does it state exclusion conditions. The usage content present (query syntax, display conventions) is how-to instruction for invoking this tool, not tool-selection 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?

No annotations are present, so the description carries the full burden. It compensates by disclosing pagination (~30 per page), that each topic already includes category and min_trust_level, and the Markdown display convention with full titles and no emoji in plain-text headers. It omits ordering and invalid-tag behavior, but these are minor for a simple read-only listing tool.

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

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

The description is three short sentences with the core purpose front-loaded. It covers what the tool does, how to pass the tag, and rendering details without filler or repetition.

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

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

For a simple two-parameter, read-only tool with no output schema and no annotations, the description is nearly complete: it covers tag value semantics, pagination, included fields, and display style. Remaining gaps such as ordering and error handling are small and unlikely to cause incorrect invocation.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains that tag means a tag name, with an example, and the ~30-per-page statement indirectly clarifies the page parameter's purpose. It does not explicitly describe page numbering or bounds beyond the schema's default of 1, so compensation is partial.

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 a specific action and resource: list topics under a named tag, with page size and tag-name semantics. It does not explicitly name sibling tools such as category_topics or latest_topics to differentiate them, but the 'tag' wording and tag-name example disambiguate it from category/latest-based listings.

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

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

The intended use is implied: call this tool when you want topics under a particular tag name, and the description gives concrete tag-value guidance. However, it does not explicitly say when not to use it or point to alternatives like category_topics or latest_topics, so the by-tag vs by-category decision is left to inference.

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

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 useful behavioral details: each item includes category and min_trust_level, and results follow a Markdown table display convention. However, it does not mention pagination behavior, sorting, or whether the operation is read-only, though '获取' implies a read operation.

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 three short sentences with no redundancy. It front-loads the core purpose, then gives parameter values, then output/display conventions. Every sentence adds information.

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

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

For a simple list tool with no output schema or annotations, the description covers the main needs: purpose, period values, returned fields, and display formatting. It is slightly incomplete regarding pagination behavior and result ordering, but these are minor gaps for this tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly enumerates all valid period values (daily/weekly/monthly/quarterly/yearly/all), which is essential. The page parameter is not explained, but its integer type and default of 1 make it reasonably self-evident.

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

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

The description states a specific verb and resource: '获取「热门」话题列表' (get the hot topics list). The period parameter further clarifies scope. It does not explicitly differentiate from siblings like latest_topics, but the 'hot' qualifier is distinct enough to avoid confusion.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as latest_topics or category_topics. The reference to latest_topics is only about display conventions, not selection criteria. Usage is only implied by the tool's name and purpose.

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?

No annotations are present, so the description carries the full disclosure burden. It mentions that results include summaries and jump links, but it does not describe ordering, pagination, time range, or how limit affects results. This is a partial but incomplete behavioral picture.

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 with no filler, and the core action and resource are front-loaded. It lacks structured detail, but it is appropriately sized for the information it provides.

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

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

With no output schema and no annotations, the description leaves important gaps: limit semantics, result shape, pagination, and when to choose this over sibling tools. It is sufficient only for a very basic understanding of the call.

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 0%, so the description must compensate for parameter meaning. It implicitly maps '某用户' to username, but it never explains the limit parameter, its default, or its effect. The compensation is only partial.

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

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

The description uses a specific verb ('获取') and a clear resource ('某用户的发帖/回复活动'), and adds return details (摘要与跳转链接). It is distinguishable from siblings like user_info or search, though it does not explicitly name those alternatives.

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

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

There is no guidance on when to use this tool versus user_info, search, or format_topic. No exclusions or contextual triggers are provided, so an agent must infer applicability from the tool name and minimal description.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the operation is a query (read-only) via the verb '查询', which is a useful trait. However, it does not disclose potential errors, rate limits, authentication requirements, or whether the user must exist. The minimal read-only implication earns a baseline score, but richer context is missing.

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, compact sentence that front-loads the core action and resource, then lists the key data points. It is efficient with no redundant words, though it could be slightly more explicit about the parameter.

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, single-parameter read tool, the description covers the main purpose and the delivered information. However, with no output schema and no annotations, it leaves gaps such as error behavior, whether the user must exist, and the exact output format. It is adequate but not fully complete for an agent encountering this tool for the first time.

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 0%, so the description must compensate. It does not mention the 'username' parameter at all, nor explain how to specify which user to query. The purpose implies that a user identifier is needed, but without explicit parameter semantics, agents may be unsure of the expected format or whether the username is a login name or display name.

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

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

The description clearly states the action ('查询' - query) and the target resource (用户资料 - user profile), and enumerates the data fields returned (trust level, registration/last online time, post count, like count). It is specific and distinct from sibling tools like get_topic or search, though it does not explicitly differentiate itself by name.

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

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

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a valid username, nor any comparison with similar tools like user_actions or whoami. Usage context must be inferred entirely from 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.

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

With no annotations, the description carries the full behavioral disclosure burden. It uses the clear read-only verb '查看' (view), indicating no side effects. It also specifies the source of identity (current cookie) and the data returned (user and trust level). This is adequately transparent for a simple read operation, though it does not describe failure modes like unauthenticated sessions.

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 front-loads the action and resource. Every word earns its place; there is no redundant or extraneous content.

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

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

For a zero-parameter, read-only tool with no output schema, the description conveys the essential purpose and data source. It could specify what happens when no cookie is present or the shape of the returned trust level, but these are minor omissions for such a simple 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?

The tool has zero parameters, and the schema is complete (100% coverage). The description adds contextual meaning by clarifying that the tool operates on the current cookie rather than taking any explicit input. This satisfies the baseline for a no-parameter tool.

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

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

The description states a specific verb ('查看' = view) and a distinct resource: the linux.do logged-in user and trust level associated with the current cookie. This clearly distinguishes it from sibling tools like user_info, which would target arbitrary users rather than the authenticated session.

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 provides no explicit guidance on when to use this tool versus alternatives. There are no stated exclusions, prerequisites, or hints about situations where a sibling tool would be more appropriate. Usage is only implied by the tool's self-evident purpose.

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