Doris MCP Server

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that results are 'returned' and 'executed by the client,' but lacks critical details: whether queries are read-only or can modify data, authentication requirements, error handling, result format, or any rate limits. For a SQL execution tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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 clear sections ([Function Description] and [Parameter Content]) and uses bullet points efficiently. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating the sections more fluidly, but overall it's appropriately sized and front-loaded with the core purpose.

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 complexity of a SQL execution tool, no annotations, and no output schema, the description is moderately complete. It covers parameters thoroughly but lacks behavioral context (safety, permissions, result format) and doesn't explain what 'return result command' means or how results are structured. For a tool that could potentially modify data, this leaves important gaps despite good parameter documentation.

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 fully compensate. It does this excellently by providing clear semantics for all 4 parameters: sql (required SQL statement), db_name (optional target database with default behavior), max_rows (optional row limit with default), and timeout (optional timeout with default). Each parameter's purpose, optionality, and defaults are clearly explained beyond what the bare schema provides.

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: 'Execute SQL query and return result command (executed by the client).' This specifies the verb ('Execute SQL query') and resource ('SQL query'), distinguishing it from sibling tools that are all read-only metadata retrieval functions (like get_db_list, get_table_schema). However, it doesn't explicitly contrast with those siblings beyond the different action.

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 this tool versus alternatives. It doesn't mention that siblings are for metadata retrieval while this is for actual query execution, nor does it discuss prerequisites like database connectivity or permissions. The only implicit usage context is that it executes SQL, but no explicit when/when-not instructions are provided.

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