Airtable MCP server

What it does

airtable-mcp-server reads and writes the bases a personal access token can reach. It lists bases and tables, reads, searches, creates, updates and deletes records, adds tables and fields, reads and writes record comments, and uploads attachments. It is a community package by Adam Jones (domdomegg on GitHub), MIT licensed, and Airtable does not maintain it. Statio runs version 1.14.0 with your token.

Airtable also runs its own MCP server at https://mcp.airtable.com/mcp, on all plans, signed in with OAuth or a personal access token. It covers more of Airtable, including interfaces and automations. This page is about the community package the Statio catalog runs.

Tools

Version 1.14.0 lists 16 tools: 7 read and 9 change something. Every tool sets a read-only hint, and the write tools also set a destructive hint, which the notes below follow.

Two things in the source are worth knowing before you grant the reads. list_records sends no record limit unless the caller passes maxRecords, and it keeps paging until the table runs out, so one call on a large table puts every record into the agent's context. The README says the default is 100, but the code doesn't set one. create_record and update_records always send Airtable's typecast option, which turns on best-effort conversion from strings. Airtable's docs say that conversion is off by default "to ensure data integrity".

Set it up

Both setups need a personal access token. Create one at airtable.com/create/tokens. Airtable asks for two things: scopes, which decide which API endpoints the token can use, and access, which decides which bases and workspaces it can touch. A token acts as the account that created it, limited to those scopes and bases.

The README's minimum is schema.bases:read and data.records:read. That covers the 6 table and record reads. Add the rest only for what an agent has to do:

• data.recordComments:read for list_comments, and data.recordComments:write for create_comment
• data.records:write for creating, updating and deleting records, and for attachments
• schema.bases:write for create_table, update_table, create_field and update_field

Under access, add only the bases the agent works in. A token with access to every workspace reaches every base you can open, including ones created later.

Claude Code, directly:

claude mcp add airtable -e AIRTABLE_API_KEY=pat-your-token -- npx -y airtable-mcp-server@1.14.0

Cursor, directly, in ~/.cursor/mcp.json or .cursor/mcp.json:

{
  "mcpServers": {
    "airtable": {
      "command": "npx",
      "args": ["-y", "airtable-mcp-server@1.14.0"],
      "env": {
        "AIRTABLE_API_KEY": "${env:AIRTABLE_API_KEY}"
      }
    }
  }
}

The package can also run over HTTP (MCP_TRANSPORT=http), but its README warns that mode has no authentication of its own and that a website in your browser can reach it on localhost through DNS rebinding. Use the default stdio transport on your own machine.

The client tutorials, How to add MCP servers to Claude Code and How to set up MCP servers in Cursor, explain config scopes and how to keep the token out of files you commit.

Through Statio: install Airtable from the catalog, paste the token under the server's Credentials, and grant tools under Permissions. A new server has no grants, so nobody can call it until you add some. The desktop app then writes your client configs. The manual entry is the local proxy URL with the server name from your dashboard, http://127.0.0.1:7777/airtable/mcp, added in Claude Code with claude mcp add --transport http airtable <url> or as a "url" in Cursor. Tools missing after that? Start a fresh session, then work through How to debug an MCP server that won't connect.

What to hold back

The token's scopes are the boundary that holds whatever the client allows. Airtable refuses any call the token isn't scoped for, so a token with only the read scopes can't write through this server or anything else. Start there, and add a write scope for one job at a time.

delete_records is the tool most agents should not get. It takes a list of IDs and deletes them in one call, and none of this server's tools put a record back. An agent told to "clean up duplicates" decides for itself which ones are duplicates.

update_records changes up to 10 records per call, and a loop can call it as often as it likes. Because it always sends typecast, a value in the wrong format gets converted instead of rejected, so a bad write can land without an error.

create_table, create_field, update_table and update_field change the base's structure for everyone who uses it. Renaming a field or table breaks any script or integration that looks it up by name. Keep schema.bases:write off the token unless the agent's job is building bases.

create_comment posts as the person who made the token. It's the safest write here, but everyone on the base sees it under your name.

Record fields, comments and attachments are written by whoever can edit the base, including people outside your team if the base takes form submissions. Any of that text can carry instructions aimed at the agent. Pairing the record reads with update_records or delete_records is what lets that text change your data. list_records with no maxRecords also makes that input as large as the table.

With Statio you grant each tool separately, so a reporting agent can have the reads and an intake agent can have the reads plus create_record. MCP permissions covers how grants and denies combine.

Questions