Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The Airtable MCP server has solid fundamentals with 7 well-named tools following clear verb_noun conventions (list_, get_, search_, create_, update_). All tools have descriptions and JSON schemas with typed parameters. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present and correct. However, several parameter descriptions lack actionable detail about formats, constraints, and error recovery. Output schemas are not explicitly documented. Error handling is minimal, no recovery guidance or classification of retryable vs fatal errors. Parameter descriptions average ~50 chars, below the 72-char baseline for A+ tools. Some parameters like 'sort' and 'records' lack item-level type definitions. The detail_level enum pattern is applied consistently, which is good. Overall, this is a solid B-/C+ server that implements core patterns but lacks the polish and defensive design of production-grade tools.
Error handling is minimal. No recovery guidance (e.g. 'try search_records with a partial term'), no error classification (retryable vs fatal), no actionable error messages with constraints shown.
Recommendations
Add explicit output schema documentation to all tools. Example for list_records: 'Returns: {records: [{id, fields: {[key]: value}}, ...], offset?: string, total?: number}' in the description or as a schema property.
Expand 'records' parameter definition in create_records and update_records to: {type: 'array', items: {type: 'object', properties: {id?: string, fields: {type: 'object'}}, required: ['fields']}, minItems: 1, maxItems: 100, description: 'Array of record objects. Each record object must have a fields property (object with field_name: value pairs). For updates, include id field.'}
Add item schema to 'sort' parameter in list_records: {type: 'array', items: {type: 'object', properties: {field: {type: 'string'}, direction: {type: 'string', enum: ['asc', 'desc']}}, required: ['field']}, description: 'Array of sort specifications, each with field name and direction (asc or desc)'}
Implement recovery guidance in error responses. Examples: If base_id is invalid, return 'Base not found. Call airtable_list_bases to see available bases.' If record_id not found, return 'Record not found. Try airtable_search_records with search_term to locate the record.'
Add explicit result limits to descriptions: 'list_bases: Returns max 100 bases per page (use offset for pagination)', 'list_records: Returns max 100 records per call', 'search_records: Returns max 100 matches'.
Clarify side effects in create_records and update_records descriptions: 'Creates new records (non-idempotent). Do not retry on failure without deduplication to avoid duplicate records.' and 'Updates existing records. Provide record IDs from a prior airtable_get_record or airtable_search_records call.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 44 points across a rubric change (v1 → v2)
65/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
65
<=2025-11-25
v2
2026-03-09
F
21
-
v1
Update existing records (up to 100 total, automatically batched in groups of 10)
No pagination limit enforcement mentioned in descriptions. Tools like list_records and list_bases should explicitly state the result limit (e.g. 'Returns max 100 records per call') to prevent context window exhaustion.
Descriptions for create_records and update_records lack clarity on side effects. Should explicitly state: 'Creates new records (destructive, non-idempotent)' or 'Updates existing records (destructive)' so LLMs know these are not safe to retry without deduplication.
Parameter 'offset' (list_bases) lacks guidance on format. Should clarify: 'Pagination offset as returned in the previous response's offset field' or provide cursor guidance.
No confirmation pattern for destructive writes (create/update). Agents make mistakes, should offer a dry_run parameter or explicit confirmation before executing writes.
Parameter dependencies not documented. E.g., if 'fields' is provided in list_records, does it filter results or just selects columns? If 'view' is provided, is filterByFormula ignored? Undocumented dependencies cause misuse.
Fields parameter descriptions are generic. Should clarify: 'Field names to return (case-sensitive). Omit for all fields. Returns only specified fields in result records.'
Document parameter dependencies in list_records description: 'If view is provided, it takes precedence over filterByFormula. If fields is provided, only those fields are returned in the response. Use maxRecords (hard limit) or pageSize (per-request limit) for pagination.'
Add a dry_run flag (optional boolean) to create_records and update_records: 'If true, validates the operation but does not commit changes. Use to preview the operation before execution.'
Clarify offset/pagination model: 'offset is a string returned in previous responses. Pass the offset value from a prior call to fetch the next page. Omit offset or set to null to start from the beginning.'
Add actionable parameter validation error examples to descriptions. For maxRecords: '(1 - 100, default 100). Invalid values will error with: Invalid maxRecords: got X, must be 1 - 100.'
Document what cellFormat controls: 'json (default): field values as JSON types; string: all values as strings. Applies only to return format, not filtering.'
Expand description for typecast (create/update): 'If true, attempts to convert provided values to the target field type. If false, mistyped values cause an error. Enable with caution to avoid silent type coercion.'
Add include-chaining-ids guidance: Ensure all responses from get/list/search tools return the base_id and table_id so downstream tools (create_records, update_records) have the context they need without extra lookups.