Airtable Full-Stack MCP

Overview Schema Source Related Servers Discussions Admin

airtable_generate_automation_script

Generate production-ready JavaScript for Airtable automations, including webhook mapping, unique ID creation, deduplication, and payment reconciliation, ready to paste into the Script editor.

Instructions

Generates production-grade, syntactically verified JavaScript code tailored for Airtable's In-Base Scripting API ("Run a script" automation action).

When to Use

When configuring native Airtable Automations that require custom business logic, field transformations, or external API communication.
When mapping incoming webhook payloads (Tally forms, Fillout, Stripe payment events) into structured Airtable records.
When creating sequential prefixed IDs (e.g., 'VR-M-00105') without race conditions.
When performing deduplication checks or cross-table rollups inside Airtable.

When NOT to Use

Do NOT use this tool to execute operations directly on Airtable from your local machine. Use 'airtable_batch_upsert' or 'airtable_manage_records' instead.
Do NOT use this tool for creating Interface Designer pages. Use 'airtable_create_interface_page' instead.

Operational Disclosures

Execution Environment: The generated code is designed to run in Airtable's native sandboxed Scripting environment with access to global 'base', 'input.config()', 'output.set()', and 'remoteFetchAsync()'.
Safe & Idempotent: Generated templates include batching safeguards (Airtable's 50-record batch mutation limit) and error boundaries.
No Side Effects Locally: This tool produces verified code text that you paste into the Airtable Automation Script editor.

Input Schema

TableJSON Schema

Name	Required	Description
`options`	No	Template configuration parameters
`template`	Yes	Script archetype: 'tally_fillout_mapper' (maps intake payloads), 'stripe_paypal_reconciliation' (handles charge balances), 'unique_id_generator' (sequential prefixed IDs), 'deduplication_sync' (finds and flags duplicates), 'custom' (scaffolded custom logic)
`table_name`	Yes	Target Airtable table name (e.g. Merchants, Orders, Payments)
`field_mappings`	No	Mapping of incoming payload keys to Airtable column names, e.g. {"client_name": "Full Name", "email_address": "Contact Email"}

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.1Sep 25, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states that the tool produces code text with no local side effects, describes the execution environment and available globals, and discloses built-in batching safeguards and error boundaries. This is strong transparency for a code-generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with clear headings: purpose, when to use, when not to use, and operational disclosures. It is appropriately detailed for a complex tool without unnecessary filler, and the primary purpose is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description explains that the tool produces pasteable code text and where it should be used. It covers the execution environment, safety behavior, exclusions, and alternatives, giving an agent everything needed to call the tool correctly and understand its results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds selection context by tying use cases to template archetypes (e.g., webhook payload mapping, unique ID generation, deduplication). It reinforces parameter intent beyond the schema, even though some examples like 'VR-M-' are duplicated from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: it 'Generates production-grade, syntactically verified JavaScript code tailored for Airtable's In-Base Scripting API'. It also differentiates itself from siblings by explicitly naming tools like 'airtable_batch_upsert', 'airtable_manage_records', and 'airtable_create_interface_page' as alternatives for other jobs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to Use' section lists concrete scenarios such as mapping webhook payloads, generating sequential prefixed IDs, and deduplication. The 'When NOT to Use' section explicitly names sibling tools that should be used instead, making the routing decision unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server