Loading ToolBench
An MCP server that turns a folder of CSV / Parquet / JSON files into one SQL-queryable source for your AI agent.
tablebridge has well-structured tool definitions with clear, actionable descriptions (avg 180 chars, within baseline 194). All 6 tools have explicit schemas with typed parameters. Naming follows verb_noun convention (list_, describe, preview, query, refresh, server_info). However, several parameters lack descriptions (e.g., 'n' in preview has description but lacks type constraints; 'sql' in query lacks format/constraint guidance). Output schemas are documented in descriptions but not formally declared. Error handling is minimal, no recovery guidance, no validation error messages. Security is strong (read-only, sandboxed), but error responses would not guide LLM recovery.
Show a table's column names and DuckDB types. Use this before writing a `query` to learn a table's schema — its columns, their types, and order. The table name is the data file's stem as reported by `list_sources`. Read-only. Returns a JSON array of {name, type} objects.
List the tables available to query (one per data file) with column counts. Start here: each CSV/Parquet/JSON file under the data directory is exposed as a table you can SELECT from and JOIN across.
Return the first ``n`` rows of a table as JSON. Use to eyeball a table's contents and value shapes before querying. The row count is capped by TABLEBRIDGE_MAX_ROWS regardless of ``n``. Read-only. Returns a JSON array of row objects.
Run a read-only SQL query (DuckDB dialect) across the loaded tables. Use this for any real data question — filtering, aggregation, or JOINs across files. Each data file is exposed as a table (see `list_sources`); call `describe` first if you need a table's schema. Supports SELECT / WITH / DESCRIBE / SUMMARIZE; writes and raw file-access functions are rejected. Results are capped at TABLEBRIDGE_MAX_ROWS, with a ``truncated`` flag when more rows exist.
Re-scan the data directory (pick up added/changed files) and report the count.
query() parameter 'sql' lacks format constraints and validation guidance. Description mentions 'read-only DuckDB SQL' but does not specify what write operations are rejected or how the LLM should format queries. No regex pattern, length limit, or example of valid syntax.
No error handling or recovery guidance in any tool. If query() fails (e.g., invalid SQL, table not found), the response is likely a raw exception. LLM has no guidance on what to do next (retry, call describe first, check table name).
preview() parameter 'n' has description but no type constraint (min/max). Unbounded integer lets LLM pass absurd values (e.g., n=999999) that could timeout or exhaust memory, despite TABLEBRIDGE_MAX_ROWS cap.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Report the effective configuration (data dir, row cap, supported formats).
refresh() and server_info() have minimal descriptions (60 and 65 chars respectively). refresh() does not explain when to call it or what 'reloaded_tables' count means. server_info() does not clarify what 'effective configuration' includes.
Output schemas are documented in tool descriptions (e.g., 'Returns a JSON array of {name, type} objects') but not formally declared in a structured schema field. LLM must parse descriptions to infer output structure.