Airtable MCP Server

Airtable

Airtable organizes data as bases → tables → records. Field types (single line text, attachments, links) appear in schema reads; record payloads use field names as keys.

First moves

1. Bases — list accessible bases and copy base ids for the session.
2. Base schema — tables and field definitions for a base (names, types, options).
3. Table schema — one table's fields when you need a lighter schema read than the full base map.
4. Records — list rows in a table with optional view, sort, page size, and column projection.
5. Record comments — read collaboration threads on a row when the user asks what was discussed.
6. Text search — keyword search across text-like columns when the user names a phrase to find.
7. Formula filter — targeted record pulls with Airtable formula expressions when rules are precise.

Writes

Create and batch-update records (up to ten per batch). Schema writes add tables and fields — confirm field types from schema reads before creating columns. Record comments can be read or added on individual rows.

Hierarchy

Base id → table id or name → record id. Linked-record fields return arrays of record ids, not full nested rows.

Operational order

1. List bases, then read schema for the base the user names — do not guess table or field names.
2. Pull records with a view, formula filter, or text search matching the user's question.
3. Copy record ids from list responses before comment reads or row updates.
4. Keep paging when the user wants a full export or "all rows" — stop only when no next page remains.

Gotchas

• Pagination — record lists return at most 100 rows per page; follow offset tokens in responses until done.
• Formula syntax — quote strings and reference field names in braces; invalid formulas fail the whole pull.
• Text search scope — narrow to named columns on wide tables so keyword search stays fast and relevant.
• Column projection — request only the fields you need on large tables to keep payloads manageable.
• Opaque ids — base, table, and record ids are strings from list or schema responses; do not invent them.
• Rate limits — five requests per second per base; page sequentially instead of parallel fan-out.