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

With no annotations and no output schema, the description carries the full burden, and it does disclose the single most important behavioral trait: the response is a count, not a file list. It omits secondary traits such as whether the count spans all mounted volumes, empty-result behavior, or performance on large indexes.

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, zero waste, with the differentiating behavior (count only, no file list) front-loaded ahead of the illustrative examples.

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 two-parameter query tool with full schema coverage, the description covers purpose, usage, and the return shape sufficiently. Minor gaps remain on result semantics and limits, but no critical information needed to invoke it correctly is missing.

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 query and folder both documented in the schema along with example syntax. The description adds no parameter-level detail, so the baseline 3 applies since the schema already does the heavy lifting.

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 precise behavior: it returns only the match count and deliberately does not transfer the file list, which cleanly separates it from everything_search. It never names a sibling, so an agent must infer the contrast from the semantics rather than explicit routing.

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?

Concrete example questions («我电脑上有多少个 PDF», «这个目录里有多少张图») make the intended usage obvious, and the count-only framing implies you should pick this over a listing search when you only need a number. It stops short of explicitly naming the alternative tool or stating when this is the wrong choice.

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 behavioral disclosure burden and does well: it discloses real-time filesystem access, index bypass, and explicit handling for nonexistent paths. It does not describe permission requirements or error formats, but the main non-obvious behavioral traits are covered.

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 concise and front-loaded: it immediately states the action, then lists the returned metadata fields, then adds the important index-bypass and nonexistent-path behavior. Every sentence adds useful information with no 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 simple single-parameter metadata tool with no output schema, the description is complete enough: it explains what is returned, that access is real-time, that the Everything index is bypassed, and how nonexistent paths are handled. No significant context needed to call it correctly is missing.

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?

There is one required parameter, and schema description coverage is 100%; the schema already documents the path parameter and gives an example path. The description adds little parameter-level detail beyond indicating that the input is a path, 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 states a specific verb and resource: reading real-time metadata of a path, with enumerated fields (size, creation/modification/access time, is-directory). It also distinguishes the tool from indexed siblings by explicitly saying it does not go through the Everything index.

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 usage context: use this when real-time filesystem metadata is needed and the Everything index should be bypassed. It does not explicitly name sibling alternatives like search, count, or reveal, but the index-bypass distinction provides practical 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，描述需要承担行为说明责任。它披露了会在资源管理器中选择并定位文件，属于会唤起/聚焦 UI 的操作，但没有说明是否打开新窗口、路径无效时的行为或平台限制等细节。

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 的简单 UI 定位工具，描述已覆盖动作、对象、平台环境和典型用途，足以指导调用。缺少的主要是异常路径或窗口聚焦行为等次要细节。

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 覆盖率为 100%，path 参数已在 schema 中说明为“要定位的完整路径”。描述没有在 schema 之外补充路径格式、是否支持相对路径或特殊字符等额外语义，因此按基线为 3。

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?

描述明确给出了具体动作“选中并定位”和对象“文件/目录”，并限定在 Windows 资源管理器环境中，能够与搜索、计数、文件信息等兄弟工具在动作层面区分开。但没有显式点名兄弟工具或说明与它们的选择关系。

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?

“方便用户直接查看或双击打开”暗示了适用场景：需要让用户在资源管理器中查看或打开文件时使用。但没有说明何时不应使用，也没有提及其他替代工具或前置条件，使用边界仍依赖推断。

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，描述承担全部说明义务；它补充了返回内容与“全盘搜索”这一范围提示，暗示结果可能很多。但未说明执行开销、是否只读、翻页行为（offset/limit 仅在 schema 中）或索引未就绪时的表现，信息披露只能算中等。

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?

10 个参数、没有 annotations、没有 output schema，描述通过列举返回字段弥补了输出结构缺失，并说明了查询语法约束。但对 limit/offset 分页语义与搜索代价未作提示，仍有小幅缺口。

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 覆盖率 100%，基础分本就为 3；描述额外强调 query 必须使用 Everything 语法而非自然语言，而这是最关键的必填参数，schema 示例未明确禁止自然语言输入，该提示具有实质增量价值。

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?

States a specific verb and resource（用 Everything 索引做全盘文件/文件夹搜索）并列出返回字段（名称、完整路径、类型、大小、修改时间）。它与 everything_count 的边界略模糊，因为描述里也承诺“返回匹配总数”，但它明确以结果列表为主，仍然能区分。

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?

“只支持 Everything 查询语法，不是自然语言”这句有实际使用约束，能防止 agent 传入自然语言。但既没有说明何时改用 everything_count、everything_file_info 或 everything_reveal，也没有给出使用前提或排除条件，用途边界只能靠推断。

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