Loading ToolBench
Nautilus MCP multicloud: PostgreSQL, MySQL/MariaDB, SQLite, SQL Server, Oracle, MongoDB, Redis. Read-only database query and metadata tool supporting multiple database engines.
The Nautilus server provides 8 well-intentioned read-only database tools with proper parameter schemas and descriptions. However, significant gaps in description quality, parameter naming clarity, and error handling guidance prevent a higher score. While all tools have input schemas with types and descriptions, many descriptions are formulaic or lack actionable context. Parameter naming is inconsistent (e.g., 'connection_id' is good, but 'key_pattern' and 'cursor' for Redis are underdocumented for their domain). Error responses are minimal, tools return plain text strings without structured guidance on recovery. The server scores above median due to complete schema coverage and resource implementation, but falls short of 'good' (70+) due to weak descriptions, composition issues (db_query_sql lacks output schema documentation), and missing patterns like confirmation-request for destructive-adjacent operations.
Describe indexes for a table or MongoDB collection.
Fetch documents from a MongoDB collection with optional filtering.
Get metadata information for a resource including column definitions, document samples, or key information.
Listando conexões de banco de dados disponíveis.
Listando recursos para connection_id: {connection_id}, schema: {schema}, database: {database}
Peek at a sample of data from a table or collection.
Execute a read-only SQL query against a database connection.
Tool descriptions are formulaic and lack actionable context for LLM selection. Most descriptions (e.g., 'Get metadata information for a resource...') are 40-60 characters and do not state WHEN to use the tool instead of a similar one (e.g., when to call db_get_metadata vs db_peek_sample), or WHAT the output contains (column definitions, document structure, etc.). This forces LLMs to guess.
Output schemas are not documented. db_query_sql returns 'str' (plain text or JSON?), db_list_resources returns unstructured text with table names, db_get_metadata returns an undocumented structure. LLMs cannot infer downstream tool parameters (e.g., does db_query_sql return field names that feed into later queries?). This violates the 'Document the output schema' requirement.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Read data from a Redis cache key.
Redis-specific parameters ('key_pattern', 'cursor') lack clear domain documentation. The parameter description for 'cursor' says 'Cursor for Redis pagination (optional)' but does not explain the cursor format, how to obtain the initial cursor, or when pagination is needed. This is insufficient for LLM reasoning.
Error responses are plain text strings without structured recovery guidance. When a tool fails (e.g., 'Conexao nao encontrada' in Portuguese), the LLM receives no classification (retryable? user-fixable? fatal?) and no suggestion for next steps. This violates the 'Error responses must tell the LLM what to do next' rule.
db_query_sql lacks output schema documentation and validation. The description says 'returns JSON, CSV, or markdown' but the tool signature returns 'str', and there is no documented structure (column names, types, row count, success/failure distinction). LLMs cannot chain this into subsequent calls.
Parameter naming inconsistency and overloading. 'connection_id' is clear, but 'schema', 'database', 'key_pattern', 'cursor' vary in clarity. For MongoDB, 'database' and 'collection' are clear, but for SQL databases, the distinction between 'schema' and 'database' depends on the engine, this is underdocumented. LLMs may confuse these across database types.
No pagination or result limiting is enforced in the returned output text. While the input parameters include limits (e.g., 'limit' in db_query_sql, default 50, max 200), the returned text is unstructured and may not reflect the limit properly. There is no next_cursor or page token returned to enable pagination in a structured way.
Tool composition is weak. There are multiple 'peek' and 'get' tools (db_get_metadata, db_peek_sample, db_list_resources) that perform similar discovery functions. The distinction between db_peek_sample ('peek at a sample') and db_get_metadata ('metadata including column definitions') is unclear from descriptions alone. LLMs will struggle to choose the right one.
SQL injection prevention is mentioned (SqlQueryValidator exists) but not visible in the tool description. LLMs will not know that db_query_sql is safe for user-provided queries, and may avoid calling it or ask the user to construct queries manually. This is a missed opportunity to encourage safe tool use.