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

没有 annotations，描述承担了行为披露的主要责任。描述指出返回的是完整纯文本正文，这是一个有用的行为信息；但未提及权限要求、错误场景（如 doc_id 不存在）或响应结构。对于简单读取工具而言，信息基本够用但有一定保留。

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?

描述只有两句话，第一句直接说明核心功能和输出形式，第二句给出参数格式与来源。没有冗余信息，核心内容前置，非常适合 agent 快速理解。

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、属于简单的文档获取操作，描述已覆盖输入来源、输入格式和输出内容，且与兄弟工具的协作关系也已标明。对于这种复杂度，说明是完整的。

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 对 doc_id 的描述覆盖率为 100%，描述在此基础上额外补充了 doc_id 的形态示例（guides/deployment/deployment_guide）以及获取来源（search_docs/list_docs 的 id 字段），提供了超出 schema 的来源语义，能帮助 agent 正确构造参数。

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?

描述明确说明了工具的功能：获取指定文档的完整正文（纯文本），动作为“获取”，资源为“文档正文”。这与 search_docs / list_docs 的检索和列表职能明显区分，且指出了 doc_id 的来源，能够帮助 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?

描述说明 doc_id 可从 search_docs / list_docs 结果的 id 字段获取，隐含了先搜索/列表、再获取正文的使用链路。虽然没有明确写出“不要用 search_docs 获取正文”之类的排除条件，但上下文已经足够清晰。

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 behavioral transparency burden. It discloses the deterministic sorting, the expected item fields (title / description / preview / section), and pagination support. It does not cover boundary behaviors like empty results or total count disclosure, which holds it back slightly from a 5.

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 brief sentences, with the core purpose stated first, followed by the sorting/format specifics and pagination note. There is no filler; every sentence contributes new information, making it both concise and high-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?

The tool is simple (two optional params, no annotations, no output schema). The description supplies the essential behavioral context: what is listed, the ordering, the item fields, and pagination. An agent can correctly invoke the tool with no missing pieces; the only minor absence (top-level response envelope) is predictable for a list 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?

The input schema already provides complete coverage of both parameters (limit: default 10, max 100; offset: default 0, min 0) with descriptions. The tool description only confirms offset pagination support but does not add meaning beyond the schema, so the baseline 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 states a specific verb and resource ('list Neo-MoFox official docs') and provides concrete detail on sorting and per-doc fields. It distinguishes itself from sibling tools (search_docs, get_doc) by describing exactly what an index-style listing operation returns, not a search or a single-doc fetch.

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 clear context for when to call list_docs: to retrieve the official docs in a paginated, section-ordered manner, with the deployment guide first. It does not explicitly mention when to prefer search_docs or get_doc, which would elevate it to the full 5 criterion, but the intended usage is clear without exclusion notes.

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 — and it delivers: it discloses query tokenization, ranking by number of matched keywords, OR-style matching (at least one keyword), matched fields, and the absence of full content in results. This goes well beyond a minimal 'search docs' statement.

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 dense sentences cover purpose, query semantics, ranking, matching scope, result limitations, and the get_doc alternative. There is no filler, and the most decision-relevant behavior 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?

The description covers the core behavior, ranking, matched fields, result brevity, and the flag to get_doc for full content. It is slightly less complete regarding list_docs as an alternative and the exact shape of returned result items, but these are minor for a search tool with fully described parameters.

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 baseline is 3. The description adds substantial value beyond the schema by explaining how the query parameter is interpreted (split by whitespace, ranked by matched keyword count) and what the query can match (title/summary/preview/category/id/path).

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 action ('检索关键词') and a specific resource ('Neo-MoFox 官方文档'), then explains exactly what is matched and how results are ranked. It also differentiates itself from get_doc by explicitly noting that it returns excerpts rather than full content.

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 clear context: use this to search docs, and if full text is needed, use get_doc. It does not explicitly mention when to choose list_docs over this tool, but the search-vs-listing distinction is reasonably inferable from the context.

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