Loading ToolBench
An extended Airtable MCP server with full CRUD, bulk import/upsert, data analysis, schema validation, and export. Built on domdomegg/airtable-mcp-server.
This server provides 29 tools with comprehensive Airtable coverage. Most tools have names that clearly indicate action (verb_noun pattern), descriptions that explain purpose, and input schemas with typed parameters. However, there are significant gaps: (1) Output schemas are NOT documented anywhere, the code shows tool registration but no return type specifications visible in source; (2) Parameter descriptions exist but are often generic and lack constraint details (e.g., 'Optional maximum number of records' lacks min/max bounds); (3) Error handling guidance is absent, tools return raw API errors with no recovery hints; (4) Several tools combine multiple concerns (e.g., create_webhook includes security warnings about macSecretBase64 in description rather than a separate credential-handling tool); (5) Descriptions vary in quality, some are thorough (create_webhook, bulk_import) while others are minimal (list_bases, validate_schema). Tool naming is generally strong (18-25 chars, verb-first), parameter types are present (string, number, array, object), but LLM-friendly constraint documentation is weak. The server follows a consistent registration pattern and covers both CRUD and advanced operations well, but falls short of A-grade polish.
Import multiple records into a table from a JSON array. Records are batched in groups of 10 (Airtable's limit) with rate limiting to stay within 5 requests/second. Use this instead of create_record when you have more than a few records to add. Supports up to 1000 records per call. Each record should be an object with field names as keys. Field names must match the table's field names exactly (case-sensitive), or use typecast to allow Airtable to coerce values. Example input for records: [ {"Name": "Alice", "Email": "[email protected]", "Status": "Active"}, {"Name": "Bob", "Email": "[email protected]", "Status": "Pending"} ] Returns a summary with created count, failed count, errors (with row indices), and created record IDs.
Create or update records based on merge field(s). If a record with matching merge field values exists, it is updated; otherwise a new record is created. Records are batched in groups of 10 with rate limiting. Supports up to 1000 records per call. The fieldsToMergeOn parameter specifies which field(s) to use for matching. These fields must have unique values in the table. If multiple fields are specified, records are matched on the combination. Example: Upserting contacts by email: fieldsToMergeOn: ["Email"] records: [{"Email": "[email protected]", "Name": "Alice Updated", "Status": "Active"}] This will update the existing record with that email, or create a new one if not found.
Create a new Airtable base in a workspace with an initial set of tables and fields. You need a workspaceId — use list_bases first to find bases and their workspace context, or check the Airtable UI (workspace IDs start with "wsp"). Each table must have at least one field. The first field in each table becomes the primary field and must be one of: singleLineText, number, email, url, phoneNumber, date, autoNumber, barcode, formula, or duration. Example usage: name: "Service Directory" workspaceId: "wspABC123" tables: [ { "name": "Organizations", "description": "Service providers", "fields": [ {"name": "Name", "type": "singleLineText"}, {"name": "Description", "type": "multilineText"}, {"name": "Website", "type": "url"}, {"name": "Status", "type": "singleSelect", "options": {"choices": [{"name": "Active"}, {"name": "Inactive"}]}} ] } ] Returns the created base with IDs for the base, tables, and fields.
Output schemas are not documented. Tool definitions show input schemas but provide no specification of what fields/types are returned. LLMs cannot plan downstream tool calls or extract needed data without documented output structure.
Parameter descriptions lack numeric constraints. Parameters like maxRecords, pageSize, and limit state they are 'optional' but do not specify min/max bounds. LLMs will pass unbounded values that may break APIs or cause timeouts.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Create a comment on a record
Create a new field in a table
Create a new record in a table
Create a new table in a base
Create a webhook on a base to receive real-time notifications when data changes. The notificationUrl is where Airtable will send POST requests when changes occur. Your endpoint must be publicly accessible via HTTPS. The specification controls what changes trigger notifications. Common configurations: Watch all record changes in a base: specification: {"options": {"filters": {"dataTypes": ["tableData"]}}} Watch a specific table: specification: {"options": {"filters": {"dataTypes": ["tableData"], "recordChangeScope": "tblXXXXXXXXXX"}}} Watch record and schema changes: specification: {"options": {"filters": {"dataTypes": ["tableData", "tableFields"]}}} IMPORTANT: The response includes a macSecretBase64 value. Save this immediately — it's needed to verify that incoming webhook payloads actually came from Airtable, and cannot be retrieved again. Webhooks expire after 7 days. Use refresh_webhook to extend them.
Delete a field from a table. This is a destructive operation that permanently removes the field and all its data from all records. Note: You cannot delete the primary field of a table. The Airtable API does not support deleting tables, only fields.
Delete records from a table
Delete a webhook from a base. Use list_webhooks to find webhook IDs.
Get the schema and metadata for a table
Export table data
Get a single record by ID
Get payloads for a webhook
List all bases in the Airtable account
List comments on a record
List records from a table
List all tables in a base
List all views in a table
List all webhooks for a base
Refresh a webhook to extend its expiration time
Search records in a table by a search term across specified fields
Analyze and summarize table data
Update a field's name and description
Update records in a table
Update a table's name and description
Upload an attachment to a record
Validate table schema against a provided schema definition
Error handling guidance is absent. Tools return raw API errors with no recovery suggestions. When a record lookup fails, the tool should suggest 'Try search_records() with a partial name.' Agents need actionable error context.
Minimal descriptions for discovery tools. list_bases, list_tables, list_views, and list_webhooks have descriptions under 50 characters. These tools are often called early in a session to explore structure, descriptions should state when to call them and what they reveal.
Credential handling mixed into tool description. create_webhook includes security warnings about macSecretBase64 in its description text rather than implementing a proper credential-handling pattern. This couples security logic with tool documentation.
summarise_table and export_table have vague descriptions and unclear output specs. 'Analyze and summarize' and 'Export table data' lack detail on what the output contains, what 'analyze' means, and when format='csv' vs 'json' is appropriate.
Parameter names are inconsistent across similar operations. 'nested' in create_field is opaque; other tools use 'specification' (create_webhook) or 'fields'. Inconsistent parameter naming forces LLMs to re-learn the API for each tool.
No pagination documentation in result-returning tools. list_records, list_comments, and get_webhook_payloads accept optional pagination params, but descriptions do not explain how to use them (e.g., 'Omit offset on first call, then pass the offset from the previous response').