Loading ToolBench
Two tools with reasonable descriptions and explicit schema registration via TypeScript, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. Tool names follow verb_noun convention (get_schema, query). Descriptions are present and moderately detailed (173 and 287 chars respectively), meeting the 10-1024 char baseline, but parameter-level documentation is sparse. The 'query' tool accepts SQL directly without type constraints or format validation hints. Error handling is minimal, no recovery guidance, retryability classification, or actionable error messages. The schema for 'query' is documented as a simple string input, but the output structure is completely undocumented. Output field naming and structure are not specified, forcing the LLM to infer what the response contains.
Get the database schema for the user's Atomic CRM instance. IMPORTANT: Always call this tool FIRST before using the query tool to understand what tables and columns are available. Returns information about: - All tables and views in the database (views are clearly labeled) - Column names and data types for each table/view - Foreign key relationships between tables Views (like contacts_summary, companies_summary) are read-only and often provide aggregated or pre-joined data for easier querying. This helps you write accurate SQL queries including JOINs without guessing table or column names.
Query data from the user's Atomic CRM instance using SQL. IMPORTANT: Before using this tool, you MUST call the get_schema tool first to understand what tables and columns are available in the database. Use this tool when the user asks about their CRM data such as: - Contacts, companies, and deals - Sales pipeline and forecasting data - Customer interactions and notes - Tasks and follow-ups - Custom fields and metadata Row Level Security (RLS) is enforced - queries automatically return only data the authenticated user has permission to access. Note: Use the *_summary views (contacts_summary, companies_summary) for queries that need aggregated data or search capabilities. Examples: - "SELECT id, first_name, last_name, email_fts FROM contacts_summary WHERE email_fts LIKE '%@company.com%'" - "SELECT name, stage, amount FROM deals WHERE created_at > NOW() - INTERVAL '30 days' ORDER BY amount DESC" - "SELECT COUNT(*) as total_tasks, type FROM tasks WHERE done_date IS NULL GROUP BY type" - "SELECT c.first_name, c.last_name, co.name as company_name FROM contacts c JOIN companies co ON c.company_id = co.id WHERE co.sector = 'Technology'"
No output schema documentation for either tool. The 'get_schema' tool returns information about tables, columns, and relationships, but the exact response structure (fields, types, nesting) is not documented. The 'query' tool returns SQL results, but the shape of rows, presence of metadata, and error response format are undocumented. LLMs cannot plan downstream tool calls or extract data reliably without knowing what fields to expect.
SQL injection and command injection risk not addressed. The 'query' tool accepts arbitrary PostgreSQL SQL as a string parameter with no validation, sanitization, or constraint hints. While RLS is mentioned as enforced server-side, the description lacks guidance on LLM misuse patterns. No length limits, query complexity bounds, or statement-type restrictions (e.g., preventing DROP TABLE) are documented. Malicious or confused LLMs could craft harmful queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Parameter 'sql' for the query tool has minimal documentation. It is described as a PostgreSQL query string, but lacks constraint hints (e.g., max length, disallowed keywords, recommended patterns). The description includes example queries, which is anti-pattern, LLMs tend to reuse examples literally. A proper format constraint (e.g., 'SELECT-only, max 5000 chars, no DDL') would be more machine-parseable and prevent hallucination.
No error handling guidance. Descriptions do not explain what errors are possible (e.g., syntax errors, permission denied, table not found), whether errors are retryable, or what the LLM should do if a query fails. For example, if a column name is wrong, should the LLM retry with get_schema first? This is not stated. Error responses from the tool are not documented.
No pagination support documented for 'get_schema' or 'query'. If schema is very large (many tables) or if a query returns thousands of rows, the response could exceed context windows. Neither tool description mentions limits, pagination cursors, or result caps. The rubric baseline (100% of A+ tools return pagination info) is not met.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in tool definitions. The 'query' tool explicitly declares 'Risk: READ_ONLY' in description text, but does not use the current spec's toolAnnotations field (io.modelcontextprotocol/toolAnnotations). This limits MCP client ability to make informed safety decisions about tool execution.
get_schema tool input schema is empty ({}). While this is correct for a no-argument tool, it should be validated in the handler and documented as 'no parameters required'. The current code accepts any input parameters silently without validation or documentation.