Setup guide
Point Claude at a base and it works with the fields you actually built, not the ones it would have guessed.
Before you start
Airtable's own connector is in the directory, verified, and it brings your structured data to Claude. This page's route is a different shape: the whole Airtable tool list behind one endpoint, with you choosing which of it Claude can touch.
Airtable Verified
Versus
Connecting FloConnector connects Airtable, and Airtable is one of 60 connectors the same endpoint can carry. You do this setup once, not once per app.
Step one
Step two
Control
A profile carries only the tools you switch on, and the endpoint exposes only that profile. That is the whole permission model, and it is set before anyone connects.
Airtable Connected 10/25 5 read 5 write
Tick a row to include it, or flip Read only to lock every write off at once.
FloConnector holds the Airtable credential, encrypted before it is stored, and calls Airtable on the model's behalf. Claude sees the tools and their results, never the credential behind them.
Once it is connected
Each of these runs real Airtable tools, named underneath so you can see what Claude is actually calling. 10 of the 25 tools are covered here.
What is in the content calendar for next month, and what is still missing an owner?
Rows from that table in the date range, filtered on the field your base really uses for an owner rather than one Claude assumed was there.
list_bases get_base_schema list_records Add these six applicants to the hiring base and set them all to screening.
Six records written with the field names and option values the table actually has, so a single select does not reject a value that was never on its list.
get_base_schema create_records Which records changed status this week, and what did people say on them?
The rows matching the filter, each with its comment thread read back alongside it.
list_records list_comments Set the three overdue rows to blocked and add a note on each saying why.
The named fields changed, everything else on those rows untouched, and a comment on each explaining the change.
list_records update_multiple_records create_comment Set up a table for supplier quotes in the ops base, with the fields we use on the others.
A new table in that base, its fields modelled on the shape of the tables already there rather than invented from the name.
list_bases get_base_schema create_table create_field Are there attachments on last quarter's invoice rows, and how big are they?
The rows with something in the attachment field, and each file's name, type and size. It reads the details; the file itself stays in Airtable.
list_records get_attachment_info Troubleshooting
Claude Desktop sits on Connect after you signed in
The sign-in has usually succeeded. Check the profile in your dashboard: if the grant is there the connection is live, and restarting the desktop app clears the stale button. It is a client-side issue, not something the server can fix.
The connector saves but no tools appear
Disconnect and reconnect it once. If it is still empty, check in the dashboard that the connection behind the profile is still connected and that you are an assigned member of that profile.
The first load is slow on a very large profile
A profile exposing hundreds of tools takes longer to load, and a model given too many tools chooses worse. Split the work across two profiles rather than exposing everything at once. This is the failure mode most MCP write-ups name and never solve.
Only the ones you ticked when you connected. Airtable's own consent screen asks which bases to grant, and that choice is the outer boundary; the profile then decides which tools exist inside it. Reconnect if you want to change the list later.
No. You approve access on Airtable's own page, and the token that comes back is encrypted before FloConnector stores it. Claude sees the tools and their results, never the credential behind them.
Not unless you switched the delete tools on, and they are flagged in the picker for a reason: an Airtable delete is permanent, with no bin to fish it back out of. A profile built for reporting and updates has no route to one.
It reads them the way the API returns them. Formula and rollup fields come back with their computed value, and a linked record comes back as the record ID it points at, so Claude follows the link with a second read when it needs the name behind the ID.
It takes both layers. Connect only the bases they should reach, and build them a profile carrying the list and read tools and nothing that writes. The profile alone is not enough, because it controls which tools exist rather than which base they touch.
Yes. A profile URL is a standard hosted MCP server, so it is one paste into a different menu, with nothing to redo on the Airtable side.
Airtable offers a patch update that changes only the fields you name, and a PUT update that clears every field you did not. Both sit in the picker under nearly the same name. Switch on the patch one, and leave the PUT one off unless replacing a whole row is exactly what you meant.
A base is whatever somebody built, so field names, types and select options are not guessable from the outside. The schema tool is what makes a write land. Without it on the profile you get polite guesses and failed writes, and the failure is not obvious from the question.
Creating, updating and deleting records are batched at ten per call, which is Airtable's limit rather than ours. A large import still works, it just runs as a run of calls, and if it stops halfway the records already written stay written.
Your turn
One connection, one endpoint, and 25 Airtable tools your AI can actually run. Start free with 1,000 tool calls and see what your own first week looks like.
