Airtable

Deletes an existing automation from a base. The automation must be off before it can be deleted. The target automation must be off. If it is on, the user must turn it off in the Airtable UI before it can be deleted.

delete_automation

Deletes an interface from a base, including all of its pages. The published version, if any, immediately stops being available to end users. Use list_pages_for_base to find the appropriate interfaceId. To delete a single page within an interface instead, use delete_page. On success of delete_interface, the response includes an actionId that can be passed to revert_action to undo the deletion, restoring the interface with its pages.

delete_interface

Deletes a page from an interface, given its pageId. Standalone forms, and pages that have no published version yet, are removed immediately. A page that has its own published version is instead staged for removal in the working draft, staying visible to end users until the interface is published. An immediate removal cannot be undone with these tools; a staged removal becomes permanent once the interface is published. Use list_pages_for_base to find the pageId if needed. After deleting, only offer to run publish_interface when the removal was staged — i.e. the page had its own published version. If it was removed immediately (a standalone form, or a page with no published version), the deletion already took effect for end users, so do not suggest publishing.

delete_page

Deletes records from an Airtable table. To get record IDs, use the list_records_for_table or search_records tools first. You can delete up to 50 records per request. To delete more than 50 records, make multiple requests. Example: delete selected records returned by a preceding list or search call, using the request shape advertised for this endpoint.

delete_records_for_table

Displays an interactive widget showing record data queried from an Airtable table. Do not assume baseId and tableId. Obtain these from search_bases → list_tables_for_base. Do not attempt to pass filterByFormula. Look carefully at the filters parameter. Pre-requisite: If filtering on singleSelect/multipleSelects fields, you must call get_table_schema first to get the choice IDs. Aim to provide 6 to 10 relevant fields via the 'fieldIds' parameter. The possible view types are kanban and list. Set viewType to kanban when there is a singleSelect field that is requested. Aim to provide at least 1 sort when there is a reasonable column to sort by. Note: singleSelect and multipleSelects field values are returned as objects (e.g., {"id": "sel...", "name": "Option", "color": "blue"}) or arrays of such objects. When writing these values back via create_records_for_table or update_records_for_table, use the plain string name (e.g., "Option") instead of the object.

display_records_for_table

Fetches dynamic input options for an automation action or trigger's input field (e.g. Slack channels, Jira projects, calendars). Requires an `externalAccountId` from list_external_accounts. Use get_create_automation_instructions to discover which `inputKey` values each action or trigger type expects.

fetch_automation_input_data

Lists records queried from an Airtable table. Do not assume baseId and tableId. Obtain these from search_bases → list_tables_for_base. Do not attempt to pass filterByFormula. Look carefully at the filters parameter. Pre-requisite: If filtering on singleSelect/multipleSelects fields, and the choice name is not provided, you must call get_table_schema first to get the choice IDs. Aim to provide at least 6 relevant fields via the 'fieldIds' parameter. Note: singleSelect and multipleSelects field values are returned as objects (e.g., {"id": "sel...", "name": "Option", "color": "blue"}) or arrays of such objects. When writing these values back via create_records_for_table or update_records_for_table, use the plain string name (e.g., "Option") instead of the object. If the base is not found or returns a permission error, the user may have interface-only access. Try list_records_for_page instead.

list_records_for_table

Lists records from an interface page. Pages may display data from one table (simple pages) or multiple related tables (hierarchy pages, e.g. projects → tasks). The response contains recordsByTableId, a map from table ID to the records from that table. For simple pages this has one entry; for hierarchy pages it has one entry per configured level. Use the table IDs from list_pages_for_base to identify which table is which. Use this for bases with permissionLevel "interfaceOnly" or "none" (interface-only access), or when the user asks about interface/page data. Do not assume baseId. Obtain it from search_bases or list_bases. Use list_pages_for_base to find the pageId or interfaceId if needed. If filtering or selecting specific fields, use list_pages_for_base if needed to find the field IDs and select choice IDs for the fieldIds and filters params.

list_records_for_page

Gets a single record's details from an interface page element. Takes a navigation path with a root record and edges representing linked record relationships. With no edges, returns the root record. With edges, returns the last edge's linkedRecordId. For each edge, fieldId is the linked record field to follow, and linkedRecordId is the record it points to. Example: record A on page P has linked record field F pointing to record B. - Fetch A: path = {root: {pageId: P, recordId: A}, edges: []} - Fetch B: path = {root: {pageId: P, recordId: A}, edges: [{fieldId: F, linkedRecordId: B}]} Each subsequent call appends to the same path without changing root. For dashboard pages, include elementId in the root to identify the dashboard element. Obtain element IDs from the dashboardElements array in the list_pages_for_base response. The response includes navigationTargets listing which fieldIds can be expanded further. To navigate deeper, append a new edge. Requires baseId and path. Use this for bases with permissionLevel "interfaceOnly" or "none" (interface-only access), or when the user asks about interface/page data. Do not assume baseId. Obtain it from search_bases or list_bases. Use list_pages_for_base to find the pageId or interfaceId if needed.

get_record_for_page

Gets the full configuration of a single automation in an Airtable base, including trigger configuration, action nodes with their input expressions, and deployment status. The returned configuration is the draft (the working copy the user edits). Set includeDeployedVersion to true to also see the most recently published configuration when it differs from the draft — useful for debugging deployed behavior. Edits always apply to the draft. Requires an automationId, which can be obtained from list_automations. {"baseId": "appZfrNIUEip5MazD", "automationId": "wflGlRtkBNWfYnPOV"}

get_automation

Returns the full spec for create_automation — expression language, wrappers, function catalog, trigger and action input catalogs, pitfalls, and a complete example. Call once per session before building an automation payload.

get_create_automation_instructions

Returns the JSON schema for a page element of the specified type. The returned schema describes the element config within the pageConfiguration required by create_page.

describe_page_element

Returns the JSON schema for a page type config. Use describe_page_element to discover any element-specific config required for the chosen page type. The returned schema describes the pageConfiguration shape required by create_page.

describe_page_type

Returns the schema of a form page — its structure, not the submitted-record data. Returns the form's source table, submission action (create or update), and a hierarchical breakdown of sections, rows, and field elements. Sections are the visual groups inside the form (each with an optional title), rows are the columns-of-fields layout within a section, and elements describe each individual field — its label, helper text, field type, required/read-only status, any prefilled value, and any conditional visibility filter. Single-select and multi-select field elements also list their valid choices. Use this when the user asks how a form is organized, what fields it collects, or which fields are required. visibilityFilters specifies the conditions under which a field or section is shown, not a resolved shown/hidden state. Required fields are required only when visible. Fields inside hidden sections are not visible. Do not call this on non-form pages. Supports entry-level form pages (in an interface or standalone) and record-creation row forms, forms embedded in other interface page types. Do not assume baseId. Obtain it from search_bases or list_bases. Use list_pages_for_base to find the pageId if needed. Record-creation row forms appear in that tool's embeddedForms array; pass any one of the form's interfaceIds as the interfaceId here. {"baseId": "appZfrNIUEip5MazD", "pageId": "pagXxYyZzAaBbCcDd"}

get_form_schema

Gets the detailed schema information for specified tables and fields in a base. This returns the field ID, type, and config for the specified fields of the specified tables. Example: get schema for two fields in a table: {"baseId": "appZfrNIUEip5MazD", "tables": [{"tableId": "tblGlReoTNWfYnXIG", "fieldIds": ["fld8WsrpLHHevsnW8", "fldgD18XtsueoiguT"]}]}

get_table_schema

Lists all bases that you have access to in your Airtable account. Use this to get the baseId of the base you want to use. Favorited and recently viewed bases are generally more relevant. If the response includes an offset, pass it in a subsequent call to retrieve the next page of results.

list_bases

Lists all workspaces the current user has access to, along with their permission level in each. No dependencies. This is typically the first tool to call when you need a workspaceId.

list_workspaces

Lists past runs of a published automation, newest first, with the failing step and error category for any run that failed. This is the tool for any question about whether an automation is working: why it failed, whether it is still failing, when it started failing, or how often. Cross-reference failure.nodeKey with the node keys from get_automation to see the configuration of the step that broke. Run history does not go back indefinitely. The oldest run returned is not necessarily the first one. Do not assume baseId or automationId. Obtain the base from search_bases or list_bases, and the automation from list_automations. {"baseId": "appZfrNIUEip5MazD", "automationId": "wflGlRtkBNWfYnPOV", "status": "failure"}

list_automation_runs

Lists automations in an Airtable base. Returns metadata about each automation including its ID, name, deployment status, trigger info, and graph nodes. Use this when the user asks about automations configured in a base. Optionally filter by trigger type (e.g., 'agentTriggerReceived'). The returned configuration is the draft (the working copy the user edits). Set includeDeployedVersion to true to also see each automation's most recently published configuration when it differs from the draft — useful for debugging deployed behavior. Edits always apply to the draft. Do not assume baseId. Obtain it from search_bases or list_bases. {"baseId": "appZfrNIUEip5MazD"}

list_automations

Lists comments on a specific Airtable record, ordered from newest to oldest. Do not assume baseId, tableId, or recordId. Obtain these from search_bases → list_tables_for_base → list_records_for_table. Comments may contain user mentions in @[userId] or @[userGroupId] format. The mentioned field maps these IDs to display names and emails. Supports pagination via pageSize and offset parameters.

list_record_comments

Lists the external accounts (integrations) accessible to the current user, including accounts they own and accounts shared with them. Each account includes its type (e.g. Google Sheets, Slack, Salesforce), a human-readable label, and an account configuration ID that can be used to reference the account in other tool calls. Only user-managed integration accounts are returned.

list_external_accounts

Lists all interfaces and their pages for a base. Returns metadata about each interface and the pages within it, including page IDs, names, and page-type-specific fields describing the page's data model or content. Pages have a pageType: "list" pages support listing records directly, "dashboard" pages contain visualization elements (charts, big numbers, etc.) that aggregate data from source tables, "overview" pages contain static authored content (text, links) with no record data, and "form" pages create records in a single table. For record list pages, use sourceTableId and tablesByTableId to understand the data model. For dashboard pages, use dashboardElements to understand what each element visualizes. Each element's config describes the aggregation (e.g., a BigNumber with summaryFunction "sum" means "sum the values of the referenced field"). To compute these values, call list_records_for_page with the element's id as elementId to fetch the underlying records, then aggregate them according to the config. Overview pages are not backed by record data and cannot be used with list_records_for_page; read their content field directly. For form pages, use name, description, and sourceTableName to identify the relevant form. Call get_form_schema for the full form structure. Forms appear in interfaces (pageType "form"), in standaloneForms (interfaceId null), or in embeddedForms — record-creation modals opened from page buttons, not navigable themselves; pass any one of the form's interfaceIds as the interfaceId. Note that the server may choose to omit form pages depending on the configuration. Use this when the user asks about interfaces, pages, dashboards, or forms, or when a base has permissionLevel "interfaceOnly" or "none" (interface-only access). Draft pages are pages with no published layout (never published or since unpublished). They are omitted by default; set shouldIncludeDraftPages to return them in a top-level draftPages array. When shouldIncludeRecordDetailPages is also set, draftPages additionally includes record detail pages not reachable via a published page. Use this when the user asks about draft or unpublished pages. Do not assume baseId. Obtain it from search_bases or list_bases. {"baseId": "appZfrNIUEip5MazD"}

list_pages_for_base

Lists the secrets accessible to the current user, including secrets they own and secrets shared with them via user groups. Use the returned IDs when configuring custom script automation actions that need secret access.

list_secrets

Lists the views in a table, returning each view's ID, name, and type. Use this to discover viewId values needed by other tools, such as an automation trigger that fires on records entering a view. Do not assume baseId. Obtain it from search_bases or list_bases. {"baseId": "appZfrNIUEip5MazD", "tableId": "Orders"}

list_views_for_table

Ping the MCP server to check if it is running

ping

Publishes an interface, promoting each page's working draft to the live version that end users see. This includes any draft edits made outside this conversation, so publishing may make more changes live than just the ones made here. Pages whose publishing state is "disabled" are skipped and remain as drafts. Publishing is idempotent: re-publishing an already-published interface with no new changes is a no-op. Use search_bases or list_bases to find the appropriate baseId. Use list_pages_for_base to find the interfaceId if needed. Use create_interface and create_page to create a new interface to publish.

publish_interface

Gets the summary of a specific base. This includes the schemas of all tables in the base, including field name and type. If the base is not found or returns a permission error, the user may have interface-only access. Try list_pages_for_base instead.

list_tables_for_base

Reverts a previous eligible Airtable mutation by performing the inverse write, using the actionId it returned. Record updates are not revertible. Use the actionId returned by an eligible mutating tool result. A tool result is eligible only if it explicitly returns an actionId. Examples include create_records_for_table or delete_records_for_table. Reverts one actionId per call (a multi-action revert is not atomic). To revert several, call once per actionId in reverse completion order, stopping on the first error. Example: revert an eligible mutation: {"baseId": "appZfrNIUEip5MazD", "actionId": "actZOTa3BDHxlJNzf"}

revert_action

Searches for records that are valid candidates for a linked-record (foreign-key) field, returning each candidate's record ID along with the fields the linked-record field is configured to display (the same fields shown on the in-product card). Use this to find the record ID to put in a linked-record field when calling submit_form or update_records_for_table. Use list_pages_for_base to find the pageId if needed. Use get_form_schema (for forms) to discover the linked field's fieldId. Pass the fieldId of the linked-record field you are filling (not the table it links to — the foreign table is resolved automatically). The pageId must be a page that surfaces the linked field: for submit_form this is the form's pageId; for update_records_for_table pass the interface page that shows the record/field being edited. Pass interfaceId when the page lives inside an interface; omit it for a standalone form. A linked-record field's candidates can be restricted by dynamic filters that reference the record's OTHER field values, so you must supply those values for the filters to apply: when filling a NEW record (e.g. for submit_form), always pass fields with the other values you have so far or plan to submit; when editing an EXISTING record, pass recordId, plus fields for any other values you are changing in the same update (a value in fields takes precedence over the record's stored value; anything not in fields falls back to the stored value). If you pass neither, the filters are evaluated against blank values and the results may include records that are not actually selectable, or miss ones that are.

search_candidate_linked_records

Searches for bases by name. This is useful when you need to find a specific base quickly by a partial name-based match. Returns bases sorted by their relevance score, as well as a recommended base ID and a hint on whether we need to ask the user to explicitly select the base they want to use.

search_bases

Searches for records in a table using a free-text query. Uses an optimized full-text index that supports fuzzy matching (handles typos) and token-based search (matches individual words regardless of order). When available, returns full record cell values and supports filtering and sorting of results. Call list_tables_for_base first to discover available tables and fields if needed. Prefer this over list_records_for_table when performing free-text search on large tables. Use list_records_for_table instead when filtering by exact field values or structured filters. Not all field types are searchable. Date, rating, checkbox, and button fields are not indexed. Formula, rollup, and lookup fields are only searchable if their result type is searchable. If you need to query by unsearchable field types, use list_records_for_table with filters instead.

search_records

Submits a form, creating a new record in the form's source table. Call get_form_schema first on the form's pageId to discover which fields the form collects, their fieldIds, types, required/read-only flags, select-field choices, and any prefilled values and visibility filters — do not assume every column on the source table is on the form. The schema response includes the interfaceId (null for standalone forms) to pass back here. For linked-record fields, use search_candidate_linked_records to find the record IDs to submit. Always include that tool's fields param with the other values you plan to submit here, so its results respect the linked field's dynamic record-selection filters. Use list_pages_for_base to find the pageId if needed. Pass the baseId and pageId of the form, the interfaceId if the form lives inside an interface (otherwise omit it), and a fields object mapping field IDs to cell values (same shape as the create_records_for_table tool). For singleSelect and multipleSelects fields, the value must be a choice name from the field's options.choices in the get_form_schema response, exactly as written there — do not invent or reword option names. Supports entry-level form pages and record-creation row forms (forms embedded in other interface page types). Respect the visibility filters from get_form_schema: do not submit a value for any field hidden by its own visibilityFilters or its section's visibilityFilters. A field is visible only when the submitted values satisfy its filter and the filters of any fields it depends on. Do not set a field that wasn't requested just to make another visible. If a hidden field is requested to be filled but the values don't reveal it, confirm how to proceed before submitting. {"baseId": "appXxx...", "pageId": "pagXxx...", "interfaceId": "pbdXxx...", "fields": {"fldXxx...": "Hello world"}}

submit_form

Re-runs the trigger test for a genericWebhookReceived automation and waits briefly for a newly captured payload schema. This is an automation trigger operation, not an Airtable Webhooks API operation. Call get_automation first. The external system must POST a representative object payload to the returned webhookUrl before this tool can capture its schema. For a deployed automation, posting the sample also runs the live automation and may cause side effects. This tool does not send the sample or deploy or undeploy the automation. {"baseId": "appZfrNIUEip5MazD", "automationId": "wflGlRtkBNWfYnPOV"}

test_automation_webhook_trigger

Replaces the entire draft configuration (trigger, graph, name, description) of an existing automation. If the automation is on, live behavior is unchanged until unpublished changes are applied with Update in the Airtable UI. Use list_automations to find the automationId, then call get_automation to retrieve the current trigger, nodes, and description before updating — list_automations returns node summaries without their inputs. Call get_create_automation_instructions once per session for the full catalog of trigger types, action types, and expression shapes. This is a full replacement — all fields (trigger, nodes, name, description) must be provided, even if only one changed. The previous configuration is discarded entirely. On success, the response includes an actionId that can be passed to revert_action to undo the update and restore the previous configuration.

update_automation

Updates an existing table's name and/or description in an Airtable base. To get baseId and tableId, use the search_bases and list_tables_for_base tools first. At least one of name or description must be provided. Example: update a table's name and description: {"baseId": "appZfrNIUEip5MazD", "tableId": "tblGlReoTNWfYnXIG", "name": "Updated Name", "description": "New description"}

update_table

Updates records in an Airtable table. The fields you specify will be updated, and all other fields will be left unchanged. To get baseId and tableId, consider using the search_bases and list_tables_for_base tools first. When writing to a linked-record (multipleRecordLinks) field through an interface page, get the record IDs from search_candidate_linked_records, passing a pageId that exposes the field for editing — it also applies the field's record-selection filters. It only works within interfaces; for base-level writes, use record IDs from the linked table. For singleSelect/multipleSelects fields, provide the option name as a plain string (e.g., "In progress") or array of strings, not the object format returned by list_records_for_table. By default the response includes only the fields you wrote. To also include fields you did not write (e.g. the primary field or formula results), pass their IDs in fieldIds. You can update up to 50 records per request. To update more than 50 records, make multiple requests. Example: update a record's fields: {"baseId": "appZfrNIUEip5MazD", "tableId": "tblGlReoTNWfYnXIG", "records": [{"id": "recZOTa3BDHxlJNzf", "fields": {"fldGlRtkBNWfYnPOV": "Updated name", "fld8WsrpLHHevsnW8": "Done"}}]}

update_records_for_table

Updates the name, description, and/or options of a field in an existing Airtable table. At least one of name, description, or options must be specified. To get baseId and tableId, use the search_bases and list_tables_for_base tools first. To get the fieldId, use the list_tables_for_base tool. Example: update a field's name and description: {"baseId": "appZfrNIUEip5MazD", "tableId": "tblGlReoTNWfYnXIG", "fieldId": "fldGlRtkBNWfYnPOV", "name": "Updated Name", "description": "Updated description"} Example: update a formula field's expression: {"baseId": "appZfrNIUEip5MazD", "tableId": "tblGlReoTNWfYnXIG", "fieldId": "fldGlRtkBNWfYnPOV", "options": {"formula": "{Quantity} * {Price}"}}

update_field