Loading ToolBench
MCP servers for Azure DevOps and SQL Server integration, providing tools for project management, work items, pull requests, repositories, and database operations
NeuroMCP exposes 3 SQL Server tools with partial schema coverage and weak descriptions. All tools have descriptions (10-50 chars), but lack depth on context, error handling, and recovery guidance. Parameter schemas are present but incomplete, databaseConfig objects lack proper type constraints and validation rules. The ExecuteSql tool accepts a generic 'parameters' field without format guidance, inviting hallucinated SQL injection payloads. No error handling guidance, no output schemas documented, no idempotency markers. Tool names are reasonable (verb_noun pattern) but descriptions fall short of production quality. Security concerns: passwords exposed as tool parameters (anti-pattern per pattern:secret-injection). No per-tool audit or permission gates.
Execute an SQL query on the MSSQL server
Get information about the current database connection
Test a database connection with the provided configuration
Passwords and credentials exposed as tool parameters (password, userId in databaseConfig). Credentials must never appear in parameters, they leak into agent traces, logs, and prompt history. Use server-side secret injection via environment variables or vault instead.
ExecuteSql accepts a 'parameters' field (object, nullable) with no format guidance, type constraints, or validation rules. This invites LLMs to pass arbitrary payloads, risking SQL injection. Descriptions must specify expected parameter format and constraints.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract data without knowing return field names and types. GetConnectionInfo and TestConnection return Dictionary<string, object> with no schema specification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Descriptions are minimal (10-50 chars) and lack context on WHEN to use each tool, WHAT prerequisites exist, and what side effects occur. GetConnectionInfo: 'Get information about the current database connection', does it test connectivity? Return sensitivity details? Is it read-only?
No error handling guidance. If ExecuteSql fails (SQL syntax error, permission denied, timeout), the response contains no actionable recovery steps for the LLM. Pattern:recovery-guide requires error responses to guide next steps.
databaseConfig parameters (server, database, userId, password, trustServerCertificate, integratedSecurity) lack descriptions at the parameter level. Only top-level 'databaseConfig' is described. LLMs cannot understand what each sub-field controls or when to use integratedSecurity vs userId+password.
No idempotency markers (idempotentHint) on GetConnectionInfo and TestConnection. Agents retry on ambiguous failures, without idempotency signals, LLMs cannot safely assume repeated calls are safe.
ExecuteSql lacks a destructiveHint annotation, yet it performs WRITE operations. MCP spec requires tool annotations to signal side effects. LLMs need to know this tool modifies state and should not retry blindly.
No mention of pagination, result limits, or result caps. If ExecuteSql returns 10,000 rows, the response balloons the context window. Pattern:paginated-result and mxe:enforce-result-limits require cap + pagination support.