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

With no annotations provided, the description carries the full burden. It discloses that the tool is heuristic and not a defect detector, which is useful. Yet it does not mention side effects, return format, or operational details like git requirements, leaving several behavioral aspects implicit.

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 two sentences, front-loaded with the action and object, and includes a clarifying caveat. No filler or redundant information is present.

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 tool is simple with only two parameters. The description conveys purpose, heuristic nature, and a limitation, which is sufficient for a basic heuristic tool. However, the lack of output schema and annotations means it does not specify return format or error conditions, so it is not fully 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?

The schema describes cwd as 'Local repository path. No network access is used.' but leaves limit without description. The tool description does not explicitly explain limit, though the phrase 'most often' implies a count. Thus it adds minimal meaning beyond the 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?

The description uses a specific verb ('Find') and a clear resource ('files that appear most often in recent repository history'), distinguishing it from sibling tools like repository_summary and recent_changes. The added caveat that it is a heuristic for review focus further sharpens its identity.

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?

It states the tool is for review focus and explicitly says it is not a defect detector, giving a clear when-not direction. However, it does not name alternative tools or provide explicit scenarios, so it stops short of a 5.

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, the description must disclose behavioral traits. It mentions 'local' and 'bounded output,' hinting at no network use and a limit, but it does not explicitly state that the operation is read-only, revertible, or what side effects (if any) it has. This is insufficient for a tool without annotation support.

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 single, clear sentence with no unnecessary words. 'Bounded output' packs a useful constraint into two words. It is appropriately concise and front-loaded with the action and resource.

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?

There is no output schema or annotations, so the description should explain what the output looks like and how parameters affect behavior. It does not describe return fields, pagination, or the effect of the limit parameter. It also fails to mention the cwd parameter, leaving important context missing for a tool of this complexity.

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 schema description coverage is 50% (cwd has a description, limit does not). The description adds only the phrase 'bounded output' which vaguely relates to the limit parameter but does not explicitly explain how to use either parameter or what cwd does. It adds minimal value beyond the 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?

The description "List recent local Git commits with bounded output" clearly states the tool's action (list), the resource (recent local Git commits), and a key constraint (bounded output). This distinguishes it from sibling tools like repository_summary or file_hotspots, making its 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools. The description simply states the function, leaving the agent to infer usage context from the name alone.

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, the description carries the burden of behavioral disclosure. It states the operation is 'Read', implying a non-mutating action, and specifies it operates on a local Git repository. However, it does not explain potential failure modes, output format, or side effects beyond the basic premise. This is adequate for a simple read tool but not rich.

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 single sentence with no redundant information. It front-loads the core action ('Read') and lists the specific data items returned, making it highly concise and easy to parse.

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 tool with one parameter, no output schema, and no annotations, the description sufficiently explains what the tool does and what it returns (branch, working-tree, remote names, latest commit metadata). It could mention caveats like requiring a valid Git repository, but the parameter schema already indicates 'local repository path', making the description adequately 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?

The input schema is fully described (100% coverage) with a clear description for the cwd parameter ('Local repository path. No network access is used.'). The tool description adds little beyond what the schema already provides, meeting the baseline for good schema 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 clearly states the tool reads branch, working-tree, remote names, and latest commit metadata from a local Git repository. This is a specific verb+resource+scope that distinguishes it from sibling tools like recent_changes or file_hotspots, which focus on different aspects of repository history.

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 no guidance on when to use this tool versus its siblings (recent_changes, file_hotspots, top_level_hygiene). It simply describes what it does without giving context or exclusions, leaving the agent to infer usage.

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 full burden. It discloses a key behavioral trait ('without reading file contents') and implies read-only operation through 'Check'. However, it does not mention return format, side effects, or any limitations beyond top-level scope.

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 single, compact sentence that front-loads the verb 'Check' and immediately specifies what is checked. No word is wasted, and it is well-structured.

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 tool with one parameter and no output schema, the description adequately covers the purpose and a key behavioral constraint. It could mention whether it assumes a git repository, but overall it is sufficiently complete for typical use.

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% for the single parameter 'cwd', and the description adds no additional parameter semantics. The parameter is already documented in the schema, so a baseline score of 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 uses a specific verb 'Check' and clearly lists the exact resources: 'top-level large files, .gitignore presence, and working-tree dirtiness'. It also adds a distinguishing constraint 'without reading file contents' which helps differentiate it from sibling tools like repository_summary or file_hotspots.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the description.

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