Airtable for spreadsheets and tables
Airtable stores operational data as records in tables that behave like a database while reading like a grid, and this maintained server is the top pick for letting an agent work that data directly. It wins the spot because the whole job here is structured read and write against your tables, and the server does exactly that: it reads schemas, queries and searches records, and creates or edits rows, tables, and fields.
Notion and Coda, the two siblings here, are document workspaces that happen to hold tables. This server treats the table as the primary object, which is the right shape when your tracker, inventory, or CRM-in-a-grid lives in Airtable and you want the agent reasoning over rows rather than pages.
How Airtable fits
An agent usually starts by orienting itself: list_bases to find the workspace, list_tables and describe_table to read the schema, fields, and views before it touches data. Reading and querying run through list_records (with maxRecords and a filterByFormula expression), search_records for free-text lookups across fields, and get_record for a single row by ID. Writes cover the common cases: create_record, update_records for one or many rows at once, and delete_records. The schema itself is editable too, through create_table, update_table, and create_field, so an agent can add a column or stand up a new table rather than only filling existing ones.
The honest limits are Airtable's own. filterByFormula is the query surface, so anything you cannot express as a formula has to be filtered client-side after a broader read, and large bases mean paging through records rather than one sweeping scan. This is a community-maintained server (by Adam Jones), not an official Airtable build, so treat its lifecycle accordingly. Against the siblings: reach for Notion when the data is mostly prose with light tables attached, and Coda when documents and tables are tightly interwoven in one doc. For a grid you genuinely operate as a database, this Airtable server is the closer fit.
Tools you would use
| Tool | What it does |
|---|---|
| list_records | List records from a table, with optional maxRecords and a filterByFormula expression. |
| search_records | Search for records containing specific text across all or selected fields. |
| list_bases | List all accessible Airtable bases with their ID, name, and permission level. |
| list_tables | List all tables in a base at a configurable detail level (identifiers only or full schema). |
| describe_table | Get detailed information about a single table, including its fields and views. |
| get_record | Get a specific record by its ID from a table. |
| create_record | Create a new record in a table with the given field values. |
| update_records | Update one or multiple existing records in a table. |
| delete_records | Delete one or more records from a table. |
| create_table | Create a new table in a base with defined fields. |
FAQ
- Can the Airtable server change a table's structure, or only its data?
- Yes. Alongside record tools, it exposes create_table, update_table, and create_field, so an agent can add a field or create a new table, not only read and write existing rows.
- Is this the official Airtable MCP server?
- No. It is a maintained community server by Adam Jones (domdomegg), not an official Airtable release. It is widely used, but plan around a community project's lifecycle.
- How does an agent query specific records?
- list_records accepts a filterByFormula expression and a maxRecords limit, and search_records does free-text matching across fields. Queries you cannot express as an Airtable formula have to be filtered after a broader read.