search_code

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

No annotations are provided, so the description carries the transparency burden. It clearly discloses the indexing dependency on read_github_file and implies this is a read-only search over local scope. It doesn't mention edge cases like missing index or result ordering, but the core behavioral boundary is clearly communicated.

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 well-structured: one-sentence summary, clear usage instruction, search scope constraint, and a compact Args list. Every sentence serves a purpose and no unnecessary filler is included.

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 three-parameter search tool with an output schema, the description covers scope, prerequisites, when to use, and limitations. It is sufficiently complete for an agent to decide when to invoke this tool and what to expect, although it could mention what happens when there are no previously read files.

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 Args section in the description is essential. It explains all three parameters: query, repo, and top_k, with top_k's default and max limit. The descriptions are not very detailed but they do add practical meaning beyond the bare schema types.

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 '在已读过的代码中搜索关键词' which clearly identifies a search operation scoped to previously read code. It distinguishes itself from sibling tools like search_github or web_search_github by explicitly limiting results to files read with read_github_file.

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 explicit usage guidance: search before writing code and reuse existing implementations instead of writing from scratch. It also clarifies the limitation that only files read via read_get_file are searchable, but it does not explicitly name alternative tools for cases where code has not been read yet.

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