doc-bot

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates this is a read-only listing operation ('List all available...'), mentions the periodic checking recommendation for discovering new docs, and describes the return format. However, it doesn't address potential limitations like pagination, rate limits, or error conditions that would be helpful for a robust implementation.

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 efficiently structured with two sentences: one stating the core functionality and return format, and another providing usage guidelines with specific scenarios. Every phrase adds value, with no redundant information or fluff, making it easy to parse while being comprehensive.

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 zero-parameter listing tool with no annotations and no output schema, the description provides strong context about purpose, usage, and return format. However, without an output schema, it could benefit from more detail about the structure of the returned index (e.g., whether it includes file paths, modification dates, or other metadata beyond titles and descriptions).

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 tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters, though it could theoretically mention why no parameters are needed (e.g., 'no filtering options available').

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 the specific verb ('List') and resource ('all available project documentation files'), distinguishing it from siblings like 'search_documentation' (search-based) and 'read_specific_document' (single-document retrieval). It explicitly mentions the return format ('index with titles, descriptions, and metadata'), making the purpose unambiguous.

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 explicit when-to-use guidance with four concrete scenarios: starting work, search failures, exploring unfamiliar codebases, and checking topic coverage. It also implicitly distinguishes from alternatives by suggesting use when 'search fails to find what you need (browse instead)', positioning this as a discovery/browsing tool versus search-based siblings.

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