Loading ToolBench
MCP сервер для безопасной работы с базами данных Skyeng Platform. Поддерживает все предметы платформы с локальным хранением кредов
The server implements 3 database query tools with Russian descriptions. All tools have descriptions (50-100 chars, meeting the 10-1024 minimum), but analysis reveals significant gaps in schema completeness, parameter documentation, and error handling. Tool names follow verb_noun pattern (query_, list_, get_), which is positive. However, schemas lack comprehensive field-level descriptions and output structure documentation. The codebase shows defensive programming (timeouts, semaphores, config validation) but tools themselves lack the LLM-optimized context needed for reliable agent planning. Most critically: (1) no output schemas are documented, (2) parameter descriptions exist but lack constraint details (e.g., timeout bounds, database name enumeration), (3) error responses are generic (no recovery guidance), (4) no idempotency or safety hints. The server is database-focused (READ_ONLY risk classification is appropriate), but tool definitions would confuse an LLM about what data structure each call returns.
Получить схему конкретной базы данных (таблицы, колонки, индексы)
Список доступных баз данных с информацией о схеме
Выполнить SQL запрос к базе данных
No output schemas documented for any tool. Tools return data but LLM cannot infer structure (fields, types, nested objects). Impossible to plan downstream calls or extract relevant results. Critical for agent composition.
Parameter descriptions lack constraint details. 'timeout' parameter says 'Таймаут выполнения запроса в секундах (0 = без лимита)' but does not specify bounds (minimum, maximum, recommended defaults). LLM cannot validate inputs before calling. Example: timeout could be -1, 999999, or string.
No enum or constraint on 'database' parameter in query_database and get_database_schema. Parameter accepts a string but should declare which database names are valid (discovered via list_databases). Requires LLM to chain calls or guess; invites hallucinated database names.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
No error handling guidance. Tool descriptions do not explain failure modes (invalid SQL, connection timeout, database not found, permission denied) or recovery paths. LLM receives raw errors with no next-step hints.
query_database lacks idempotency declaration. SQL queries are read-only (per Risk field), but tool description does not explicitly state 'This tool is safe to retry' or document any side effects. Agents need to know retry safety.
Russian descriptions are non-standard for LLM tooling ecosystems, which predominantly use English. Tool descriptions ('Выполнить SQL запрос...', 'Список доступных баз данных...') will be less reliably understood by English-trained LLMs and reduce interoperability.
No pagination support on list_databases (returns all databases). For large environments (many test/prod replicas), response could exceed context limits and degrade LLM reasoning. Tool should accept limit/offset parameters and return a total count.
No tool annotations. Tools lack readOnlyHint, idempotentHint, or destructiveHint metadata (MCP 2026-07-28). Agents cannot infer safety properties without reading descriptions. Even though all tools are read-only, explicit hints would improve reliability.