Manage Database

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

The description explicitly notes that restore is destructive and that the force parameter allows overwriting during restore or merge, which is valuable behavioral information. However, the annotation destructiveHint=false directly contradicts this, as the tool can perform destructive operations. This is a critical inconsistency, and the description fails to align with the structured metadata, warranting a score of 1.

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 but effectively packs information: it states the general purpose and then lists all six actions with brief parenthetical clarifications. It is concise and front-loaded, though the dense list could be more readable with bullet formatting. Every phrase adds information without waste.

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?

With no output schema and a tool that includes destructive actions, the description should explain behavior in more depth—such as where backups are written, prerequisites for restore, how merge resolves conflicts, and what the audit reports. It only names actions without detailing side effects, expected returns, or edge cases, leaving substantial gaps for an agent.

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%, so baseline is 3. The description adds significant value by enumerating the valid values for the action parameter (backup, restore, audit, merge, branch_diff, branch_merge), which the schema leaves vague as 'the database administration or VCS sync action to execute.' For other parameters, the schema descriptions suffice, but the action list is a notable contribution.

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 defines the tool as handling SQLite database maintenance, backups, integrity checks, and Git VCS sync, and it lists six specific actions. This distinguishes it from sibling tools like manage_nodes or manage_sessions, which focus on other resources. However, it is a multi-action tool, so the purpose is broad rather than a single verb, preventing a perfect score.

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 implies usage contexts—database maintenance and VCS state sync—but does not explicitly compare to alternatives or state when not to use it. While the tool name and action list make its domain clear, there is no direct contrast with sibling tools or exclusion criteria, so guidance is only implied, not explicitly provided.

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