Loading ToolBench
Enterprise-grade Model Context Protocol (MCP) server implementation for Apache Doris with support for SQL query execution, schema introspection, metadata management, monitoring, analytics, and data governance
The server defines 8 tools with good naming conventions (verb_noun style: exec_query, get_table_schema, get_db_table_list, etc.). All tools have descriptions present and schemas with typed parameters. However, descriptions are inconsistent in quality and detail. The exec_query tool has a detailed description explaining the three-part naming requirement for catalog federation, which is excellent domain-specific guidance. Other tools like get_db_list have minimal descriptions ('Get a list of all database names on the server'). Parameter descriptions are present but terse, most are 5-15 characters, below the 72-character baseline for A+ tools. No enum constraints are used despite tools accepting limited values (e.g., catalog_name could benefit from enumeration if known at schema definition time). Output schemas are not documented; only input schemas are visible. Error handling and recovery guidance are absent from all tool descriptions. All tools are marked READ_ONLY risk, which is good for security transparency, but no tool annotations (readOnlyHint/destructiveHint) are explicitly visible in the schema metadata. Parameter constraints are minimal: max_rows and max_bytes have numeric bounds (minimum specified), timeout has a minimum, but most other parameters lack validation rules or format hints.
Execute SQL query and return result command with catalog federation support. SQL statement to execute MUST use three-part naming for all table references: 'catalog_name.db_name.table_name'. For internal tables use 'internal.db_name.table_name', for external tables use 'catalog_name.db_name.table_name'
Get a list of all database names on the server
Get a list of all table names in the specified database
Get audit log records for a recent period
Get comment information for all columns in the specified table
Get the comment information for the specified table
Parameter descriptions are too brief (5-15 chars). Baseline for A+ tools is 72 chars. Most parameters lack actionable guidance: db_name, catalog_name, table_name are self-explanatory but lack context on when to use them or how they interact. Example: 'Catalog name' does not explain how to obtain a valid catalog_name, whether it defaults to 'internal', or whether it's required.
Output schemas are not documented. The rubric requires documentation of the structure agents should expect (fields, types, cardinality). For example, exec_query returns a 'result command' but the schema of that result is not defined. Agents cannot plan downstream tool calls or extract the right data without knowing output fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get index information for the specified table
Get detailed structure information of the specified table (columns, types, comments, etc.)
No error handling guidance. Tool descriptions do not explain what errors agents should expect (e.g., 'Invalid catalog', 'Table not found'), what those errors mean, or how to recover. No recovery guides like 'If catalog not found, call get_db_list() first' are present.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). While all tools are marked Risk: READ_ONLY in the metadata, no explicit MCP schema annotations are documented. Current spec expects structured annotations in the tool definition.
Parameters lack constraints and format hints. Most parameters (db_name, table_name, catalog_name) are free-form strings with minimal guidance. No regex patterns, enums, or length limits are documented. For example, catalog_name accepts 'internal' or external catalog names, but the description does not list valid options or explain the distinction.
No pagination documented for list-returning tools. get_db_table_list, get_db_list, and get_recent_audit_logs return lists but do not describe limit behavior, whether they support pagination, or what happens if results exceed some threshold. Agents cannot handle large result sets properly without explicit pagination guidance.
exec_query tool has unusual parameter semantics. It accepts both 'db_name' and 'catalog_name' as optional parameters, but the description states SQL must use three-part naming. It is unclear whether these parameters override the names in the SQL, supplement them, or are mutually exclusive with SQL-embedded names. This ambiguity violates the param-relationships rule.