Loading ToolBench
DataMCP is a Model Context Protocol server for data operations with PostgreSQL query execution, data analysis, and environment management.
DataMCP provides 5 tools with inconsistent quality. Tool naming is clear and verb-based (get*, set*, query, analyze*, health*), following conventions well. However, input schemas are incomplete: some tools have no schema at all (getEnvironment, healthCheck return {}, effectively no parameters), while others lack Zod schema visibility for key parameters. Descriptions vary in quality: query and analyzeJson have verbose, helpful descriptions; setEnvironment and healthCheck are adequate; getEnvironment is minimal. Parameter descriptions are partially present but the JSON input schema visibility is limited in the source excerpt. Most critically, the code shows Zod schema definitions (z.string().describe(...)) but the inputSchema objects passed to registerTool() do not display the transformed Zod objects, making it impossible to verify whether full type annotations are visible at runtime. Output schemas are not documented anywhere. Error handling is basic (try-catch with error.message) but lacks recovery guidance or error categorization. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Tools are largely single-responsibility and composable, which is good.
Analyze and explore JSON data files with automated data profiling, statistical analysis, and AI-powered insights. Handles large files efficiently with sampling, generates interactive analysis descriptions, and provides comprehensive data summaries.
Get the current database environment. Returns the name of the currently active environment.
Perform a health check on the current database environment to verify the connection status and connectivity.
Execute read-only PostgreSQL queries and return results as structured JSON. Supports SELECT, WITH, and EXPLAIN statements only for security. ALL QUERIES MUST INCLUDE A LIMIT CLAUSE for safety. Results are limited to 100 rows by default to prevent memory issues. Required parameters: - query: The SQL query to execute (SELECT statements only, MUST include LIMIT clause) Example: {"query": "SELECT * FROM users WHERE active = true LIMIT 10"}
Set the environment for the database, we support multiple environments for the same database. The default environment is 'default'. The dev environment is for development and the prod environment is for production. You can use this tool to switch between environments. Note: The environment will be reset to 'default' after 10 minutes to prevent accidental changes.
getEnvironment and healthCheck have empty input schemas ({}), providing zero parameter guidance to LLMs.
Tool output schemas are entirely undocumented. LLMs cannot predict what fields to expect in responses, hindering multi-tool composition and forcing the LLM to parse responses structurally.
No tool annotations present. query and analyzeJson should carry readOnlyHint=true. setEnvironment should carry destructiveHint=true. These annotations help agents plan safer interaction patterns.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Error handling is generic. Errors return raw error.message without recovery guidance, error classification, or constraint violation details. E.g., query rejects queries without LIMIT but returns only 'All queries must include a LIMIT clause', no suggestion to try with LIMIT 10.
getEnvironment and healthCheck descriptions are under 50 characters and lack clarity. getEnvironment says 'Get the current database environment. Returns the name of the currently active environment.' but does not explain WHEN to call it or what you can do with the result.
query parameter 'limit' lacks min/max bounds in description. The code enforces max: 5000, but the description only says 'default: 100, max: 5000'. No minimum is stated, leaving LLMs free to pass 0 or negative values.
analyzeJson parameter 'maxCycles' lacks min/max bounds in code validation. Description says 'default: 3, max: 5' but no minimum. The code should validate >= 1 and document it.