db_repair

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

With no annotations, the description carries the full burden of behavioral disclosure, and it fails to provide meaningful detail. It does not state whether repair is destructive or irreversible, what the confirm flag controls, or what happens to the database during repair. The 'confirm: Required' line is misleading because the schema marks confirm as optional with default false, so the description actively misinforms about behavior.

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 short and front-loaded, but the brevity is under-specification rather than disciplined conciseness. The Args block mostly duplicates the schema and includes a false 'Required' flag. Every line should add value, and two of the three lines fail to do so reliably.

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 maintenance and potentially destructive operation with no annotations, this description is incomplete. It does not explain the effect of the confirm flag's default false, when repair should be run, or what the output means. The presence of an output schema does not compensate for the missing safety and usage context.

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 description must compensate, but it adds almost nothing beyond the schema's titles. 'database: Name' just restates the parameter name, and 'confirm: Required' contradicts the schema, which shows confirm is not required and has a default of false. It never explains what a true confirm value does or what the database name should reference.

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?

States a specific verb and resource: 'Repair a database.' It conveys the operation's intent and is distinguishable at a high level from read-only database tools like db_info or db_list. However, it doesn't explain how repair differs from sibling maintenance tools like db_check or db_optimize, so it lacks full sibling differentiation.

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 db_repair versus db_check, db_optimize, or other database maintenance tools. It does not state prerequisites, recommended conditions, or when repair should be avoided. No explicit or even clearly implied usage context is provided beyond the verb 'repair'.

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