Loading ToolBench

Reading the current corpus…

scansca MCP server · D · ToolBench

scansca

A Model Context Protocol server for database introspection and query execution. Provides tools to list schemas, tables, and execute SQL queries against registered databases.

<=2025-11-25STREAMABLE_HTTP4 tools

51/100

Definition Quality60

Protocol Readiness62

Supportability27

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Scansca provides 4 database introspection tools with basic schemas and descriptions. All tools have input schemas with typed parameters and descriptions, meeting minimum requirements. However, descriptions are generic (10-50 chars), lack context on WHEN to use each tool, and omit dependency hints. No output schemas documented. Parameters lack enums, ranges, or format constraints. Error handling is absent, no guidance on recovery or actionable error messages. Tools follow verb_noun naming (execute_query, list_schemas) but descriptions don't explain distinctions or prerequisites. No pagination support despite list_* tools. Security: no mention of SQL injection prevention, rate limiting, or audit logging despite executing arbitrary SQL queries.

Tools (4)

execute_queryread onlysource verified57/100

Execute a SQL query on a registered database

get_table_inforead onlysource verified57/100

Get detailed information about a database table

list_schemasread onlysource verified62/100

List all schemas in a database

list_tablesread onlysource verified62/100

List all tables in a database schema

Issues (5)

CRITICALtool ↗

No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., column names, data types, constraints). Agents must guess response structure.

execute_querylist_schemaslist_tablesget_table_info

HIGHtool-description ↗

Descriptions are too short (10-50 chars) and lack context. 'Execute a SQL query' does not explain WHEN to use this vs list_tables, what parameters are required, or what happens on error. Baseline: 194 chars average for A+ tools.

execute_querylist_schemaslist_tablesget_table_info

CRITICALtool-gateway ↗

execute_query accepts arbitrary SQL with optional params array but no validation, injection prevention, or error guidance. No mention of read-only enforcement despite READ_ONLY risk label. Agents could pass malicious queries.

execute_query

HIGHpaginated-result ↗

Recommendations

Add output schemas for all tools. Example for list_tables: {type: 'object', properties: {tables: {type: 'array', items: {type: 'object', properties: {name: {type: 'string'}, schema: {type: 'string'}, row_count: {type: 'integer'}}}}}}.
Expand descriptions to 100-200 chars with WHEN/WHY context. Example: 'List all tables in a schema. Call this after list_schemas() to discover available tables before querying. Returns table names and metadata.'
Add SQL injection prevention: validate query syntax, reject DDL/DML if read-only mode is enforced, return actionable errors like 'Only SELECT queries allowed. Got: INSERT INTO...'
Implement pagination for list_* tools: add limit (default 20, max 100) and offset parameters. Return total_count and has_more in response. Document in description: 'Results limited to 20 per page.'
Add parameter constraints: database and schema as enums (fetch from server config), query as string with pattern validation, params as array of strings with length limits.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

51/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	51	<=2025-11-25	v2