Airtable MCP Just Overtook the Airtable API

For two years the rule with Airtable was simple: the REST API is the real surface, and everything else is a friendlier wrapper on top of it. That rule just broke.

Airtable's MCP server now exposes create_interface, create_page, publish_interface and create_automation — capabilities that have no equivalent in the public Airtable Web API. You can ask Claude to build a client-facing dashboard page, or describe an approval workflow in a sentence and get back a validated draft automation with conditional branches. Neither of those is possible with an API key and a curl command.

This guide is the practical version: what the server can do, how to connect it everywhere, and two complete worked examples with the actual payload shapes.

The Short Version

• The Airtable MCP server lives at https://mcp.airtable.com/mcp. It is hosted by Airtable — nothing to run yourself.
• It is included on every Airtable plan at no extra cost, and usage counts against your existing API rate limits.
• It exposes around 44 tools covering records, schema, interfaces, automations, comments and workspace discovery — all listed below.
• New: interfaces (create_interface, create_page, publish_interface) and automations (create_automation, update_automation, delete_automation).
• Automations are saved as drafts — a human enables them in the Airtable UI. Interface pages are created unpublished.
• It works with Claude, ChatGPT, Claude Code, Codex, Cursor and Amazon Quick out of the box, plus any MCP client manually.
• There is an official CLI: npm install -g @airtable/mcp-cli.

Why "MCP Is Now More Capable Than the API" Is a Real Claim

This is the part most write-ups have not caught up with, so it is worth being precise rather than hand-wavy.

The Airtable Web API is excellent at what it does: records CRUD, listing and creating bases, creating and updating tables and fields, record comments, and webhooks. What it has never had is any endpoint for the two things Airtable users actually spend their afternoons on — building interfaces and building automations. Those live entirely inside the product UI.

The MCP server changed that. Here is the honest capability comparison as of August 2026:

Read the bolded rows again. Interfaces and automations are the two artefacts that make an Airtable base a system rather than a spreadsheet, and until now the only way to produce them programmatically was a browser and a mouse.

What the API is still better at. Don't over-rotate. The REST API remains the right tool for high-volume batch writes (MCP caps record creation at 10 per request), for webhooks and event-driven pipelines, for anything running in production without an AI client in the loop, and for deterministic ETL where you want the exact same bytes every run. The interesting shift is not "MCP replaces the API" — it is that the two surfaces now have genuinely different capability sets, and choosing between them is an actual design decision.

If you are new to the credentials side of this, our personal access token guide covers the auth fundamentals that MCP still builds on, and Airtable MCP server explained is the plain-English introduction to the server itself.

The Complete Airtable MCP Tool Reference

Tool names and behaviours can change — Airtable ships to this server continuously — but this is the surface as of August 2026, grouped by what you would actually use them for.

Discovery

Records

Schema

Interfaces — the new surface

Automations — the other new surface

The ID formats you will see

MCP tools operate on Airtable internal IDs, never display names. Learning the prefixes makes debugging agent output much faster:

If an agent ever passes you a "base ID" that is a human-readable name, it has hallucinated — the correct move is always search_bases first. If the object hierarchy behind these IDs is unfamiliar, our bases vs tables vs workspaces explainer covers it.

Connecting It: Every Client, Step by Step

Claude (web and desktop)

The fastest path in existence. Open the official Airtable connector in Claude's connector directory, click Connect, and authorise through OAuth. No config file, no token, no terminal. Airtable's registered OAuth client ID for Claude is 266cb1c0-b4ae-43a1-b7d7-c2a563667d95, which is what your admin will need if your workspace enforces an integration allowlist.

Best for: querying and updating data through natural conversation, and — new in this release — asking for an interface page and getting one.

ChatGPT

Open the official Airtable app inside ChatGPT, select Connect, sign in to Airtable, and authorise. OAuth client ID: 7a713e1a-3d99-4fdf-b59a-311bdf94ba97.

If you need a custom connector instead (some enterprise setups do), enable Developer mode under Settings → Apps → Advanced Settings, create an app pointing at https://mcp.airtable.com/mcp, and configure OAuth using either Dynamic Client Registration or a user-defined OAuth client with client_secret_basic as the token endpoint auth method.

Claude Code

The official plugin is the recommended route:

claude plugin install airtable@claude-plugins-official

Restart Claude Code, open the /plugin menu, find Airtable MCP, and authorise through OAuth.

To wire it manually instead:

claude mcp add --transport http airtable https://mcp.airtable.com/mcp

Then open /mcp inside Claude Code and complete browser authentication.

Or commit it to a project so your whole team inherits it, via .mcp.json in the repo root (or ~/.claude.json for a personal global setup):

{
  "mcpServers": {
    "airtable": {
      "type": "http",
      "url": "https://mcp.airtable.com/mcp"
    }
  }
}

Claude Code is the strongest client for the new capabilities, because interface and automation building is iterative — you create, inspect, adjust, and re-create, and a coding agent handles that loop far better than a chat window.

Codex

codex plugin add airtable@openai-curated

Then open Plugins in the app, search for Airtable, and click Add. Manually:

codex mcp add airtable --url https://mcp.airtable.com/mcp
codex mcp login airtable

Or in ~/.codex/config.toml:

[mcp_servers.airtable]
url = "https://mcp.airtable.com/mcp"

Cursor

Use the Airtable MCP install deep link from Airtable's docs, then go to Cursor Settings → Tools & MCP → Installed MCP servers, click Install, and authorise. Manually, edit ~/.cursor/mcp.json (or .cursor/mcp.json in the project):

{
  "mcpServers": {
    "airtable": {
      "type": "http",
      "url": "https://mcp.airtable.com/mcp"
    }
  }
}

Any other MCP client

Two supported auth paths.

OAuth. Register an OAuth client through Airtable's developer flow with the redirect URI your tool supplies, and request these scopes:

data.records:read
data.records:write
schema.bases:read
schema.bases:write
data.recordComments:read
data.recordComments:write
workspacesAndBases:read

Then point the client at https://mcp.airtable.com/mcp with your client ID and complete the authorisation flow.

Personal access token. For headless environments where a browser OAuth flow is impractical, create a PAT with the same scopes and send it as a header:

Authorization: Bearer pat_your_token_here

For a read-only agent — which is what you want for anything customer-facing or analytical — request only data.records:read, schema.bases:read, data.recordComments:read and workspacesAndBases:read. An agent that physically cannot write is worth more than an agent you have asked nicely not to.

Choosing which client

The Official CLI

This is the piece most people miss: everything above is also available from a terminal, with no AI in the loop at all.

npm install -g @airtable/mcp-cli

Or via the standalone installer:

curl -fsSL https://raw.githubusercontent.com/Airtable/airtable-mcp-cli/main/install.sh | sh

Authenticate once:

airtable-mcp configure     # prompts for a personal access token
airtable-mcp whoami        # confirms who you are authenticated as
airtable-mcp logout        # clears stored credentials

Credentials are written to ~/.airtable/cli.json with 0600 permissions. In CI or a container, skip configure entirely and set AIRTABLE_TOKEN instead.

The clever bit: the CLI does not hardcode its commands. It discovers them from the MCP server at runtime and caches the list for 60 seconds, so new server-side tools show up as new commands without you upgrading anything.

airtable-mcp tools                  # human-readable list of available tools
airtable-mcp tools --json           # machine-readable, for scripting
airtable-mcp tools --refresh        # bypass the 60-second cache
airtable-mcp list-bases
airtable-mcp list-records --baseId appXXXXXXXXXXXXXX --tableIdOrName Tasks

Useful flags:

Scripting pattern — arguments in via stdin, quiet mode on, token from the environment:

export AIRTABLE_TOKEN=pat_xxx

echo '{"baseId":"appXXXXXXXXXXXXXX","tableIdOrName":"Tasks"}' \
  | airtable-mcp list-records --input - -q \
  | jq '.records | length'

A realistic cron use: every weeknight at 6pm, pull anything overdue and pipe it into a Slack webhook. Put the pipeline in a wrapper script rather than inlining it in the crontab — cron does not read your shell profile, so any variable you exported interactively is simply empty when it runs, and a crontab entry has to be a single line (there is no backslash continuation).

#!/bin/bash
# /usr/local/bin/overdue-to-slack.sh — chmod 700, it holds a token
export AIRTABLE_TOKEN='pat_xxx'
export SLACK_WEBHOOK='https://hooks.slack.com/services/XXX/YYY/ZZZ'

/usr/local/bin/airtable-mcp list-records \
  --baseId appXXXXXXXXXXXXXX --tableIdOrName Tasks --json -q \
  | /usr/local/bin/jq -r '...' \
  | /usr/bin/curl -s -X POST -H 'Content-type: application/json' -d @- "$SLACK_WEBHOOK"

Then the crontab entry is one line:

0 18 * * 1-5 /usr/local/bin/overdue-to-slack.sh

If you would rather not have a PAT sitting in the script, run airtable-mcp configure as the same user cron runs as and drop the AIRTABLE_TOKEN line — the CLI reads ~/.airtable/cli.json, which is already 0600.

This is genuinely a new option for teams: MCP-level capability, no LLM, no per-token cost, no non-determinism. If your only reason for hand-rolling an API client was scripting, the CLI now covers it — and it covers interfaces and automations too, which your API client could not.

Worked Example 1: Build an Interface From a Prompt

Here is the flow an agent actually runs, so you know what to expect and where to intervene.

Step 1 — find the base and learn the schema.

search_bases("Client Delivery")        → appXXXXXXXXXXXXXX
list_tables_for_base(appXXXXXXXXXXXXXX) → tblProjects, tblTasks, field IDs and types
get_table_schema(...)                   → select choice IDs (needed for any filter)

That third call matters more than it looks. Filters on single-select and multi-select fields take choice IDs (sel...), not the label you see in the UI. Skipping get_table_schema is the single most common cause of an agent building a page that silently shows nothing.

Step 2 — learn the config shape. The agent calls describe_page_type for the page type it plans to build. There are two page types:

• visualization — a single view of one table
• dashboard — multiple sections, each backed by a table, each holding several elements

For a visualization page, the supported visualisation types are kanban, list, calendar, gallery, grid, timeline and recordReview. recordReview is the interesting one — a record list on the left, a detail panel on the right, which is the layout most internal tools actually want.

For a dashboard page, the supported elements are number, barChart, lineChart, scatterChart, pieChart, donutChart, list, pivotTable, kanban, gallery, calendar, timeline and grid. Airtable renders them in visual groups automatically: numbers at the top, then charts, then visualisations, preserving your array order within each group.

Step 3 — create the interface and the page.

create_interface(baseId, name: "Delivery Dashboard")  → pbdXXXXXXXXXXXXXX
create_page(baseId, interfaceId, name, pageType, pageConfiguration)

A dashboard page configuration looks roughly like this:

{
  "sections": [
    {
      "tableId": "tblProjectsXXXXXX",
      "title": "Active projects",
      "elements": [
        { "type": "number" },
        { "type": "barChart" },
        { "type": "grid" }
      ],
      "recordScopeFilters": {
        "operator": "and",
        "operands": [
          { "operator": "=", "operands": ["fldStatusXXXXXXXX", "selActiveXXXXXXX"] }
        ]
      },
      "dropdowns": [{ "fieldId": "fldOwnerXXXXXXXXX", "name": "Owner" }]
    }
  ]
}

Three concepts are worth internalising because they are what separate a usable page from a demo:

recordScopeFilters is a security boundary, not a convenience filter. Records excluded by it are never sent to the client at all. This is how you build a page that shows a person only their own records, or a client only their own projects. End users cannot change it. Each dashboard section can have its own independent scope.

tabs and dropdowns are the user-facing controls. Tabs are named filters the viewer picks between (an "All" tab is always added automatically — don't include one). Dropdowns expose a single field as a runtime filter control. They are mutually exclusive — supply one or the other on a given page or section, never both. Dropdowns support checkbox, date, dateTime, collaborator, linked-record and select fields, plus formula/lookup/rollup fields whose result type is one of those.

Filters use structured operands, not formula strings. Each condition is an operator plus an operands array where the first element is a field ID. Date conditions take a mode object — {"mode": "pastNumberOfDays", "numberOfDays": 30, "timeZone": "America/New_York"} — rather than a date string, and the time zone is required.

Step 4 — review, then publish.

publish_interface(baseId, interfaceId)

Pages are created against the draft version. Nothing your team sees changes until you publish, which gives you a real review gate. Ask the agent to describe what it built and confirm before you call this.

The one real limitation: editing an existing interface page is not supported yet. You can create pages and delete pages, but you cannot ask an agent to restructure a page someone built by hand last quarter. In practice this means the workflow is "generate a first draft fast, then refine in the UI" — which, for a page you would otherwise have spent 40 minutes assembling by hand, is still a very good trade. If you want the manual side of this, see our Airtable Interface Designer guide and how to build an Airtable dashboard.

Prompts that produce good interfaces

Vague prompts produce vague pages. These work:

• "In my Client Delivery base, create an interface called Account Manager View with a record review page over Projects, scoped to projects where Owner is the current viewer, with a dropdown filter on Status."
• "Build a dashboard page over Deals with a number element for total pipeline value, a bar chart of deals by stage, and a grid of deals closing in the next 30 days. Don't publish it — show me the config first."
• "Create a timeline page over Campaigns using Start Date and End Date, with tabs for Q3 and Q4."

Note the pattern: name the base, name the table, name the page type, state the filter, and say whether to publish.

Worked Example 2: Build an Automation From a Prompt

Automations are where the MCP server gets genuinely deep, and where it is worth understanding the model rather than just prompting and hoping.

Always start with get_create_automation_instructions. It returns the complete spec — expression language, wrappers, function catalog, the full trigger and action input catalogs, known pitfalls, and a worked example. Airtable explicitly recommends calling it once per session before building anything. A good agent does this automatically; if yours doesn't, tell it to.

The shape of an automation

An automation is a trigger plus an ordered array of nodes. Nodes come in three flavours:

1. Action nodes — do one thing (createRecord, sendEmail, sendToSlack…)
2. repeatingGroup — a for-each loop; the inner nodes run once per item in an array
3. conditionalGroup — if / else-if / else branches, up to 25 branches, each with up to 50 comparisons

Every node carries a key that later nodes use to reference its output.

Trigger types you can create

The curated set — the ones with full guidance and examples — is:

Beyond those, the server also supports emailReceived, rowCommentCreated, inputReceivedFromConnection, agentTriggerReceived, and third-party triggers for Google Sheets, Google Forms, Google Calendar and Microsoft Outlook.

Action types you can create

The curated actions — createRecord, updateRecord, findRecords, sort, sendEmail, sendToSlack, gmailSendEmail, microsoftOutlookSendEmail, aiGenerate, aiGenerateStructuredOutput — cover the overwhelming majority of real workflows. customScript is there too, with an outputSchema you declare so downstream nodes can reference what the script sets via output.set().

Beyond the curated set the server can create Jira, Azure DevOps, Salesforce, GitHub, Google Docs, Google Sheets, Google Calendar, Outlook, Microsoft Teams, Twitter, Facebook Pages, Hootsuite and Twilio actions, plus aiGenerateImage and noOp.

Anything touching a third-party service needs an externalAccountId (an eac... ID) from list_external_accounts. If you have never connected Slack to that base, the agent cannot invent the connection — connect it once in the Airtable UI first.

The expression language

This is the part that trips people up. Every trigger and node input is an expression, not raw JSON. There are four forms:

A minimal, complete automation — when a record is created, set its status:

{
  "trigger": {
    "type": "recordCreated",
    "inputs": { "tableId": "tblXXXXXXXXXXXXXX" }
  },
  "nodes": [
    {
      "key": "node1",
      "type": "updateRecord",
      "inputs": {
        "tableId": "tblXXXXXXXXXXXXXX",
        "rowId": { "template": [{ "$ref": "trigger", "path": ["id"] }] },
        "updateRecordMethod": "customFields",
        "fields": {
          "fldStatusXXXXXXXX": { "template": ["In Progress"] }
        }
      }
    }
  ]
}

The validate-and-retry loop

create_automation validates before it saves. If isValid comes back false, nothing was saved and you get an errors array pointing at the bad inputs. The correct behaviour is to fix and call again — and after two or three failed attempts, to stop looping and surface the errors to a human rather than burning tokens guessing. Tell your agent this explicitly if it has a habit of retrying forever.

Drafts only — and why that's the right design

On success, only the draft configuration is saved. The automation is off. The response includes an automationUrl; you open it in Airtable, review the trigger and every action, and turn it on yourself.

This is a deliberate and, frankly, correct safety boundary. An automation is a piece of software that runs unattended against live business data — an agent that could silently enable one would be a genuinely bad idea. The draft gate means the worst case of a hallucinated automation is a confusing draft you delete, not two thousand wrong emails.

Note the corollary: delete_automation only works on inactive automations. To delete a running one, turn it off in the UI first.

Prompts that produce good automations

• "In the Client Delivery base, create an automation: when a Project record's Status changes to Blocked, post a message to the #delivery Slack channel with the project name, owner and blocker notes. Use my connected Slack account."
• "Create an automation that runs every weekday at 9am, finds all Tasks with a Due Date in the past and Status not equal to Done, and for each one sends the assignee an email." (That "for each one" is what produces a repeatingGroup.)
• "When a form is submitted, branch on Request Type: hardware requests create a record in IT Requests, software requests create a record in Procurement, everything else goes to Triage." (That's a conditionalGroup with three branches.)

Compare these to what you would build by hand — our Airtable automation guide and automation examples show the manual equivalents, including what those conditional branches look like in the UI.

Permissions, Scoping and Security

The MCP server enforces Airtable's existing permission model rather than bypassing it. That is the single most important security fact about it.

Control which bases the integration can reach. Go to https://airtable.com/?integrations=thirdParty, or Profile → Integrations → Third-party integrations. Add or remove specific bases and interfaces. Do this deliberately — the default instinct to grant everything is exactly what you want to avoid on a base containing customer PII or financials.

Interface-only access is a real feature, not a limitation. If a base is shared with someone through an interface rather than as a full collaborator, MCP still works for them — scoped to what that interface exposes. This is a clean pattern for giving an agent access to a curated slice of a base without handing over the base.

Enterprise: centralised read-only. Admins who want a stable, organisation-wide connection that does not depend on any individual's permissions can create a service account with read-only access, generate a PAT from it with only the read scopes, and distribute that. Everyone sees identical data, and the connection survives people leaving. If your organisation enforces an integration allowlist, the admin path is Admin Panel → Settings → Integrations & development → Third party integration allowlist → Allow integration, then paste the client ID.

Practical rules we apply on client projects:

1. Start read-only. Expand to write only once you have watched the agent work for a week.
2. Connect one base, not all of them. Least privilege is cheap here.
3. Keep the draft gates. Do not build tooling that auto-publishes interfaces or auto-enables automations.
4. Treat revert_action as a seatbelt, not a plan. Know it exists; don't rely on it.
5. Rotate PATs like any other credential, and never commit one to a repo.

More on the underlying model in how to set up Airtable permissions and our Airtable security overview.

Limits, Gotchas and Known Rough Edges

Things that will bite you, collected so they don't have to:

• 10 records per create call. Bulk imports need chunking; an agent creating 400 records will make 40 calls and may hit rate limits doing it.
• MCP shares your API rate limits. Agent traffic and API traffic compete. On a busy base, a chatty agent can throttle your production integrations.
• Automations are drafts. Always. Plan for the human step.
• Deleting an automation requires it to be inactive first.
• Interface pages cannot be edited, only created and deleted.
• Select filters need choice IDs. Always get_table_schema before filtering.
• Date filters need a time zone. Every date mode object requires an IANA time zone string.
• Tabs and dropdowns are mutually exclusive on a page or section.
• Third-party actions need a pre-connected account. list_external_accounts first.
• Managed app development bases return 403. Calls against production bases where the components are installed work fine.
• Tool names and behaviours change. Airtable says so explicitly. Anything you script against the CLI should tolerate a tool list that shifts — which is exactly why the CLI discovers commands at runtime.
• Interface-only users cannot use table tools. list_tables_for_base will return a permission error; use the page tools.

Where This Leaves the Airtable Stack

The practical read on this release, from someone who builds these systems for clients:

The first draft of an Airtable system is now something you can prompt. Base, tables, fields, a working interface, and a set of draft automations — in an afternoon rather than a fortnight. That is a real change in the economics of getting started.

The last mile still isn't. Correct field types under load, permission models that survive an audit, interfaces that a non-technical user can actually operate, automations that fail gracefully at 2am — these still need judgement. The agent gives you 70% in an hour; the remaining 30% is where systems live or die.

The interesting new pattern is agent + CLI + human review. Use a conversational client to design, the CLI to run scheduled maintenance deterministically, and the draft gates as the review boundary between them. That is a substantially better operating model than either "everything by hand" or "let the AI run free".

If you want the broader agent picture, see types of Airtable AI agents, Claude + MCP building Airtable bases, and what Airtable Omni is for how Airtable's own in-product AI compares to driving it from outside via MCP. For the conceptual grounding, what MCP means for Airtable is the plain-English version of this article.

Getting Started Today

1. Connect one client. Claude or ChatGPT if you want to talk to your data; Claude Code if you want to build with it.
2. Scope it to one base. Preferably one that isn't business-critical.
3. Confirm the connection. "How many records are in my Tasks table?"
4. Try the new stuff. "Create a dashboard page over Projects with a number element for open projects and a bar chart by owner. Don't publish it."
5. Then an automation. "Draft an automation that Slacks me when a project goes to Blocked." Open the automationUrl, read it properly, then decide.
6. Add the CLI once you find yourself doing the same query twice.

If you would rather have this designed properly the first time — permissions modelled, interfaces built for the people who actually use them, automations that hold up — we do this for a living. We have shipped MCP-backed Airtable systems across CRM, operations, client portals and professional services, and we know which edges are sharp.

The Bottom Line

The Airtable MCP server crossed a threshold with this release. It is no longer a friendlier front-end for the API — it does things the API cannot do at all. Interfaces and automations, the two artefacts that turn a base into a business system, are now buildable from a sentence, in Claude, in ChatGPT, in your editor, or from a shell script.

The draft-and-publish gates mean you keep control of what actually ships. The permission model means an agent can only do what you could do. And the CLI means none of this requires an LLM in the loop if you don't want one.

If you have been treating MCP as the lightweight option, it is time to re-evaluate. Right now it is the most capable programmatic surface Airtable has.