Loading ToolBench
Retable Model Context Protocol Server for managing workspaces, projects, and tables in Retable.io
The server defines 17 tools with visible schemas and descriptions in src/mcp-server.ts. However, significant quality gaps reduce the overall score. Tool descriptions are present but brief (averaging ~60 chars, well below the 194-char baseline for A-grade tools). Parameter descriptions are minimal or missing context. Schemas are declared via Zod but lack validation details, constraints, and output documentation. Error handling is generic (wrap all errors as JSON text responses) with no recovery guidance. The tool set has structural issues: several tools lack critical domain context (e.g., create_table accepts only projectId, no table name/description parameters); schema complexity is inconsistent (insert_row and update_row have deeply nested object structures that could confuse LLMs); and parameter names occasionally diverge from field-naming consistency (delete_column uses 'columns' object, others use simpler names). No tool annotations (readOnlyHint, destructiveHint) are present despite clear Risk classifications. Output schemas are undocumented, callers have no reference for what fields to expect. The server implements basic error wrapping but provides no recovery guidance, suggestions for alternatives, or error categorization.
Create a new column on the specific Retable
Create a Project under the given Workspace with a default Retable
Create new table in a project
Create a new Workspace with a default Project
Delete column from a specific Retable
Delete a specific Project
Delete rows from a specific Retable
Descriptions are consistently brief (averaging ~55 chars vs. 194-char baseline) and lack WHEN/WHY context. Examples: 'Create a new Workspace with a default Project' (49 chars) provides no guidance on when to use this vs. other workspace operations. 'Get data in a table' (19 chars) fails the 20-char minimum for adequate context.
Output schemas are undocumented. No tool declares what fields it returns, what types those fields have, or how they chain to downstream tools. LLMs cannot plan multi-step workflows without knowing return structures. This violates the 'Document the output schema' requirement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Delete a specific Workspace
Get user's all Workspaces
Get a specific Project with Retables
Get tables in a project
Get data in a table
Get information about a specific Retable
Get a specific Workspace and its Projects
Get projects in a workspace
Insert a new row in a specific Retable
Update an existing row in a specific Retable
Schemas for complex operations lack validation constraints and clarity. insert_row and update_row have deeply nested 'newRow' objects with duplicate 'columns' fields that differ in purpose (definition vs. values). LLMs will struggle to construct correct payloads. Example: insert_row requires both columns definitions AND column_ids in data array, this dependency is undocumented.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint per MCP spec) are absent despite clear Risk classifications in the audit. Every tool should declare its safety profile. Example: delete_workspace is marked DESTRUCTIVE but has no hint to guide agent caution.
Error handling is generic and non-actionable. All errors are caught and returned as plain JSON text with only 'error' field set. No recovery guidance, error classification (retryable/user-fixable/fatal), or suggestions for next steps. Example: if delete_workspace fails due to insufficient permissions, the response is {"error": "<message>"} with no hint to check permissions or try a different workspace.
create_table accepts only projectId and returns what? No table name, description, or configuration parameters. Most APIs require at minimum a name. This forces an extra API call or assumes a default naming scheme, both break LLM intent. Similarly, insert_row and update_row payloads are unclear: does 'columns' array in insert_row describe schema or provide values?
Parameter descriptions are missing or minimal. Example: delete_column has 'columns' parameter described as 'Columns to delete' with nested 'column_ids' array, no hint that it's an array of strings or what format column IDs take. add_column 'newColumn' parameter has nested 'columns' array where 'type' field is described only as 'Column type', valid values not listed.
No pagination support documented or visible. get_rows, get_all_workspaces, get_workspace_projects, get_project_tables lack limit, offset, or cursor parameters. If a workspace has thousands of projects, a single call could return massive results, wasting tokens and risking context exhaustion.
No idempotency or deduplication guidance. Agents retry on ambiguous failures. Tools like insert_row and create_workspace could create duplicates on retry. No mention of idempotency keys, deduplication, or how retries are handled.