Loading ToolBench
MCP server that exposes database operations as tools, enabling interaction with Neurelo Connect backend for executing workflows, queries, and managing database targets
Neurelo Connect MCP exhibits significant quality gaps across naming, description completeness, and parameter documentation. Of 9 tools, most lack meaningful parameter descriptions, and several have ambiguous naming patterns. The dynamically generated query_* tools compound this issue, their definitions are inferred rather than explicitly visible in source code. Tool descriptions are present but often generic (averaging ~60 chars, well below the 194-char baseline for A+ tools). Critical parameter documentation is missing: 'target' parameters in system_get_database_status, system_get_database_schema lack descriptions (marked as null in schema); raw_query and raw_readonly_query have minimal parameter guidance. The call_endpoint tool accepts an untyped 'object' for parameters without explaining what structure is expected or what fields are valid. Error handling is absent, no recovery guidance, no categorization of failures, no actionable error messages. No tool annotations (readOnlyHint/destructiveHint) are visible, limiting agent safety reasoning.
Call a given stored query/playbook endpoint with the provided parameters
Defined Query endpoint tools dynamically generated from endpoint metadata
Execute a raw query against a database with read/write access. Can only be called if the database allows raw read/write queries.
Execute a raw query against a database with readonly access. Can only be called if the database allows raw readonly queries.
Get the schema for a given database
Get the status of a given database
Critical: Parameter 'target' in system_get_database_status, system_get_database_schema lacks description (null in schema). LLMs cannot determine what value to pass.
Critical: call_endpoint accepts 'parameters' as untyped object with vague description ('Record of string keys to union of string, number, or boolean values'). No documentation of valid parameter names, required vs optional fields, or validation rules. Agents cannot construct valid requests.
High: Tool descriptions are generic and do not explain WHEN to use each tool or HOW they relate. E.g., system_get_database_status vs system_get_status, the distinction is unclear. raw_readonly_query vs raw_query, when should an LLM pick one vs the other?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get all available endpoints for stored queries and workflows
Check if all databases are running
List all the available databases
High: Dynamically generated query_* tools are inferred rather than explicitly visible in source code. No tool registration code shown; schemas are inferred to be 'dynamically generated based on endpoint parameters.' This violates the requirement that tool definitions be explicitly declared and verifiable.
High: No error handling guidance. Tools provide no recovery instructions, no categorization of errors (retryable vs user-fixable vs fatal), and no actionable error messages. An LLM receiving a failure has no guidance on what to do next.
Medium: No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. raw_query is marked Risk:WRITE but no annotation prevents accidental repeated execution. Agents lack explicit safety signals.
Medium: Tool naming lacks clarity in distinguishing similar operations. 'system_get_database_status' and 'system_get_status' are not clearly differentiated. 'raw_readonly_query' vs 'raw_query' relies on the LLM reading the description; the names themselves could be clearer (e.g., 'execute_safe_query' vs 'execute_mutation_query').
Medium: Output schemas are not documented. Tools like system_list_databases, system_get_endpoints, and raw_query do not specify what fields are returned or their types. LLMs cannot plan downstream operations without knowing the response structure.