Loading ToolBench
Enhanced Airtable MCP Server with Advanced Security and Filtering
The Airtable MCP server presents moderate definition quality with consistent naming patterns and adequate schemas, but suffers from significant gaps in parameter descriptions, output schema documentation, and error handling guidance. All 12 tools follow the verb_noun convention (list_, get_, create_, update_, delete_, search_, filter_, aggregate_), which is positive. However, most parameters lack detailed descriptions explaining constraints, formats, and valid values. Tool descriptions are present but brief (40-80 chars typically), falling below the 194-char baseline for production tools. Output schemas are not documented, critical for LLM planning. Error handling is minimal; there is no guidance for recovery or error classification. Security validation code is present (injection protection, field name validation) but not reflected in parameter descriptions or error-handling contracts.
Aggregate records using operations like sum, count, average, min, max
Create a new record in an Airtable table
Delete a record from an Airtable table
Filter records by date range in an Airtable table
Get details about a specific Airtable base
Get a specific record from an Airtable table
Get details about a specific table in an Airtable base
Output schemas not documented. Tools return data structures but LLMs cannot see what fields to expect, forcing exploratory calls and breaking response-field-naming alignment for downstream tool chains.
Parameter descriptions lack constraint and format details. 'fields' parameter in create_record and update_record provides no guidance on field names, types, or valid values. 'filter_formula' in list_records and aggregate_records mentions 'Optional Airtable filter formula' but does not explain syntax or injection-prevention expectations, despite defensive validation code present in validators.py.
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 | 0 | - | v1 |
List all accessible Airtable bases
List records from an Airtable table with optional filtering and pagination
List all tables in a specific Airtable base
Search for records in an Airtable table by field value
Update an existing record in an Airtable table
Tool descriptions too brief (40-70 chars). Baseline for production is 194 chars. Descriptions lack WHEN-to-use context, dependencies, or operation consequences. E.g. delete_record says 'Delete a record' but does not warn of irreversibility or suggest dry-run patterns.
No error handling guidance. Code includes SecurityError and ValidationError exceptions but tool definitions provide no guidance on what errors agents should expect, how to classify them (retryable vs. user-fixable), or how to recover. LLMs will not know whether to retry, ask the user, or abandon.
No pagination documentation for list_* tools. list_records and search_records accept max_records but do not document whether they return a cursor, offset, total_count, or how to fetch the next page. Production baselines require explicit pagination guidance.
Parameter type mismatches in naming. 'base_id', 'table_id', 'record_id', 'field_name' parameters lack explicit type descriptions (string vs. ID format). Code validates base_id starts with 'app' but this constraint is not in parameter descriptions, LLMs will not know the expected format.
Destructive operations lack confirmation or dry-run pattern. delete_record is marked DESTRUCTIVE but tool definition provides no mention of confirmation, undo, or dry-run capability. Code does not appear to support these recovery patterns.
max_records defaults and caps not documented. list_records, search_records, and filter_by_date accept max_records with claimed default/cap but description does not state these explicitly. Code comment says 'max: 1000' for list_records but this is not in the schema description.