Is deleting Airtable records through the MCP server reversible?

Only partly. Deleted records go to Airtable's UI trash and are restorable there for about 7 days — but there is no API restore, so an agent that deletes cannot itself undo it, and after the window the data is gone. A bulk update that overwrites many rows is worse: prior values aren't returned by the call, so reversal is hard even though it isn't technically a delete.

MCP field guide / Airtable

// mcp field guide · database / no-code

Airtable MCP server

Q: Can the Airtable MCP server delete a table or a whole base?

No. The community domdomegg/airtable-mcp-server exposes no delete-table, delete-field, or delete-base tool (verified against source), and Airtable's official server likewise cannot delete tables or fields. The only delete tool is delete_records. So the catastrophic schema-destruction scenario is not reachable through either server today.

The scary scenario people imagine — an agent deleting a whole table or base — isn't even reachable here. Neither the community nor the official server exposes a delete-table/base tool. The genuine risk is quieter: a bulk delete_records or a bulk overwrite that no schema-destruction tool would ever cause. Here's the sourced read.

Community: domdomegg/airtable-mcp-server (MIT, local) Official: mcp.airtable.com (hosted, all plans)

GUARD FIT · READS + SINGLE WRITES

LOW

List/search/read and one-off create/update are low-risk and UI-trash-recoverable. Little to gate.

GUARD FIT · BULK DELETE / OVERWRITE

STRONG

Bulk delete_records and bulk update_records — data loss/overwrite recoverable only via a 7-day UI trash, with no API restore.

Overall fit: STRONG on the bulk-mutation surface; weak elsewhere — and schema annihilation isn't on the menu.

Two servers

Community — domdomegg/airtable-mcp-server (npm, MIT, v1.14.0), the most-used self-hosted/local option: a thin, zero-LLM wrapper over the Airtable REST API, authenticated with a Personal Access Token whose scopes are its permissions.¹ Official — Airtable Inc.'s hosted server at mcp.airtable.com/mcp (GA, included on all plans, OAuth/PAT), which covers a similar record/schema surface, adds Airtable-specific objects (interface pages, automations, base creation), and deliberately omits table/field deletion.³

Tools by risk surface

Names below are verbatim from the community server (16 tools). The official server uses different names.

Tier	Tools
read-only	`list_bases`, `list_tables`, `describe_table`, `list_records`, `search_records`, `get_record`, `list_comments`
mutating	`create_record`, `update_records` (bulk-capable), `create_table`, `update_table`, `create_field`, `update_field`, `create_comment`, `upload_attachment` (wire name unverified)
destructive	`delete_records` (bulk-capable) — the only delete tool

The notable absence (verified against source): there is no delete_table, delete_field, or delete_base tool in the community server, and the official server likewise cannot delete tables or fields. The catastrophic schema-destruction surface simply isn't reachable — so "an agent could nuke your base" is false for Airtable today. (Whether the official server exposes record deletion at all is unverified from its docs.)

Real use cases

Natural-language queries. "Which deals closed last week?" via search_records/list_records — no formulas.

AI data entry / enrichment. Create and update rows from unstructured input (emails, docs), then comment status.

Schema scaffolding. Bootstrap a base's tables and fields from a described data model (official server extends this to interfaces and draft automations).

Where a human-approval guard fits

Reads & single writes → low. List/search/read change nothing; a single create_record/update_record is low blast radius and UI-trash-recoverable. Gating them is friction.

Bulk delete & bulk overwrite → strong. This is the honest sharp edge:

Bulk delete_records — a filter that selects more rows than intended is a mass deletion. Deleted records sit in Airtable's UI trash for ~7 days, but there's no API restore, so the agent that deleted them can't undo it, and after the window they're gone.
Bulk update_records — a wrong field mapping across many rows silently overwrites data, and the call doesn't return the prior values, so reversal is hard. Treat wide/bulk updates as near-destructive.
Schema edits (update_field/update_table) — reversible in principle, but a renamed field can break downstream automations and formulas. Medium-to-strong.

The honest calibration: Airtable already gives you a 7-day trash net for deletes — so a guard's job here isn't to prevent an unreachable "delete the base," it's to catch the bulk record delete or overwrite that only a human notices before commit, and that the trash doesn't fully cover (overwrites aren't in the trash at all). That's the right-sized control — gate the dangerous subset, not everything.

Gate the bulk delete, pass the reads

ChronoMCP holds bulk delete_records and wide update_records for a human — with an honest note that the API can't restore what it removes.

Read the quickstart → More MCP profiles

Sources

Community — domdomegg/airtable-mcp-server (tool names, no delete-table/base, verified in source): github.com/domdomegg/airtable-mcp-server
npm — airtable-mcp-server (v1.14.0, MIT): npmjs.com/package/airtable-mcp-server
Airtable — official hosted MCP server docs (cannot delete tables/fields): support.airtable.com/docs/using-the-airtable-mcp-server

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Airtable, and domdomegg/airtable-mcp-server is an independent community project. The 7-day trash / UI-only restore is Airtable platform behavior. Official-server tool names and any record-delete capability are docs-sourced and partly unverified; risk groupings are our classification. Sources current as of Aug 2026 — check the source links.