---
title: 'Airtable Skills: The Missing Half of Your AI Agent Setup'
description: 'Official Airtable skills teach Claude, Codex and Cursor how bases, filters and the CLI really work. Full guide to all eight bundled skills, install commands for every agent, and how to write your own.'
canonical_url: 'https://www.business-automated.com/tutorials/airtable-skills-for-ai-agents'
md_url: 'https://www.business-automated.com/tutorials/airtable-skills-for-ai-agents.md'
last_updated: 2026-08-04
---

Most teams connect the [Airtable MCP server](/tutorials/airtable-mcp-interfaces-automations-guide), watch their agent do something impressive, then watch it do something quietly wrong — filter on a select field by the label instead of the choice ID and return zero records, or invent a "Deals" table structure that doesn't match how anyone in the company actually works.

The tools were never the problem. **The agent had capability but no expertise.** That is exactly the gap Airtable skills fill.

This guide covers all eight bundled skills, how to install them in every major agent, how they interact with MCP and the CLI, and how to write your own for the parts of your business no public skill could possibly know.

## The Short Version

- Skills are packaged instruction files that teach an agent how Airtable works, loaded only when relevant.
- Airtable publishes eight official skills at [github.com/Airtable/skills](https://github.com/Airtable/skills), MIT licensed.
- **Core:** `airtable-overview`, `airtable-filters`, `airtable-cli`.
- **Solutions:** `product-ops`, `sales-ops`, `marketing-ops`.
- **Behavioural:** `agent-activity-log`, `show-airtable-link` — bundled in the plugin but not listed on Airtable's developers page.
- Claude Code: `/plugin marketplace add airtable/skills` then `/plugin install airtable@airtable-skills`.
- Any other agent: `npx skills add airtable/skills` (agentskills.io format).
- The plugin also auto-wires the official MCP server via a bundled `.mcp.json` — tools and knowledge in one install.
- Install `airtable-overview` and `airtable-filters` always. Install one solution skill, not three.

## Skills vs MCP: Hands vs Judgement

The clearest way to think about this:

| | MCP server | Skills |
| --- | --- | --- |
| Provides | Tools and capability | Knowledge and procedure |
| Answers | "What can I do?" | "What should I do, and how?" |
| Lives | On Airtable's servers | In your agent's context |
| Loaded | Always, as a tool list | On demand, when relevant |
| Fails as | Correct calls, wrong strategy | Good advice, no ability to act |

An agent with MCP but no skills is a very fast intern with full database access and no onboarding. It knows `list_records_for_table` exists. It does not know that filtering a single-select field requires calling `get_table_schema` first to get the `sel...` choice ID, because the label you see in the UI is not what the filter matches. So it writes a filter against `"In Progress"`, gets an empty result, and confidently reports that you have no in-progress projects.

That specific failure is what `airtable-filters` exists to prevent. Multiply it across a dozen similar sharp edges and you have the difference between an agent you trust and one you double-check.

Skills also use **progressive disclosure**: they sit dormant, and the agent pulls one in when the task matches its description. That means you can install several without permanently burning context window on instructions that are irrelevant to today's question — which is why the format works at all.

## The Three Core Skills

These are foundational. They apply to any Airtable work regardless of what your base is for.

### `airtable-overview`

**What Airtable says it does:** teaches your AI tool how Airtable is structured — bases, tables, field types, views, and relationships.

**Why it matters:** Airtable is not a spreadsheet and it is not Postgres, and agents default to reasoning about it as one or the other. Both defaults produce bad output.

The spreadsheet assumption leads to agents that treat a base as a grid of cells, miss that a linked record is a relationship rather than text, and suggest duplicating data across tables that should be linked. The database assumption leads to agents that expect foreign keys, joins and a schema migration path that doesn't exist, and that propose normalising a base into eleven tables when Airtable's practical ceiling for usability is far lower.

Airtable's actual model — bases containing tables, tables containing fields with ~25 distinct types, views as saved filtered perspectives rather than separate data, linked records creating two-way relationships, lookups and rollups pulling values across those links — is specific enough that an agent genuinely needs to be told.

**Install it if:** you use Airtable. This is the baseline.

**What it fixes in practice:** agents proposing a text field where a linked record belongs, confusing views with tables, suggesting a formula where a rollup is correct, and misunderstanding that deleting a view does not delete records. If you want the human version of the same material, our guides on [linked records](/tutorials/airtable-linked-records-explained), [lookup fields](/tutorials/how-to-use-airtable-lookup-fields), [rollup fields](/tutorials/how-to-use-airtable-rollup-fields) and [bases vs tables vs workspaces](/tutorials/airtable-base-vs-table-vs-workspace) cover the same ground.

### `airtable-filters`

**What Airtable says it does:** improves the accuracy of record queries by teaching your AI tool how Airtable filters work.

**Why it matters:** this is the single highest-ROI skill in the set, because filtering is where agents fail most often and most silently.

An empty result set looks identical whether it means "there are no matching records" or "your filter was malformed". The agent reports the former. You act on it. Nobody notices for a week.

The sharp edges the skill addresses are real and non-obvious:

- **Select fields filter on choice IDs.** A single-select or multi-select condition matches `sel...` IDs, not the label. You must call `get_table_schema` to retrieve them.
- **Operators are field-type-specific.** Single-select and single-collaborator use `=`, `!=`, `isAnyOf`, `isNoneOf`. Multi-select and multi-collaborator use `hasAnyOf`, `hasAllOf`, `=`, `doesNotContain`. Linked records add `contains` and `isNoneOf` — and with `=` they take an *array* of record IDs, unlike every other field type.
- **Date filters take mode objects, not date strings** — `{"mode": "pastNumberOfDays", "numberOfDays": 30, "timeZone": "America/New_York"}` — and the IANA time zone is mandatory.
- **Linked-record fields can be matched two ways:** by record ID array (exact) or by display name using `contains` (fuzzy). Picking the wrong one produces confidently wrong results.
- **Empty checks are structurally different** — `isEmpty` and `isNotEmpty` take only a field ID, with no comparison value.

None of this is guessable. An agent that hasn't been taught it will produce plausible-looking filters that return nothing.

**Install it if:** your agent ever queries records. So, always.

**What it fixes in practice:** silent empty results, hallucinated `filterByFormula` strings borrowed from REST API examples, and time-zone-off-by-one date ranges. Related reading on the human side: [Airtable filters and custom views](/tutorials/airtable-custom-views-guide).

### `airtable-cli`

**What Airtable says it does:** teaches your agent about the Airtable CLI.

**Why it matters:** the official CLI (`npm install -g @airtable/mcp-cli`) exposes every MCP tool as a terminal command, discovering the command list from the server at runtime. That makes it the right tool for scheduled jobs, CI, and any repeatable operation where you want MCP capability without an LLM in the loop.

But an agent that doesn't know the CLI exists will solve "run this Airtable cleanup nightly" by writing a bespoke Node script against the REST API — more code, more maintenance, and no access to the interface or automation tools the REST API lacks. With this skill installed, the agent reaches for `airtable-mcp` and writes you five lines of shell instead of a hundred lines of JavaScript.

It also matters for the flags that make scripting actually work: `--json` for piping into `jq`, `--input -` for reading arguments from stdin, `-q` for suppressing status noise, `--profile` for switching between environments, and `AIRTABLE_TOKEN` for headless auth.

**Install it if:** you write scripts, cron jobs, or CI steps that touch Airtable. Skip it if your agent only ever works conversationally.

**What it fixes in practice:** agents reinventing scripting infrastructure that already exists, and agents that can't help when you ask "how do I automate this on a schedule without paying for tokens every night".

## The Three Solution Skills

These are role-based playbooks. Where core skills teach the platform, solution skills teach a *domain* — what good structure looks like for a particular kind of work.

### `product-ops`

**What Airtable says it does:** teaches your AI tool sprint tracking, roadmap management, and prioritisation workflows.

**Use it when** your base holds features, epics, sprints, bugs, releases or a roadmap. With it installed, "set up sprint tracking" produces a structure with the relationships a product team actually needs — features linked to epics, tasks linked to sprints, status progressions that match how work really moves — rather than a flat table of tickets.

It also changes how the agent answers analytical questions. "How's the sprint going?" becomes a real answer about scope, carry-over and blockers rather than a record count.

Pairs with our [task management with subtasks](/tutorials/airtable-task-management-with-subtasks) and [project management in Airtable](/tutorials/airtable-project-management) guides.

### `sales-ops`

**What Airtable says it does:** teaches your AI tool pipeline management, deal tracking, and revenue reporting workflows.

**Use it when** your base is a CRM or pipeline tracker. The agent gains the vocabulary and structure of revenue work — stages, weighted pipeline, close dates, deal velocity, stage ageing, win rates — so it can both build a sensible pipeline and answer questions about one without you defining terms.

The difference shows up most in reporting. "How's the pipeline?" with this skill installed produces stage-by-stage value, deals ageing past their expected stage duration, and a forecast view. Without it, you get a table dump.

Pairs with [how to build a CRM in Airtable](/tutorials/how-to-build-crm-in-airtable) and our [client reporting dashboards](/tutorials/airtable-client-reporting-dashboards) guide.

### `marketing-ops`

**What Airtable says it does:** teaches your AI tool campaign tracking, asset management, and launch coordination workflows.

**Use it when** your base runs campaigns, content calendars, creative assets or launches. It gives the agent the structure of marketing work — campaigns as parents with assets and channels beneath, approval states, launch dependencies, asset versioning — which is exactly the kind of many-to-many-heavy modelling that agents get wrong without guidance.

Pairs with our [marketing teams solutions](/solutions/marketing-teams) page and [Airtable forms guide](/tutorials/how-to-create-airtable-forms) for the intake side of campaign work.

### Pick one, not three

The instinct is to install everything and let the agent sort it out. Resist it — at least for these three.

Solution skills are opinionated by design, and an agent holding three competing playbooks will sometimes pattern-match the wrong one — answering a sales question with campaign-tracking structure because the words overlapped. **Install the two core skills plus the one solution skill that matches the base you're working in.** If you genuinely work across all three domains, use separate agent configurations or projects rather than one agent with everything loaded.

## The Two Behavioural Skills Nobody Mentions

Airtable's [developers page](https://airtable.com/developers/agents) documents six skills. The plugin actually bundles **eight**. The two extra ones aren't domain playbooks — they change how the agent behaves rather than what it knows, and they're the ones most write-ups miss because they aren't in the published table.

### `show-airtable-link`

Returns a clickable markdown link to the most specific Airtable surface the agent just touched — a record, an interface page, a table, or a base — after any operation that creates, updates or reads content.

This sounds cosmetic. It isn't. Without it, an agent tells you it updated fourteen records and you have to go find them yourself, which in practice means you don't check. With it, verification is one click, so you actually verify. Notably, the skill also tells the agent to build URLs only from IDs its own tool calls returned, and only for surfaces it has proven the user can reach — so it shouldn't hand you a link into something you can't open, or invent an ID.

**Install it if:** an agent ever writes to your base. Which is to say, almost always.

### `agent-activity-log`

Scaffolds and maintains an opt-in **Agent activity log** table recording what the agent did, what it decided, and where it got blocked across a long-running or multi-session workflow.

This is the one that matters once an agent stops being something you watch. A multi-session workflow with no record of *why* the agent chose what it chose is impossible to debug and impossible to hand to a colleague. The log turns that into a table you can filter.

Two things worth knowing: it is explicitly **opt-in** — the skill is written to offer the log rather than silently create it — and Airtable frames it as transparency, not surveillance. If you deploy it against work your team does, say so; a log nobody was told about lands very differently from one they helped design.

**Install it if:** an agent runs unattended, across sessions, or does anything a human later has to answer for.

## Installing Airtable Skills

### Claude Code (recommended: the plugin)

Two commands:

```
/plugin marketplace add airtable/skills
/plugin install airtable@airtable-skills
```

The first registers Airtable's marketplace; the second installs the plugin, which bundles the skills **and** auto-wires the official Airtable MCP server through its own `.mcp.json`. That is the meaningful advantage of the plugin route over installing skills individually: one command gets you both halves of the setup, already connected.

For local development against a checkout of the repo:

```
/plugin marketplace add /path/to/this/repo
```

### Codex

```bash
codex plugin marketplace add airtable/skills
```

Then enable it either through the plugins menu in the TUI, or declaratively in `~/.codex/config.toml`:

```toml
[plugins."airtable@airtable-skills"]
enabled = true
```

Note that `~/.codex/config.toml` lives in your home directory, not your repo — it is a per-user file, so there is nothing here to commit. Each team member runs the marketplace command and enables the plugin on their own machine. What you *can* version for a team is a marketplace manifest inside your own repository (`.agents/plugins/marketplace.json`), which is how you distribute skills you write yourself — see **Team distribution** below.

### Cursor

Browse the Cursor marketplace for the Airtable plugin, or run `/add-plugin`. For local testing against a clone:

```bash
ln -s "$(pwd)/plugins/airtable" ~/.cursor/plugins/local/airtable
```

### Any local agent (standalone skills)

The skills follow the open [agentskills.io](https://agentskills.io) format, and the `skills` CLI installs them without a plugin system. It detects which coding agents you have installed and writes the files where each expects them, prompting you to choose if it finds none — so it covers the agents the CLI knows about, which is a long list but not literally anything that reads the format:

```bash
npx skills add airtable/skills
```

Or install exactly one:

```bash
npx skills add airtable/skills --skill airtable-filters
```

This is the route for self-hosted agents and anything built on an agent framework rather than a vendor client. It writes the skill files into your local agent's skills directory, which is why it only works where you control the filesystem the agent reads from.

If the CLI doesn't recognise your agent, nothing is lost — the skills are plain markdown folders under `plugins/airtable/skills/`. Copy the ones you want into whatever directory your agent loads skills from and it will pick them up the same way.

### ChatGPT

ChatGPT is not a local agent, so `npx skills add` does not apply — there is no directory on your machine for it to write to. Install through the UI instead:

1. Download the skill you want from [github.com/Airtable/skills](https://github.com/Airtable/skills) (the skills live under `plugins/airtable/skills/`).
2. Open **Skills**, select **Create**, and choose **Upload**.
3. Repeat per skill — this route is one skill at a time, not a bulk install.

If you don't see the option, it is probably not you: workspace admins control skills per role under **Permissions & roles**. A single **Enable skills** permission covers both using and creating skills, and then uploading, sharing, publishing to the workspace, and installing skills for other members are each governed separately. That means an admin can leave skills fully enabled and still have uploading switched off — so check with whoever owns your workspace settings before assuming something is broken.

### Where the files live

If you want to read the skills before you install them — and you should, at least once — the repo layout is:

```
├── .claude-plugin/marketplace.json
├── .agents/plugins/marketplace.json
├── .cursor-plugin/marketplace.json
└── plugins/airtable/
    ├── .claude-plugin/plugin.json
    ├── .codex-plugin/plugin.json
    ├── .cursor-plugin/plugin.json
    ├── .mcp.json
    └── skills/
```

The skills themselves are plain markdown under `plugins/airtable/skills/`. Reading them takes ten minutes and tells you exactly what your agent has been told — which is a level of transparency worth appreciating, and worth using.

## The Full Stack: Skills + MCP + CLI

These three pieces do genuinely different jobs, and the setups that work best use all of them deliberately.

| Layer | What it is | What it gives you |
| --- | --- | --- |
| **MCP server** | Hosted tool endpoint | Capability — records, schema, interfaces, automations |
| **Skills** | Instruction files | Judgement — which tool, what order, what good looks like |
| **CLI** | `@airtable/mcp-cli` | Determinism — the same operations without an LLM |

A realistic team setup:

1. **Claude Code with the Airtable plugin** for building — schema design, interface pages, draft automations. Skills loaded: `airtable-overview`, `airtable-filters`, plus the relevant solution skill.
2. **The Claude or ChatGPT connector** for everyone else — read-mostly, conversational, connected to a scoped set of bases.
3. **The CLI in cron or CI** for the repeatable jobs — nightly hygiene checks, weekly report generation, data validation.

The skills layer improves all three, because `airtable-cli` is what makes an agent write you a correct cron job in the first place.

A worked sequence showing the layers cooperating — building an interface, which is one of the [MCP-only capabilities](/tutorials/airtable-mcp-interfaces-automations-guide) with no REST API equivalent:

- `airtable-overview` tells the agent that a "client view" means filtering by a linked Client record, not duplicating data into a client-specific table.
- `airtable-filters` tells it to call `get_table_schema` first so the status filter uses choice IDs.
- MCP's `describe_page_type` gives it the exact page configuration schema.
- MCP's `create_interface` and `create_page` build it; `publish_interface` ships it after you review.
- `airtable-cli` lets it hand you a one-liner to verify the result from a terminal.

Take away the skills layer and steps one and two go wrong in ways you won't notice until a client sees the wrong data.

## Writing Your Own Airtable Skill

Once the official skills are in, the next real improvement is a skill about *your* business. No public skill knows your base IDs, your naming conventions, or that "Status = Parked" means something specific at your company.

### The format

A skill is a directory containing a `SKILL.md` file: YAML frontmatter plus a markdown body.

```markdown
---
name: acme-airtable-conventions
description: >
  Conventions for Acme's Airtable bases — base IDs, field naming,
  status vocabularies, and the rules for our Delivery and CRM bases.
  Use whenever working with any Acme Airtable base.
---

# Acme Airtable conventions

## Bases

| Base | ID | Purpose |
| --- | --- | --- |
| Client Delivery | appXXXXXXXXXXXXXX | Projects, tasks, time |
| CRM | appYYYYYYYYYYYYYY | Accounts, contacts, deals |

## Rules

- Never write to the CRM base without explicit confirmation.
- Project status vocabulary is: Scoping, Active, Blocked, Review, Delivered.
  "Parked" is not a status — use Blocked with a Blocker Reason.
- Every Project must link to exactly one Account in the CRM base.
- Dates are stored in Europe/London. Always pass that time zone in filters.

## Common requests

**"Weekly delivery report"** → query Projects where Status is Active,
group by Owner, include Blocked count and any task overdue by 3+ days.
```

### What separates a good skill from a useless one

**The description is the most important line in the file.** It is what the agent matches against to decide whether to load the skill at all. A description like "Airtable stuff" never fires. A description that names the specific situations — "use whenever working with any Acme Airtable base", "use when building sales pipeline reports" — fires reliably. Write it as a trigger condition, not a summary.

**Include the IDs.** Base IDs, table IDs and field IDs for anything the agent touches regularly. This alone removes a discovery round-trip from every single task and eliminates the most common category of agent error — operating on the wrong base because two of yours have similar names.

**Encode the rules, not just the facts.** "Never write to the CRM base without confirmation" is worth more than any amount of schema description. Skills are where your guardrails live.

**Add worked examples.** One concrete "when someone asks X, do Y" example does more than three paragraphs of explanation, and agents follow examples far more reliably than prose.

**Keep it short and keep it current.** A skill that describes a base structure you changed in March is worse than no skill — the agent will trust it. Put the file in version control alongside whatever else your team versions, and update it when the base changes.

### Team distribution

Because skills are plain files in a repo, distribution is a solved problem: commit them, and every agent on the team picks up the same context. For Claude Code that means a project-level plugin or skill directory checked into the repo; for Codex, the `config.toml` entry; for anything agentskills-compatible, `npx skills add` pointed at your own repo.

That property — **your institutional Airtable knowledge as a versioned, reviewable file** — is the part with the longest-term value. New team members and new agents onboard from the same source, and when a convention changes you change it in one place.

## Troubleshooting

**The skill doesn't seem to load.** Installation and activation are two different things, and they fail for different reasons. Confirm the skill is installed first — list your installed skills or plugins. If it is installed but never fires, that is description matching: the description is too vague or doesn't overlap with how you phrase requests. Rewrite it to name the situation explicitly, or just tell the agent to use the skill by name once.

**The agent still filters wrong after installing `airtable-filters`.** Work through it in order. First, confirm you aren't looking at a genuinely empty result. Second, confirm the skill is installed at all. Third, ask the agent to show you the filter payload it sent: a select condition carrying a label instead of a `sel...` choice ID tells you the guidance wasn't applied on this request — the skill either didn't load for it or wasn't followed. That is an activation problem, not proof it is missing, so don't reinstall on this evidence alone. Naming the skill explicitly in your next prompt is the fastest way to tell the two apart.

**Conflicting advice between two solution skills.** Uninstall the ones you aren't using. This is the expected consequence of loading three opinionated playbooks at once.

**Plugin installed but no Airtable tools available.** The plugin wires the MCP server, but you still have to authorise it — open the plugin or `/mcp` menu and complete the OAuth flow. Skills without MCP means the agent knows how Airtable works but can't touch it.

**MCP works but the agent has no expertise.** The inverse problem: you connected the server directly rather than through the plugin, so you got tools without skills. Install the skills separately with `npx skills add airtable/skills`.

**Enterprise blocks the integration.** Skills are just files and are unaffected, but the MCP connection may need allowlisting. Admin path: **Admin Panel → Settings → Integrations & development → Third party integration allowlist**.

## Who Should Do What

**If you're one person with one base:** install the plugin in Claude Code or connect the Claude connector, add `airtable-overview` and `airtable-filters`. That is the whole setup, and it takes five minutes.

**If you're a team running your business on Airtable:** install the core skills plus one solution skill per working context, write a conventions skill with your base IDs and rules, commit it, and add the CLI for anything scheduled. Scope MCP access to specific bases rather than everything.

**If you're an agency or consultant:** the conventions-skill pattern is the leverage. One skill per client base, versioned in that client's repo, means any agent — or any consultant — picks up the full context of a system they haven't touched in three months. We build exactly this into [client Airtable systems](/airtable-consultant) as standard now.

**If you're evaluating whether this is worth it:** install `airtable-filters` alone, ask your agent the same query-heavy question you asked before, and compare. That one skill demonstrates the difference faster than any argument.

## Related Reading

- [Airtable MCP: build interfaces and automations with AI](/tutorials/airtable-mcp-interfaces-automations-guide) — the tool layer these skills teach
- [Airtable MCP server explained](/tutorials/airtable-mcp-server-explained) — setup options and security basics
- [Claude + MCP builds Airtable bases](/tutorials/claude-mcp-builds-airtable-bases) — what agent-built schema actually looks like
- [Types of Airtable AI agents](/tutorials/types-of-airtable-ai-agents) — where skills-and-MCP agents sit versus Airtable's built-in AI
- [What is Airtable Omni](/tutorials/what-is-airtable-omni) — Airtable's in-product agent, for comparison

## The Bottom Line

MCP gets most of the attention because it's the part that visibly *does* things. But capability without expertise is how you get an agent that confidently returns zero records and reports it as good news.

Airtable's official skills are free, MIT licensed, readable in ten minutes, and installable in one command. `airtable-overview` and `airtable-filters` fix the two failure modes that account for most bad agent output. One solution skill matched to your actual work adds domain judgement on top. And a short conventions skill of your own — base IDs, naming rules, guardrails — turns a generic Airtable agent into one that knows your business.

That last one is the piece nobody ships for you, and it's the one worth an afternoon.


## Sitemap

See the full [sitemap](/sitemap.md) for all pages.