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

With no annotations, the description carries full transparency burden. It discloses capabilities (multi-step analysis, cross-table reasoning, markdown reports) and restrictions (credentials handled server-side). However, it omits behavioral traits like whether it modifies data (assumed read-only but not stated), performance characteristics, or rate limits. Adequate but not comprehensive.

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 well-structured with sections (Capabilities, When to Use, Effective Prompts, Restrictions) and a clear title. However, it is lengthy and includes redundant guidance (e.g., 'Be specific about metrics'). Some sentences could be condensed. It is front-loaded but not optimally concise for an MCP tool description.

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?

Given the tool's complexity (nested objects, no output schema, 4 parameters), the description is incomplete. It lacks parameter documentation, does not specify return format beyond 'markdown reports', and omits error handling or output schema details. The 'When to Use' is helpful but does not compensate for missing parameter semantics and output 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%. The description adds no information about parameters beyond the schema. It fails to explain what 'prompt', 'celpApiKey', 'databaseConfig', or 'databaseConnectionId' represent. The only hint is the restriction about credentials, which vaguely relates to 'celpApiKey' and 'databaseConfig.password'. This is insufficient for a tool with 4 parameters and complex nested objects.

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's purpose: 'translates natural language into multi-step SQL analysis plans and executes them against databases.' It explicitly labels itself as for 'complex analytical questions requiring more reasoning,' distinguishing it from sibling 'query-database-turbo' which implies a faster, simpler variant. The verb 'translates and executes' plus the resource 'databases' is specific. Good 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 'When to Use' section provides clear context: complex questions, multi-table analyses, accuracy over speed, detailed insights. It also includes 'Restrictions' warning against sending credentials. However, it does not explicitly name sibling alternatives or state when NOT to use (e.g., simple queries should use query-database-turbo). The guidance is solid but lacks explicit exclusion criteria.

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