# APITable

> Canonical: https://www.yalc.ai/mcps/apitable/

Read and write APITable and AITable datasheets from Claude Code as a lightweight GTM database.

## Categories

- operations

**Website:** https://apitable.com/

**Repo:** https://github.com/apitable/aitable-mcp-server

## Glance

- Maintainer: APITable (official)
- Runtime: Node via npx (local)
- Auth: AITable API token

**Install Command:** claude mcp add aitable --env AITABLE_API_KEY=your_token -- npx -y /ABSOLUTE/PATH/TO/aitable-mcp-server

**Install Notes:** APITable maintains the official `apitable/aitable-mcp-server`. Clone and build it, then point npx at the built folder. Generate a personal access token in your AITable account, pass it as `AITABLE_API_KEY`, and restart Claude Code. By default the server talks to the AITable cloud at `https://aitable.ai/fusion`. If you self host the open source APITable, set `AITABLE_BASE_URL` to your instance. One tool, `update_record`, is still marked TODO in the repo, so treat writes as create and read for now.

**Yalc Fit Score:** 6

**Yalc Verdict:** A clean, cheap datasheet layer when you want a spreadsheet style store Yalc can read and append to, without standing up a full CRM. Best as scratch storage for lists, signals, and campaign state.

## Plain Description

APITable is an open source Airtable alternative, and its team ships an official MCP server (`apitable/aitable-mcp-server`) that gives Claude read and write access to AITable and self hosted APITable datasheets. The server exposes six tools: list every workspace you can access, search nodes by type and keyword, list records with pagination and field filtering, fetch a datasheet field schema, create a record, and upload an attachment from a web URL. A record update tool is on the roadmap but not yet shipped.

For Yalc operators this is the lightweight database node. When a workflow produces a list that does not belong in the CRM yet, a spreadsheet grade store is often the right home: a scratch table of accounts from a signal run, a campaign state tracker, a queue of drafts awaiting review. APITable gives you that grid with an API, and the MCP lets Yalc append rows and read them back inside the same prompt. Because you can self host APITable, teams with data residency rules can keep the table on their own infrastructure and still drive it from Claude Code by pointing `AITABLE_BASE_URL` at the private instance.

The honest boundary: this is a datasheet, not a system of record. Use it for working state and handoffs, and push validated, durable records into your real CRM through the HubSpot or Salesforce MCP when they are ready.

## Yalc Framework

**Workflow Step:** route

### Workflow Narrative

The APITable MCP sits at the **route** node as a working store. Yalc writes intermediate output here (a segment, a draft queue, a signal log), reads it back on the next step, and promotes the durable rows to the CRM later.

Most useful patterns: append accounts from a signal run to a tracking datasheet, read back a queue of drafts for a review pass, log campaign state across runs, and keep a self hosted table for data that cannot leave your infrastructure.

**Workflow Position:** The scratch database node between raw output and the CRM. Yalc appends and reads rows here; it is not where closed deals or customer records live.

### Prompt Patterns

- Yalc, list the datasheets in my APITable space, then append these 30 accounts from the funding signal run to the "Signal queue" table with columns account, trigger, and date.
→ Yalc calls list_spaces and search_nodes, then create_record per row via the MCP.

- Yalc, read the "Draft queue" datasheet, show me every row where status is "needs review", and summarize the drafts.
→ Yalc lists records with a field filter and summarizes via Claude.

- Yalc, pull the field schema for the "Campaign state" datasheet so I know which columns exist before we write to it.
→ Yalc calls get_fields_schema to avoid writing to a column that does not exist.


### Chaining

**Upstream:** Yalc signal or draft run → APITable MCP (create_record)

**Downstream:** APITable row promoted → CRM MCP (HubSpot or Salesforce writeback)


### Anti Patterns

- Don't use APITable as your system of record. Durable customer data belongs in the CRM, not a scratch datasheet.
- Don't expect record updates yet. update_record is TODO, so model changes as new rows or handle updates in the AITable UI.
- Don't hardcode the cloud base URL if you self host. Set AITABLE_BASE_URL to your instance or the server will talk to the wrong place.


**Compatibility:** The server runs locally through Node and npx, so it works in Claude Code, Claude Desktop, and Cursor once built. It targets the AITable cloud by default and any self hosted APITable via AITABLE_BASE_URL. Auth is a personal access token passed as an environment variable.

## Pros

- Official APITable server with read and write coverage of datasheets.
- Self host friendly. Point it at your own APITable instance for data residency.
- Six practical tools including field schema reads, which prevent bad writes.
- Open source project, so the server and the backing database are inspectable.

## Cons

- update_record is not implemented yet. Writes are create and read only for now.
- Runs from a local build path, not a one line published package, so setup has a build step.
- It is a datasheet, not a CRM. Wrong home for durable customer records.
- Token auth means you manage and rotate the key yourself.

## Who For

- Operators who want a cheap spreadsheet grade store Yalc can append to
- Teams with data residency rules who self host APITable
- Anyone tracking campaign or signal state between runs without touching the CRM

## Alternatives

- **Airtable MCP**
  - Rule: Switch when your team already lives in Airtable and does not need self hosting.
  - Url: #
- **Notion MCP**
  - Rule: Switch when you want documents and databases together rather than a pure grid.
  - Url: #
- **HubSpot or Salesforce MCP**
  - Rule: Use instead when the data is a durable customer record, not working state.
  - Url: #

## Faq

- Q: Is there an APITable MCP server?
  - A: Yes. The official server is apitable/aitable-mcp-server on GitHub. It gives Claude read and write access to AITable and self hosted APITable datasheets.
- Q: How do I install it?
  - A: Clone and build the repo, then add it with `claude mcp add aitable --env AITABLE_API_KEY=your_token -- npx -y /ABSOLUTE/PATH/TO/aitable-mcp-server`. Generate the token in your AITable account first.
- Q: Does it work with self hosted APITable or only the AITable cloud?
  - A: Both. It defaults to the AITable cloud at https://aitable.ai/fusion. Set AITABLE_BASE_URL to your self hosted APITable instance to use your own infrastructure.
- Q: What tools does it expose?
  - A: It exposes six tools. list_spaces, search_nodes, list_records, get_fields_schema, create_record, and upload_attachment_via_url. A record update tool is on the roadmap but not shipped yet.
- Q: Can it update existing records?
  - A: Not yet. update_record is marked TODO in the repo. For now, model changes as new rows through create_record or edit in the AITable UI.
- Q: How should I use APITable inside a Yalc workflow?
  - A: As a working store. Append lists, drafts, and signal logs that are not ready for the CRM, read them back on the next step, and promote durable rows to HubSpot or Salesforce when they are validated.

**Reviewer:** Othmane Khadri