Airtable MCP Server: Read & Write Bases with AI

⏱️ 3 min read 🔌 MCP Server

What it is: Airtable has no MCP server of its own as of writing — this covers airtable-mcp-server, a widely-referenced community implementation (by developer domdomegg, npm package of the same name) that wraps the Airtable REST API: listing bases, reading table schemas, and querying or writing records. Other community implementations exist too; check the MCP registry if this one doesn't fit your workflow, since it isn't a vendor-maintained project and update cadence can vary.

Quick answer: Run npx -y airtable-mcp-server with a personal access token set as an environment variable, and the agent can list your bases, read table schemas, and query or update records. Scope the token to specific bases with read-only access first — Airtable PATs can be granted write and even schema-editing scopes, which is more reach than most tasks need.

Why it matters for data work

Airtable is where a lot of "the real business logic lives in a spreadsheet-database hybrid nobody wants to migrate" data actually sits — CRMs, content calendars, inventory trackers built by non-engineers. An agent that can read the schema and records directly means you can ask "which deals in the Airtable pipeline haven't moved stage in 30 days" without exporting a CSV first.

Install & configure

Generate a personal access token in Airtable (Account → Developer Hub → Personal access tokens), scoped to the specific bases you want reachable:

# Claude Code
claude mcp add airtable -e AIRTABLE_API_KEY=<your-pat> -- npx -y airtable-mcp-server

// Claude Desktop / Cursor config
{
  "mcpServers": {
    "airtable": {
      "command": "npx",
      "args": ["-y", "airtable-mcp-server"],
      "env": { "AIRTABLE_API_KEY": "<your-pat>" }
    }
  }
}

Check the specific implementation's README for the exact environment variable name and whether it also accepts the token as a CLI argument — these details vary between community forks.

How much of your base should the token reach?

Airtable's personal access tokens are scoped at creation: which bases they cover, and which of data.records:read, data.records:write, schema.bases:read, and schema.bases:write they carry. Grant the narrowest set that answers your actual question — read-only, one base — rather than an all-bases, read-write token you happen to have lying around from another integration. A base with write scope can have every record in every table edited or deleted by a single wrong tool call.

How do I keep it safe?

Because access is entirely token-scope-driven, the token itself is the whole security boundary — there's no separate read-only server flag to fall back on the way there is with a database connection string. Store the PAT the way you'd store any API secret (not committed to a repo, not pasted into a shared config), rotate it if you suspect exposure, and prefer a token scoped to non-critical bases while you're still getting a feel for how the agent behaves.

Troubleshooting

Typical issues when wiring this up:

401 Unauthorized: the PAT is missing, expired, or wasn't granted access to the base you're querying — re-check the token's base list in Airtable's developer hub.
Base or table not found: the agent needs the base ID (starts with app), not the base's display name — ask it to list accessible bases first.
Writes rejected: the token lacks data.records:write scope — that's usually intentional, not a bug.
Rate limited: Airtable's API caps requests per base per second; back off and retry rather than hammering it with bulk operations.

Author & links

Author: Community (not an official Airtable product)

Repo: github.com/domdomegg/airtable-mcp-server

License: MIT

Related skills

For a similar record-and-view style tool, see the Notion MCP server or the Google Sheets MCP server. For local spreadsheet files, see the Excel MCP server.

← Back to MCP Servers