搜內容

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 substantial context: skip rules for specific directories and large files, and a nuanced fallback (degrade to literal matching, return literal_fallback warning when there are hits, report INVALID_REGEX only on zero hits). This exceeds what the schema provides. Minor gaps remain (return format, case sensitivity), keeping it just below 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 a compact, single-sentence block with no wasted words — every clause (search method, skip rules, fallback behavior, error reporting) earns its place and the core purpose is front-loaded. It is slightly dense as one run-on sentence, but efficient overall.

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 core search mechanics, skip rules, and fallback/error behavior are well covered, which is the heart of this tool. However, with no annotations and no output schema, an agent is left without the return format, the meaning of limit, and root usage details. For a 3-parameter tool these are notable gaps, making the description adequate but not 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?

Schema description coverage is 33% (only query has a description). The description's regex-fallback detail adds genuine meaning for the query parameter. However, root and limit semantics remain unexplained in both schema and description — what limit counts (matches per file vs total) and root's traversal scope are unclear, so the description only partially compensates for the low coverage.

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+resource: '正則逐行搜尋檔案內容' (regex line-by-line search of file content). The skip rules (.git, node_modules, >1MB) further characterize behavior, clearly distinguishing it from sibling fs_find (filename-based search) and fs_read (file read). An agent can tell it apart from the filesystem siblings without opening other schemas.

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 case (searching text inside files by regex) is implied by the description's mechanism, making selection from filesystem siblings reasonably inferable. However, there is no explicit when-to-use guidance, no named alternative (like fs_find vs fs_grep), and no stated exclusions or preconditions. The usage context is clear but not articulated.

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