Loading ToolBench
Servidor MCP (Model Context Protocol) para integração com ferramentas externas
This server has significant quality gaps across naming, descriptions, parameters, and schemas. Tool names are inconsistent (mix of snake_case and PascalCase), descriptions are present but generic or incomplete, and parameter schemas are minimally documented. The YouTube tool has a READ_ONLY risk designation that conflicts with its write-capable action (blog post creation). Input schemas are visible in pyproject.toml dependencies and code fragments, but parameter-level type information is sparse. Error handling infrastructure exists (MCPErrorCode, create_error_response) but is not integrated into tool descriptions. Overall, this server reads as a prototype or internal tool, not production-grade.
Exporta o catálogo do MariaDB como JSON (string).
Executa SQL (somente SELECT) no MariaDB e retorna linhas como JSON.
Search YouTube channel and write a blog post based on the topic
Lista nomes de tabelas do banco que o agente pode usar.
Recebe uma pergunta em linguagem natural, gera um SELECT e retorna APENAS os resultados em JSON (array de objetos).
Executa SQL (somente SELECT) no MariaDB e retorna linhas como JSON. Garante LIMIT e recusa comandos de escrita.
Inconsistent tool naming convention. Mix of PascalCase (VerxRH_RunQuery, Youtube_BlogPost) and snake_case (db_list_tables). PascalCase with underscores is non-standard for tool naming and makes intent parsing harder for LLMs. All tools should use verb_noun snake_case (e.g., run_query, get_db_catalog, list_tables).
Generic/incomplete parameter descriptions. 'Optional parameter (unused)' for db_list_tables's '_' parameter provides no actionable guidance. Parameters like 'sql' in VerxRH_RunQuery lack detail on format, length limits, or constraints (e.g., 'SELECT only' is mentioned in tool description but not in param description).
Risk classification mismatch. Youtube_BlogPost is marked READ_ONLY but creates a blog post (write operation). This is either a documentation error or a security misunderstanding. Write operations should be marked WRITE or have explicit confirmation patterns. All six tools are marked READ_ONLY, which may indicate risk assessment was skipped.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | 2025-03-26+ | v1 |
Missing output schema documentation. Tool descriptions do not explain what fields or structure are returned. E.g., VerxRH_RunQuery says 'returns linhas como JSON' but does not document the schema of the JSON (array of objects? fields?).
No pagination or result-limiting documentation. Database query tools (VerxRH_RunQuery, db_query, db_nl2sql_rows) do not mention limits or pagination. If a query returns 10,000 rows, the tool will exhaust the context window. Per pattern requirements, tools returning lists must accept limit/page parameters and document them.
Error handling guidance missing from descriptions. Tools have error handling infrastructure (create_error_response, MCPErrorCode) visible in code, but tool descriptions do not explain what errors can occur or how to recover. E.g., 'SQL injection detected' or 'query timeout' are not mentioned. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
Tool descriptions are too generic or incomplete. VerxRH_GetDBCatalog says 'Exporta o catálogo' with no detail on use case, structure, or when to call it vs other tools. db_nl2sql_rows returns 'APENAS os resultados' but does not clarify what preprocessing happens or why it differs from db_query. Descriptions average 50 chars; rubric baseline is 194 chars for A+ tools.
Parameter naming ambiguity. The '_' parameter in db_list_tables is cryptic and violates the verb_noun convention. Using underscore as a parameter name breaks discoverability and does not convey intent. If it is truly unused, remove it. If optional context is needed, use a descriptive name like 'filters' or 'options'.
No input validation constraints in schemas. Parameter descriptions lack regex patterns, length limits, or enum values. E.g., 'sql' parameter accepts any string but should enforce 'SELECT only'.
Tool composition concerns. Six separate database query tools exist (VerxRH_RunQuery, VerxRH_GetDBCatalog, db_list_tables, db_query, db_nl2sql_rows) with overlapping functionality. LLM must reason about which to use. Consolidation or clearer distinctions needed. E.g., if db_nl2sql_rows is for natural-language input and db_query is for raw SQL, this should be explicit in names and descriptions.