Loading ToolBench
An intelligent MCP server that converts natural language queries into SQL database queries or API requests. Supports multiple database systems and OpenAPI-compatible APIs with security controls and schema introspection.
Dynamic Smart MCP presents moderate quality tool definitions with significant gaps in parameter validation, output schema documentation, and error handling guidance. Tools have reasonable naming and some descriptive text, but lack the rigor needed for production use. Parameter schemas are incomplete (missing type information), descriptions lack LLM-optimized format and actionable context, and error responses do not guide recovery. The server exposes a WRITE-capable tool (call_api) without visible permission checks or scope declarations. Code inspection reveals security-conscious response sanitization but insufficient input validation and no per-tool permission gating. Average tool score across 7 tools is 42/100.
Execute an API request generated from natural language. Args: natural_language: A request in plain English (e.g., "Get user 123") Returns: JSON string with API response or error
Get the available API endpoints and structure.
Get database schema information. Note: In production mode (security.hide_database_details = true), this tool will return a generic message instead of actual schema.
Get example natural language queries supported by this tool. Returns a list of example questions you can ask, organized by category (basic queries, filtering, aggregation, joins, complex analytics, etc.)
Execute a read-only SQL query generated from natural language. This tool converts natural language questions into SQL queries and executes them against the connected database. It supports filtering, aggregation, joins, sorting, date operations, and complex analytics. Safety: Only SELECT queries are allowed. No data modifications possible.
No output schemas documented for any tool. LLMs cannot anticipate return structure or plan downstream tool calls. E.g., query_database returns 'JSON string' but structure is opaque.
call_api is a WRITE tool with no visible permission checks, scope declarations, or dry-run support. Tool description does not state what permissions are required or what destructive actions are possible.
Input parameter 'natural_language' in query_database and call_api lacks constraints (length, character set, SQL injection prevention). Descriptions do not state format expectations or examples of valid input.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Reload the OpenAPI specification.
Refresh the cached database schema. Use this after making schema changes (adding/removing tables or columns) to update the tool's understanding of your database structure.
Error responses (in code) return JSON with generic 'error' field but do not guide LLM on recovery. E.g., 'Failed to parse query' does not suggest calling get_database_schema first or provide valid query examples.
Tool descriptions are generic and do not provide LLM-optimized guidance on WHEN to call each tool, dependencies between tools, or expected input/output structure. E.g., get_database_schema description does not say 'Call this before query_database.'
No pagination parameters (limit, offset, page) visible in schema for query_database, despite returning potentially large result sets. Code shows no built-in result capping mentioned in tool definition.
Input schemas lack type constraints. The 'natural_language' parameter is defined as {"type": "string", "description": "..."} with no length bounds, regex patterns, or enums. Leaves validation to runtime.
Tool compositions are not guided. E.g., if query_database fails with 'Schema not found', error should suggest calling get_database_schema. Current code returns generic error.