Loading ToolBench
A Model Context Protocol server that provides access to NocoDB API functionality. Supports both stdio and SSE transport methods.
This NocoDB MCP server has fundamental definition quality issues across all dimensions. While tool names follow verb-noun convention (create_table_records, get_table_records, etc.), the parameter schemas are incomplete, descriptions lack critical context, and error handling provides no recovery guidance. The schema definitions show types but lack proper JSON Schema structure, the input specification uses a custom format rather than standard JSON Schema. Parameter descriptions are generic and do not explain constraints, expected formats, or dependencies. Output schema is undocumented. Error responses return raw API status codes without actionable guidance. All four tools suffer from similar deficiencies.
Create new records in a NocoDB table. Args: table_id: The ID of the table to create records in records: A single record object, array of record objects, or JSON string to create Returns: Dictionary containing success status, created record IDs, and any error messages
Delete a specific record from a NocoDB table. Args: table_id: The ID of the table containing the record record_id: The ID of the record to delete Returns: Dictionary containing success status and any error messages
Retrieve records from a NocoDB table. Args: table_id: The ID of the table to retrieve records from limit: Maximum number of records to retrieve (default: 25) offset: Number of records to skip (default: 0) Returns: Dictionary containing success status, retrieved records, and any error messages
Update records in a NocoDB table (batch update). Args: table_id: The ID of the table containing the records records: A single record object (must include id), array of record objects, or JSON string Returns: Dictionary containing success status, updated record data, and any error messages
Output schemas completely undocumented. Tools return Dict[str, Any] with no structure definition. LLM cannot plan multi-step workflows because it doesn't know what fields to extract from responses.
Parameter schemas use non-standard format. Input spec shows custom type notation ('union', 'types') rather than standard JSON Schema. This prevents proper validation and LLM interpretation.
Parameter descriptions lack constraint specifications. E.g., 'limit' parameter has no documented range (is 0 valid? is there a maximum?). 'offset' has no constraint. 'records' parameter accepts dict|list|string but no validation rules for field requirements, data types, or field name constraints. Code shows readonly field filtering but this is invisible to LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No error handling guidance. Error responses return raw API status codes and error dictionaries without telling LLM what to do next. E.g., a 404 error should suggest 'Try searching for the table ID first' but instead returns bare status code.
Destructive operations (delete_table_record) lack confirmation pattern. Tool can permanently delete records without requiring explicit user confirmation. Violates pattern:confirmation-request.
Tool descriptions lack 'when to use' context. Descriptions state WHAT the tool does but not WHEN to call it instead of another similar tool, or what prerequisites exist. E.g., do you need table_id from a discovery tool first? Can you pass table name instead of ID?
API keys and tokens passed via environment variables are properly handled server-side (NOCODB_TOKEN not exposed as parameter), which is correct. However, no documentation of this security pattern in tool descriptions.