Most table connectors stop at reading and writing records; this one creates tables and fields too, so a base can be reshaped in the same conversation that fills it. Two limits shape how you batch work: ten records per update call, and 5 MB per attachment, with anything larger having to arrive as a public URL on a record write.
An Airtable client covering both planes of a base: the data (records, comments, attachments) and the schema (tables and fields). What it can reach is exactly what your personal access token can reach.
- Record reads with Airtable's own query surface: a filterByFormula expression, a sort, a named view, a chosen field subset and a record cap that starts at 100
- Free-text search across every text field, or a named subset of them, for when you do not have a formula in mind
- Record writes: create one, update up to 10 in a single call, delete by id, and fetch one back by id
- The schema as data — every base the token can reach, the tables inside one, and a table described down to its fields, at the detail level you ask for
- Schema changes in place: create a table, rename or re-describe it, add a field, rename or re-describe a field
- Comments on a record, read and written, including a reply to an existing comment
- A file uploaded straight into an attachment field, up to 5 MB, with anything larger going in as a public URL through a record write
An Airtable personal access token in AIRTABLE_API_KEY, and the scopes decide what works: schema.bases:read and data.records:read to look, schema.bases:write and data.records:write to change anything, and the record-comment scopes for the comment tools. Grant it access only to the bases you want reachable — the base listing returns exactly what the token can see. Node.js for npx, or a published Docker image or .mcpb bundle instead. Attachment upload needs a record that already exists.
One command plus a key — npx -y airtable-mcp-server, then supply credentials