Skip to main content
Glama

airtable_batch_upsert

Bulk insert or update up to thousands of Airtable records with automatic chunking and rate-limit backoff. Use for CSV imports, webhooks, and external system syncs.

Instructions

Ingests or bulk-inserts records into an Airtable table using the REST API with automatic 10-record chunking and 5 req/sec rate limit backoff.

When to Use

  • When bulk-importing rows of data from CSVs, webhooks, or external systems into an Airtable table.

  • When creating multiple records in batches of 10 to 1,000+ rows efficiently without manual loop management.

  • When inserting structured data where string values for singleSelect or record links should be auto-cast.

When NOT to Use

  • Do NOT use this tool to update or delete a single record by record ID. Use 'airtable_manage_records' instead.

  • Do NOT use this tool for reading or filtering existing records. Use 'airtable_query_records' instead.

  • Do NOT use this tool to create new tables or modify field schemas. Use 'airtable_create_base_schema' or 'airtable_modify_schema' instead.

Operational Disclosures

  • Side Effects: Creates new persistent records in the target table. Does not overwrite existing rows unless fields match Airtable's native upsert performUpsert criteria.

  • Persistence & Idempotency: Additive mutation. Calling multiple times with identical records will create duplicate records unless an external primary key is deduplicated beforehand.

  • Rate Limiting: Airtable enforces a strict 5 req/sec limit. This tool chunks records into 10-item payloads and sleeps 210ms between requests, with exponential backoff on HTTP 429.

  • Auth Scopes: Requires Personal Access Token with 'data.records:write' scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
base_idYesAirtable Base ID (starts with app, e.g. appoorUuG6wgx8dJ1)
recordsYesArray of record objects mapping field names to values, e.g. [{"Merchant Name": "Acme", "Stage": "Onboarding"}]
typecastNoWhen true, automatically creates new select options or converts string values to linked record arrays (default: true)
table_name_or_idYesTarget Table Name (e.g. "Merchants", "Orders") or Table ID (starts with tbl)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • changedInput schema / properties / base_id / description
      Previous value: -"Airtable Base ID (starts with app...)"New value: +"Airtable Base ID (starts with app, e.g. appoorUuG6wgx8dJ1)"
    • changedInput schema / properties / records / description
      Previous value: -"Array of record objects mapping field names to field values"New value: +"Array of record objects mapping field names to values, e.g. [{\"Merchant Name\": \"Acme\", \"Stage\": \"Onboarding\"}]"
    • changedInput schema / properties / table_name_or_id / description
      Previous value: -"Target Table Name or Table ID"New value: +"Target Table Name (e.g. \"Merchants\", \"Orders\") or Table ID (starts with tbl)"
    • changedInput schema / properties / typecast / description
      Previous value: -"Enable typecasting to automatically parse string choices/links (default true)"New value: +"When true, automatically creates new select options or converts string values to linked record arrays (default: true)"
  2. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fully delivers by describing side effects, persistence and idempotency behavior, rate limiting with backoff specifics, and required auth scopes. There is no contradiction with annotations because none are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise summary followed by clear sections for usage, exclusions, and operational disclosures. Every sentence adds actionable information, and the use of bullets makes it highly scannable despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers tool selection, invocation prerequisites, side effects, rate limiting, auth, and parameter usage comprehensively. However, because there is no output schema, the description does not disclose the return payload or general error response shape beyond HTTP 429 backoff, leaving a minor completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% parameter coverage, including examples for base_id, table_name_or_id, records, and typecast defaults. The description reinforces typecast behavior and chunking but does not add significant per-parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Ingests or bulk-inserts records into an Airtable table using the REST API', clearly specifying the action, resource, and mechanism. The When NOT to Use section explicitly distinguishes it from airtable_manage_records and airtable_query_records, so an agent can easily tell this tool apart from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'When to Use' and 'When NOT to Use' sections. It lists concrete bulk-import scenarios and directly routes single-record updates, reads, and schema modifications to the appropriate sibling tools, leaving no ambiguity about tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.