MCP Tool Database

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It does add that only three actions are currently callable and that legacy async actions are unavailable via mcp.help. This is useful context but lacks details on what each action returns or any side effects beyond the annotations.

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 but poorly structured. It reads as a code snippet with repeated 'mcp.tool.database(action=...)' lines, which are redundant with the tool name and schema. There is no clear prose introduction or hierarchy. While it is concise in length, it wastes space with invocation examples rather than explaining behavior, so it does not earn its place.

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 has three actions and a complex nested payload schema, but no output schema. The description does not explain how the payload fields apply to each action, what outputs to expect, or the distinction between 'current' and 'focused' profiles. The note about legacy actions is helpful but incomplete. Given the complexity, the description is under-specified.

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 the schema already documents all payload parameters. The description adds no extra meaning about how parameters relate to specific actions—for example, whether get_active accepts a payload or what type/format do for list. It only notes that required fields depend on the action, which is already in the schema. Baseline 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 lists three specific actions (list, get_active, get_focused) with brief descriptions, giving a general sense of the tool's purpose. However, it does not clearly state what the tool overall does (e.g., 'manage database profiles') or differentiate it from sibling tools like mcp.tool.collection or mcp.arango. The action names are self-descriptive but the tool's scope is vague.

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 only usage guidance is 'Use mcp.help get for explicit unavailable pages for legacy async actions,' which directs users to another tool for legacy actions. There is no explanation of when to use list vs get_active vs get_focused, nor any mention of alternatives within the current tool or across sibling tools. This is minimal guidance.

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