find_files

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

With no annotations, the description carries full burden. It discloses that the output is a 'token-capped `file` list', indicating result limitations due to token constraints. It also specifies that no language server is required. It does not detail behavior for missing files or performance, but covers key traits for an AI agent.

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 zero wasted verbiage. The most critical information is front-loaded: the purpose, scope, and tone. Every sentence adds value without 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?

Given the tool has three parameters, no output schema, and no annotations, the description covers the core function, usage context (no language server, token cap), and differentiation. It could briefly note recursion under the project root, but overall is sufficient for a file search 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 low (33%), with only 'q' having a description. The tool description mentions 'substring or glob' for 'q', but does not elaborate on 'projectPath' or 'maxResults'. The token-capping hint is generic and not tied to the 'maxResults' parameter, leaving agents to infer meaning.

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 'Find files by name (substring or glob like *Manager.cpp) under the project root', specifying a concrete verb and resource. It explicitly brands itself as 'The sanctioned replacement for Bash `find -name`', distinguishing it from sibling tools focused on code navigation, editing, or search_text.

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 clear context on when to use this tool ('sanctioned replacement for Bash `find -name`') and notes that 'No language server needed', implying efficiency. However, it does not explicitly state when not to use it or compare to alternatives like search_text or grep-like tools, leaving some gaps.

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