New MCP capabilities let teams file work into Airtable and ask questions about it directly from Claude or ChatGPT, without base access or training.
Airtable's MCP server just picked up two capabilities built for people who don't build in Airtable at all: form submissions and the ability for interface-only users to query, create, and update records. Team members can now file work into a base and ask an AI model questions about it, straight from Claude or ChatGPT, without ever opening Airtable or needing base access.
Key takeaways
- MCP form submissions let anyone file requests, feedback, or assets into Airtable through natural-language queries — no base access or training required.
- MCP interface reading lets a connected model answer questions against your data using the same interface permissions a person would have.
- Agents act through interfaces and respect existing interface-level permissions, so nobody sees or touches more than they normally could.
What is Airtable's MCP server
Airtable's MCP (Model Context Protocol) server lets AI models like Claude and ChatGPT connect to your Airtable bases and act within your existing permissions. Yesterday's update was for builders — creating tables, interfaces, and automations. This update is for people that interact with the base as end-users, making submissions through forms or querying the data, without needing to build bases themselves.
The permissions model is simple: MCP access mirrors whatever level you already have in Airtable. Owners, Creators, and Editors can set up the connection and read or update the records they're already permitted to touch; Commenter- or Read-only users can read through MCP but can't make changes. For the complete list of what MCP can do — including the interface-reading capability this post is about — see Using the Airtable MCP server.
Governed intake from any agent
A team member describes a request, an asset, or a piece of feedback in plain language to a connected model — Claude, ChatGPT, or any other agent — and it's filed straight into the right base, scoped to the same permissions that form would normally enforce. No need for a form link, base access, or training.
The model doesn't need to be told where the form lives. It discovers the right page in the base on its own — whether that's a form embedded in an interface or a standalone form — reads the required fields, and validates before submitting. Linked-record fields resolve correctly too: a bug filed against a project you just created lands linked to that same project with no extra step needed.
Live Q&A with permissions intact
People with interface-only access (no base-level permissions) can now ask a connected model questions about that data and get answers scoped to exactly what their interface already shows them. "What's blocking the launch?" or "which campaigns are live?" get answered the same way a person reading that interface would see it, all pulling from your team’s trusted data in Airtable and respecting any interface permissions a base creator has set up.
This is a meaningfully different path than what users with base access have: instead of listing tables or pulling base schema, the model calls a "list pages for base" tool and then "list records for page" — everything goes through interfaces instead of the data layer, so there's no way for it to see more than the interface itself exposes.
Intake automations: what happens after someone submits
A submission through MCP doesn't dead-end in a table. Whatever automations already trigger on a native form — approval routing, task handoffs, notifications — fire the same way here, because the record lands in the same base through the same underlying structure. Intake through conversation plugs into the workflow you've already built — including automations MCP helped you set up in the first place.
Why Airtable interface permissions still matter here
Since it's easy to misinterpret "AI can just file this for me" as a permissions workaround: it isn't one. Agents act through interfaces and inherit interface-level permissions exactly as a person would. Someone with interface-only access still only sees what that interface exposes — the model doesn't get a backstage pass the person filing the request doesn't already have.
Getting started with Airtable's MCP server
If you already connected MCP after Monday's post, you're set — this update runs through the same connection you set up then, you can always manage which bases and apps a tool has access to by updating your integration settings. If not, head to our getting started with MCP page to see instructions on how to connect different AI tools
This is Day 2 of a five-day series. Catch up on Day 1: Airtable's MCP server now builds interfaces and automations.
Don't miss day 3
Frequently asked questions
Yes, we’ve built interface-specific tools to support these workflows. A connected model can query and answer questions using the same interface a person already has access to, even without base-level permissions.
They need whatever access level Airtable already requires to submit that form or interact with that interface — MCP doesn't grant new access, it works within permissions your team already has.
No. MCP mirrors your existing Airtable permissions, so a model can only read or change what you could yourself.
Yes. Submissions and edits made by an AI tool using MCP land in the same underlying base and are visible to anyone with the right permissions, the same as if they'd been entered directly in Airtable. When you look at the revision history for a record, you can audit which AI tool that made the update.