Airtable User MCP

Top Features

Why this exists

Airtable's public Web API has never exposed some of the most common tasks builders actually need: creating a formula field, tweaking a view's filter set, installing an extension, or validating a formula before it breaks production. The official Airtable MCP server is a thin wrapper over that same REST API, so it inherits every one of those gaps.

airtable-user-mcp is an add-on to the official Airtable MCP, not a replacement. It uses Airtable's own internal API (the one the web UI uses) to cover exactly the surface area the REST API can't reach. Register both servers in your AI client and your assistant gets the full Airtable automation experience — records over HTTP via the official MCP, plus schema, formulas, views, and extensions via this one.

What airtable-user-mcp adds on top of the official Airtable MCP

This is a coverage map, not a "pick one" decision — the two servers are complementary and designed to run side-by-side.

Sources: Airtable's official MCP docs, Airtable Web API reference, and the UNSUPPORTED_FIELD_TYPE_FOR_CREATE rollup thread.

Use both MCPs together

npx -y airtable-user-mcp login          # one-time browser loginclaude mcp add airtable --scope user -- npx -y airtable-user-mcp   # Claude Code

airtable-user-mcp is additive. Register the official Airtable MCP following Airtable's setup guide, then add this one alongside it in the same mcpServers block:

{  "mcpServers": {    "airtable-user-mcp": {      "command": "npx",      "args": ["-y", "airtable-user-mcp"]    }  }}

Your MCP client will expose every tool from both servers. The two entries are independent — rename the keys (airtable, airtable-official, airtable-user-mcp, etc.) however makes sense for your workflow.

What's In This Repo

This monorepo ships three products from one source tree:

Demo

Features

MCP Server (72 Tools + manage_tools)

Manage Airtable bases with capabilities not available through the official REST API:

See the full tool reference in packages/mcp-server/README.md.

One shared daemon

The extension starts the shared MCP daemon whenever a tool call needs one, so every VS Code window uses one Airtable browser session instead of one per window — that duplication is what produced most "session dead" errors. A daemon you stop from the dashboard stays stopped, and if it cannot start, the extension falls back to a per-window server so your tools keep working.

Because a daemon is usually running, other MCP clients on the same machine (Claude Desktop, Cursor, Cline, Amp) attach to it and therefore run under its auth mode and HTTP client rather than their own — deliberately, since two browsers on one Airtable profile crash. Each such client prints one stderr line saying so. See Sharing one daemon across clients.

LSP Server

airtable-user-lsp is a standalone language server for Airtable formula, script, and automation files — works in any LSP-capable editor, not just VS Code.

# stdio mode — works standalone, no daemon needednpx airtable-user-lsp --stdio

Features: diagnostics, completions, hover documentation, and signature help for .formula, .ats, and .ata files.

When the daemon is running, it auto-spawns airtable-user-lsp --tcp so multiple editors share one language server instance. The TCP port is written to ~/.airtable-user-mcp/daemon.lock as port_lsp.

See packages/lsp-server/README.md for per-editor configuration (Neovim, Zed, OpenCode, Helix).

Supported IDEs

The extension auto-configures MCP for all major AI-enabled editors:

Don't use VS Code? Use the standalone MCP server directly:

npx airtable-user-mcp

Find Us

Requirements

• VS Code ^1.100.0 (or any fork exposing the McpServerDefinitionProvider API)
• Node.js — bundled via the VS Code runtime; no separate install needed
• Google Chrome (or Edge / Chromium) — the Airtable login flow uses Patchright in headless mode. Falls back to msedge on Windows and chromium on Linux. The extension shows an actionable warning if no supported browser is detected.

Development

This is a pnpm monorepo.

pnpm install          # install all packagespnpm build            # build shared → webview → mcp bundle → extensionpnpm package          # build + create airtable-formula-X.Y.Z.vsixpnpm test             # run all unit testspnpm dev              # start webview dev server (browser preview)

How the MCP server is bundled: scripts/bundle-mcp.mjs esbuilds packages/mcp-server/src/ into packages/extension/dist/mcp/. Then scripts/prepare-package-deps.mjs vendors patchright, patchright-core, otpauth, impit and @ngrok/ngrok into dist/node_modules/ before vsce package runs, so an installed extension needs no npm install at runtime.

Platform-specific VSIXes. impit (the Chrome-TLS HTTP client) and @ngrok/ngrok (the ngrok tunnel provider) keep their compiled native binary in separate per-platform npm packages, and only the one matching the build machine is ever installed. A single VSIX therefore cannot carry working native binaries for every platform. Instead we publish one VSIX per platform, each vendoring only its own binaries — VS Code and Open VSX hand each user the build matching their machine. Supported targets:

linux-armhf (32-bit ARM) is not published: impit ships no arm-gnueabihf build, so an armhf VSIX would advertise airtableFormula.mcp.httpClient: "impit" and then fail with "Cannot find native binding". No untargeted fallback is published either, for the same reason.

The matrix is defined once in scripts/vsix-targets.mjs; versions and tarball hashes are pinned to pnpm-lock.yaml. scripts/package-targets.mjs builds every target and scripts/assert-vsix-binaries.mjs verifies each artifact contains exactly its own platform's .node files and no other's — byte-for-byte, against the SHA-256 digests in scripts/native-binary-digests.json, which are recorded from tarballs verified against pnpm-lock.yaml's integrity hashes. Filenames, package.json os/cpu, and a magic number are all labels an artifact carries about itself and cannot distinguish an x64 binary from an ARM64 one, or a glibc build from a musl one; an exact digest can.

Together these are eight target artifact packaging/assertion smokes — eight .vsix files built and their contents verified on one machine. They are not runtime smokes of eight native bindings: any single host can only load the binding compiled for itself, so only the host target's binding receives a genuine runtime load. Verifying the other seven by exact content is the strongest claim a single-host build can make about them.

The standalone npm package airtable-user-mcp is unaffected and stays universal — npm resolves the right optional dependency on your own machine at install time.

Support This Project

This project is built and maintained with the help of AI coding tools. If you find it useful and want to support continued development (new tools, updates, bug fixes), you can contribute by gifting Claude Code credits — the primary tool used to build this project.

Interested? Open an issue or reach out to discuss feature requests and sponsorship.

License

MIT