# Airtable > Canonical: https://www.yalc.ai/mcps/airtable/ Spreadsheet meets database, surfaced inside Claude Code via the Airtable MCP. ## Categories - operations **Website:** https://airtable.com/ **Repo:** https://github.com/domdomegg/airtable-mcp-server ## Glance - Auth: Personal access token - Maintainer: Community - Tools: Read + write + schema **Install Command:** claude mcp add airtable --env AIRTABLE_API_KEY=patXXX -- npx -y airtable-mcp-server **Install Notes:** Generate a Personal Access Token at airtable.com/create/tokens with the scopes you need (data.records:read, data.records:write, schema.bases:read). Replace `patXXX` with the token, run the command, restart Claude Code. The community `airtable-mcp-server` (maintained by domdomegg) covers reads, writes, and schema introspection. **Yalc Fit Score:** 7 **Yalc Verdict:** The right MCP when the team is already on Airtable instead of Notion. For greenfield Yalc setups, Notion plus its official MCP is the safer default. ## Plain Description The Airtable MCP exposes Airtable's REST API (records, tables, schema, attachments) as native Claude tool calls. Coverage spans listing records, creating, updating, deleting, schema introspection, and base navigation. Auth is a Personal Access Token, simpler than OAuth for solo or small team use. For Yalc operators on Airtable, this MCP unlocks the same workflows our Notion users get from the official Notion MCP. Where Notion's strength is docs plus database, Airtable's strength is power user database features (formulas, automations, relational links, granular permissions). For data heavy GTM workflows that need formula columns and complex relations, Airtable plus this MCP is a strong pairing. ## Yalc Framework **Workflow Step:** route ### Workflow Narrative The Airtable MCP sits at the **route** node when Airtable is the team's CRM or campaign tracker. Most Yalc workflows that touch Airtable (lead writeback, campaign state, content calendar) flow through here. The MCP pairs with Yalc skills the same way Notion does: enrichment writes records, qualification updates statuses, monthly reports read tables. The semantics are the same; the underlying database is just different. **Workflow Position:** The CRM and database layer when Airtable is the system of record. Yalc reads tables, writes records, runs formula-aware queries, and manages relational links. ### Prompt Patterns - Yalc, for every record in the "Q3 outbound" Airtable view with status "qualified", create a HubSpot contact, fire a Unipile invite, and update the Airtable row with timestamp and assigned AM. → Yalc reads via the Airtable MCP, fires downstream actions, writes back state. - Yalc, query the "Campaigns" Airtable base for every record where reply_rate is below 5 percent and sent_count is above 100. Surface the 3 worst performers with recommendations. → Yalc applies formula filters via the Airtable MCP, scores via Claude, returns digest. - Yalc, take this client onboarding markdown brief and create a fresh Airtable base under the client's workspace with tables for Leads, Campaigns, Content, and Posts. → Yalc creates the schema via the MCP, configures relations, writes the initial rows. ### Chaining **Upstream:** Any Yalc workflow → Airtable MCP (writeback) **Downstream:** Airtable record change → webhook → Yalc workflow trigger ### Anti Patterns - Don't dual run Airtable and Notion as the CRM. Pick one as the source of truth. Mirroring is fragile and writes diverge fast. - Don't write records without checking the schema first. Airtable's field types are stricter than Notion's; bad payloads return validation errors. The MCP exposes schema introspection for this reason. - Don't max out Airtable's record limits without budgeting. Free tier caps at 1,200 records per base; paid tiers go to 50k. Yalc workflows at scale should use Airtable's larger plans or move to a dedicated database. **Compatibility:** Works in Claude Code, Claude Desktop, Cursor, and any MCP-compatible client. Airtable's API has standard rate limits (5 requests per second per base typical). Multi-base and multi-workspace support requires registering the MCP with different `--env AIRTABLE_API_KEY` values per workspace. ## Pros - Power user database features (formulas, automations, relations) that Notion doesn't match - Personal Access Token auth simpler than OAuth - Multiple community MCPs available; pick the most maintained - Strong Airtable Sync feature for connecting external data sources - Free tier (1,200 records) sufficient for piloting ## Cons - Multiple competing community MCPs. No single official server yet. - Airtable's free tier record limits hit fast at GTM scale - Schema rigidity (compared to Notion) means more upfront design work - Less mature MCP ecosystem than Notion or Slack - Pricing escalates fast above 50,000 records per base ## Who For - Teams already on Airtable for GTM ops or campaign tracking - Operators who want database power user features (formulas, granular permissions) - Marketing functions running content calendars and ad audience sync from Airtable ## Related ### Mcp **Rule:** Yalc default. Switch to Airtable only when the team is already there. **Url:** /mcps/notion/ ## Alternatives - **Notion MCP** - Rule: The Yalc default for GTM database. More flexible, broader use cases, official MCP. - Url: /mcps/notion/ - **Direct Airtable REST API** - Rule: Skip the MCP for headless cron jobs. Direct API is more efficient outside Claude conversations. - Url: # - **Linear MCP** - Rule: Switch when the workflow is engineering project tracking, not GTM database. - Url: /mcps/linear/ ## Faq - Q: Airtable or Notion for GTM database? - A: Notion for greenfield Yalc setups. Airtable when the team is already there or when database power features matter (formulas, automations, granular permissions). Notion's MCP is official and more mature; Airtable's is community. - Q: Which Airtable MCP package should I install? - A: As of April 2026, `airtable-mcp-server` (by domdomegg) is the most actively maintained community MCP. Check GitHub last-commit dates before installing; abandoned community packages are common in this ecosystem. - Q: What scopes does the Personal Access Token need? - A: data.records:read for queries, data.records:write for creates and updates, schema.bases:read for schema introspection, schema.bases:write if Yalc needs to create or modify tables. Start narrow, scope up only if needed. - Q: Does the MCP support Airtable formulas? - A: Yes for read. The MCP returns formula column values as part of the record data. Writing to formula columns is not supported (Airtable calculates them; you can't override). - Q: How do I avoid hitting Airtable rate limits? - A: Airtable allows 5 requests per second per base. The MCP includes basic rate limit handling. For high volume operations, batch writes (Airtable's API supports up to 10 records per write call). - Q: Can I use the MCP across multiple Airtable workspaces? - A: Yes. Register the MCP server multiple times with different AIRTABLE_API_KEY values and different server names. Each Yalc workflow can route to the right workspace by name. **Reviewer:** Othmane Khadri