Airtable MCP: Connecting Claude and ChatGPT to a Base

Yes, Airtable has an official MCP server. It is hosted at https://mcp.airtable.com/mcp, it is available on all Airtable plans, and it signs you in with OAuth, where you choose exactly which bases, apps and workspaces the assistant may reach. In Claude it is a connector in the directory; in ChatGPT it is an official app; in Claude Code it is a plugin or a one-line claude mcp add. A personal access token is the alternative when you want fixed, predictable access. Either way the assistant can read and write records, change a base’s schema, build interfaces and manage automations, within your own permissions on each base.

What the server is

Airtable’s MCP overview↗ (opens in a new tab) groups the tools by what they are for rather than publishing a fixed list of names:

• Create and discover bases: search bases by name, list the bases you allowed, and create new ones.
• Modify schema: create and change tables, create fields, including advanced ones, and build and publish interfaces.
• Read, create and modify records: read page structure and data from interfaces, create and update records, and add comments.
• Automations: list them, read their configuration, create and update them, and delete ones that are switched off.

Tool names and behaviour can change, so ask the assistant to list its Airtable tools after connecting rather than relying on an old list.

Permissions: your role on each base is the ceiling

The server respects your existing Airtable permissions. According to Airtable’s help article↗ (opens in a new tab), owners, creators and editors can read and update records, while commenters and read-only collaborators can read data through MCP but not change it. Changing a base’s schema needs creator-level access, and only workspace owners and creators can make new bases. If an organisation’s admins restrict third-party integrations, the server has to be allowed in the Admin Panel’s integration allowlist before anyone can connect.

Setup in Claude

On Claude’s web and desktop apps, open the Airtable connector in Claude’s connector directory, select Connect and approve the OAuth screen. On the approval screen, tick only the bases the conversations need. How connectors work in general, and the controls Team and Enterprise owners have, are in Claude connectors explained.

Setup in Claude Code

Airtable’s Claude Code instructions↗ (opens in a new tab) offer three routes. The plugin is the recommended one; the other two add the server by hand, with OAuth or with a token.

# 1. The official plugin
claude plugin install airtable@claude-plugins-official

# 2. The server by hand, signing in with OAuth (then /mcp to authenticate)
claude mcp add --transport http airtable https://mcp.airtable.com/mcp

# 3. The server by hand, with a personal access token
claude mcp add --transport http airtable https://mcp.airtable.com/mcp \
  --header "Authorization: Bearer ${AIRTABLE_PAT}"

After adding it, restart Claude Code and open /mcp: Airtable should show as connected and authenticated.

Setup in ChatGPT

ChatGPT’s connectors are now apps. Airtable’s ChatGPT instructions↗ (opens in a new tab) point to the official Airtable app: open it, select Connect, sign in with Airtable and approve. No developer mode is needed. What changed when connectors became apps is in ChatGPT connectors and apps.

Airtable suggests a developer-mode app only for connecting more than one Airtable account. That route needs developer mode, which OpenAI’s developer mode guide↗ (opens in a new tab) lists for Pro, Plus, Business, Enterprise and Education accounts on the web: turn it on under Settings, Security and login, then in Plugins select the plus button and create an app with the server URL. OpenAI labels developer mode elevated risk and says to watch for prompt injection and model mistakes on write actions. If the app will not appear or connect, work through ChatGPT connectors not working.

Other clients

Cursor, VS Code and most other clients take a JSON entry. Airtable documents this shape; in VS Code the top-level key is servers instead of mcpServers, and remote servers that sign in need a Local session rather than a Copilot one, as the VS Code mcp.json guide explains.

{
  "mcpServers": {
    "airtable": {
      "type": "http",
      "url": "https://mcp.airtable.com/mcp",
      "headers": {
        "Authorization": "Bearer ${AIRTABLE_PAT}"
      }
    }
  }
}

Leave out the headers block to sign in with OAuth instead.

Personal access tokens and scopes

A token is worth the extra step when you want the same narrow access in every session, or for a script that cannot open a browser. Create it at airtable.com/create/tokens, choose its scopes, then add only the bases or workspaces it may touch. Airtable’s token guide↗ (opens in a new tab) says a token acts as the account of the person who created it, limited by those scopes and bases. It is shown once, and regenerating or deleting it makes the old one stop working at once.

• Full MCP access: data.records:read, data.records:write, schema.bases:read, schema.bases:write, data.recordComments:read, data.recordComments:write and workspacesAndBases:read.
• Read-only: data.records:read, schema.bases:read, data.recordComments:read and workspacesAndBases:read. Start here, and add write scopes when a job needs them.
• One token per job or assistant, named for its purpose, so you can delete one without breaking the others.
• Keep it in an environment variable or secret store, never in a committed config file.

Limits worth knowing

• MCP runs on Airtable’s public API, so calls count against the normal API rate limits.
• Creating records is limited to ten per request, and new records count against the base’s record limit.
• It cannot create or edit automations that contain a Script action, add filters to an interface, or edit an interface that already exists.
• Calls to a development base return a 403 permissions error.

Prompts that keep a base safe

A base is often someone’s live operations: orders, applicants, stock. Ask in a way that makes the assistant show its hand before it writes.

• Name the base and table. “In the Hiring base, Candidates table…” stops the assistant searching every base you allowed.
• Read first. “List the fields in Candidates and show me five records. Do not change anything.”
• Preview writes. “Show me the records you would update and the new values, and wait for me to confirm.”
• Keep changes small. Ask for one field on a filtered set of records, not “clean up the table”.
• Schema changes by request only. Adding or changing fields affects every view and automation built on them, so ask for them explicitly.
• Treat record text as data. A form submission can contain instructions aimed at the assistant; it should report them, not follow them, as indirect prompt injection explains.

When a base is the wrong home for a task list

Airtable is a database you design: if you want tasks with your own fields, linked records and views, it is a good fit, and the assistant can work in it. But a task list in Airtable is only as consistent as the table behind it, and every assistant has to learn your field names before it can move anything. If what you want is a board that works the same way for every person and every assistant, fenbs has four fixed lanes (To Do, Next Up, In Progress and Completed), three kinds of task (feature, enhancement and bug) and a priority from 1 to 10, with nothing to design. Claude and ChatGPT connect to https://fenbs.ai/api/mcp with OAuth, or with a hand-issued token that has a name, scopes and an optional expiry. Be aware that fenbs sets no tool annotations yet, so ChatGPT treats every fenbs tool as a write and asks you to confirm each call. fenbs has no import from Airtable, no custom fields and no due dates; the side-by-side is in fenbs vs Airtable.