Loading ToolBench
An MCP server that provides tools to query and interact with Drupal databases, supporting multiple database drivers (MySQL, PostgreSQL, SQL Server, Oracle) and parsing Drupal settings.php files.
This server has severe definition quality issues across all dimensions. While tool schemas ARE visible and mostly present, they suffer from critical naming and parameter design flaws. Three of five tools require a dummy 'random_string' parameter with no functional purpose, a major anti-pattern that violates single-responsibility principle and wastes LLM reasoning cycles. Descriptions are present but generic and lack context for tool selection. No output schemas are documented, forcing LLMs to infer result structure. Error handling exists in code but is not surfaced in tool definitions. Parameter descriptions are minimal.
Fetches detailed information for a specific Drupal node by its ID.
Fetches detailed information for a specific taxonomy term by its ID.
Fetches detailed information for a specific Drupal user by their ID.
Lists all available Drupal content types (node types).
Lists all taxonomy vocabularies in Drupal.
Dummy parameter anti-pattern: drupal_list_content_types and drupal_list_vocabularies require 'random_string' with description 'A dummy string argument required by the tool signature.' This serves no functional purpose, violates the single-responsibility principle, and forces LLMs to reason about meaningless input. This pattern should be removed entirely.
No output schemas documented. Tool definitions do not declare what fields the response contains, what types they are, or how downstream tools should interpret results. LLMs cannot plan tool chains without knowing what a tool returns. Baseline expectation: 100% of A-tier tools document return types.
Generic descriptions lack context for tool selection. 'Lists all available Drupal content types (node types)' is functional but does not guide LLMs on when to call this vs other discovery tools, what the result structure is, or how to use results in downstream operations. Target: 50 - 200 chars with WHAT, WHEN, and HOW.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'random_string' in list_* tools violates naming clarity. Parameter names must convey what they control. A 'random_string' with no context is not actionable. Even dummy parameters should have a clear semantic name or be removed entirely.
No pagination support visible. If these tools return large lists (e.g. hundreds of content types, taxonomies, or users), no limit, offset, or cursor parameters are declared. This risks context window exhaustion. Baseline: paginated results include limit, offset/cursor, and total_count.
No error handling guidance in tool definitions. The code includes error classification (ConnectionError, ValueError, generic), but these error messages and recovery paths are not documented in the tool schema. LLMs do not know what errors are retryable or how to recover.
ID-only parameters without fallback to human-readable names. Tools accept nid, tid, uid (system IDs) but do not declare support for name-based lookup. Users say 'get the user Jack', not 'get user 42'. Agents must either know system IDs or make extra discovery calls.