Evaluate SQL performance using actual table indexes and execution plans, providing evidence-based optimization suggestions without altering the database.
结合 SQL、真实表索引和执行计划诊断；建议包含证据，不自动修改数据库。
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| analyze | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds that it does not automatically modify the database and that suggestions include evidence. This adds useful behavioral context beyond the annotations, though the analyze parameter's behavior is not disclosed.
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 tool's purpose and then states its non-destructive, evidence-based behavior. Every clause contributes value with no redundancy.
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 diagnostic tool with two parameters and no output schema, the description covers the core intent and safety posture but omits the meaning of 'analyze', the nature of the diagnostic output, and any qualifying conditions. It is minimally adequate but leaves meaningful gaps.
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 carry the semantic weight. It mentions 'SQL' as the core input, but provides no added meaning for the 'sql' parameter and completely omits the 'analyze' boolean parameter, leaving its purpose ambiguous.
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 states a specific verb ('diagnose') and resource (SQL combined with real table indexes and execution plans), and signals evidence-based suggestions. It is distinguishable from siblings like explain, though it does not name the distinction explicitly.
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 context is implied: use this when you need to diagnose SQL using indexes and execution plans. However, there are no explicit when-to-use, when-not-to-use, or alternative tool comparisons, leaving the agent to infer routing from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.