Loading ToolBench
A comprehensive MCP server providing database schema exploration, SQL execution, secure file storage, code sandboxing, PDF report generation, web search/scraping, and Slack integration tools.
CogniQuery presents 11 tools with moderate structural quality but significant gaps in LLM-optimized descriptions, parameter documentation, and output schema clarity. Tool names follow action-verb conventions (echo, slack_post, schema_explorer, sql_executor, store_data, retrieve_data, code_interpreter, generate_pdf_report, web_search, scrape_website), which is positive. However, most parameter descriptions are minimal (typically 1-3 words), and output schemas are not documented. Several tools lack critical clarity around error handling and recovery. The schema_explorer tool shows the most sophistication with database-specific logic, but even it lacks comprehensive parameter validation guidance. Average tool description length is ~110 chars (below the 194-char baseline for A+ tools). Only 36% of parameters have descriptions exceeding 20 characters; many are terse ('Slack channel ID', 'Message text to send'). No tools declare permission scopes, and credentials appear to be injected via environment variables (good), but this is not explicitly documented in parameter descriptions.
Executes Python code in a secure E2B sandbox environment with access to uploaded data. This tool provides isolated code execution with data analysis capabilities.
Return the same text. Useful for a quick sanity check.
Generates a professional PDF report from markdown content and chart images. It takes markdown text and a list of file handles for charts, combines them, and returns a file handle to the final PDF.
Retrieves previously stored data using a file handle.
Explores database schema in a database-agnostic way. This tool automatically detects the database type and uses appropriate queries to extract schema information including tables, columns, primary keys, and foreign key relationships.
Scrapes the content of a website and returns clean text.
Output schemas are undocumented. No tool declares what fields the LLM should expect in responses (e.g., does sql_executor return {rows: [], columns: []} or {data: string}?). This forces LLMs to infer structure and plan downstream operations blindly, increasing hallucination risk.
Parameter descriptions are too terse (averaging 15-20 chars). Examples: 'Text to echo back', 'Message text to send', 'The search query'. These lack format constraints, length bounds, or guidance on when to use the tool. Baseline for A+ tools is 72 chars per parameter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Post a message to a Slack channel.
Upload a file (pdf/image/any) to a Slack channel. Provide exactly one of: file_handle, file_path, data_base64.
Executes SQL SELECT queries against a configured database and returns results as CSV.
Stores text or binary data securely and returns a file handle for later retrieval.
Searches the web for information using a search query.
slack_upload parameter documentation is ambiguous about mutual exclusivity. Input schema shows 'Provide exactly one of: file_handle, file_path, data_base64' in description, but the schema itself does not enforce this constraint (no oneOf, allOf, or anyOf schema composition). LLM may pass multiple parameters, causing tool failure.
No error handling guidance. Tools lack descriptions of failure modes (e.g., what if sql_executor receives invalid SQL? What if slack_post fails due to rate limit?). LLMs cannot plan recovery without knowing error categories (retryable vs. user-fixable vs. fatal).
schema_explorer tool accepts 'table_filter' as a regex pattern, but the description does not specify regex syntax, anchoring behavior, or examples. An LLM may pass invalid regex ('.*@' vs '^[a-z]+$') without guidance.
store_data and retrieve_data form a logical pair, but no tool description hints at dependency. LLM may not realize it must call store_data before retrieve_data, or that file_handle is the coupling ID. Tool descriptions lack dependency hints.
No permission or scope declarations. Tools like slack_post (WRITE), sql_executor (READ), code_interpreter (WRITE), and scrape_website (READ) do not declare required permissions (e.g., 'write:slack', 'read:database'). Agents cannot configure least-privilege access.
code_interpreter tool accepts 'file_handle' as optional input but does not document what happens if both file_handle and code are provided, or if code is standalone. Ambiguous parameter relationships invite misuse.
slack_upload and generate_pdf_report both accept file handles and support base64 encoding, but parameter naming is inconsistent: slack_upload uses 'file_handle', 'file_path', 'data_base64'; generate_pdf_report uses 'chart_handles' (array). LLM cannot reliably predict which parameter name applies across tools.
No pagination or result limits documented. schema_explorer, sql_executor, web_search, and scrape_website do not declare max result sizes or pagination support. An LLM querying a 10-million-row table or fetching 1000 search results could exhaust context or cause timeouts.