TestingOps.ai

MCP tools for agents · MCP tool for agents

Airtable and TestingOps: test data tables for agents

Connect Airtable's MCP server and TestingOps agents can read the accounts, products or expected values your team keeps in Airtable while they prepare and check test runs.

  • MCP tool for agents
  • Available
Connection
MCP tool for agents
Writes back
Only after a person approves
Last checked
7 Nov 2026

In short

Airtable and TestingOps in short

The Airtable connection is an MCP tool for TestingOps agents, set up with an Airtable personal access token limited to the bases agents should use.

Agents can read records and schema in those bases, for example the test accounts and expected values a case needs, and can update records when the token has write scopes and the call is approved.

The token can never do more than your own role in a base; remove the :write scopes if agents should only read.

What it does

What it does for your testing

  1. 1

    Test data from the table your team maintains

    Input
    A table of test accounts, products or expected values
    TestingOps
    Agents can read the records a case needs before a run
    Output
    Cases that use the data your team keeps current
  2. 2

    Expected values in one place

    Input
    A table of expected prices, limits or messages
    TestingOps
    Agents can look up the expected value for the case's scenario
    Output
    Checks based on your table rather than values typed into each case
  3. 3

    Usage recorded, with approval

    Input
    A record that should be marked as used or reserved
    TestingOps
    Agents can request an update; TestingOps asks for approval first
    Output
    A table that shows which test data a run used, after approval

Step by step

How it works

  1. Create a token for chosen basesIn Airtable, create a personal access token with the MCP scopes and add only the bases or workspaces agents may use. For read-only access, remove the scopes that end in :write.
  2. Connect it in TestingOpsPick Airtable under Extra tools your agents may use in Integrations → API & MCP, paste the token into Airtable access token and select Connect.
  3. Reads open, writes ask firstTools that read records are open to agents; tools that create or update records ask first, and tools that delete need a formal approval as well.
  4. Agents use the tables during a taskAn agent can read a table when it prepares a case or checks a result; the token stays on the TestingOps server.

The token's name appears in Airtable's record revision history, so a name such as TestingOps agents tells your team where a change came from.

Connect

Setup

  1. Open Airtable's token page with the MCP scopes already selected and select Create token.
  2. Name the token; for read-only access remove the scopes that end in :write.
  3. Under Access, select Add a base and pick the bases or workspaces agents may use, then create the token and copy it (shown once).
  4. In TestingOps, as customer admin, open Integrations → API & MCP, pick Airtable under Extra tools your agents may use (outgoing, over MCP), paste the token into Airtable access token and select Connect.

Documentation: Airtable MCP for other clients

Where you connect it in TestingOps: Integrations → API & MCP → Extra tools your agents may use → Airtable

Use cases

Use cases

Pick a free test account

Trigger
Several cases need a fresh test account each
Uses
A table of test accounts with a status field
Agent activity
Can read which accounts are free and, with approval, mark the one it uses
Result
Fewer collisions between runs that share accounts
Condition
Marking needs a token with write scopes and an approved call

Keep expected values out of the cases

Trigger
Prices change every quarter
Uses
A price table in Airtable
Agent activity
Can look up the current expected price when it checks a result
Result
Cases that stay valid when the table is updated

Review test data before a release run

Trigger
A release run is planned
Uses
The test-data tables for the release
Agent activity
Can check that each case's data row exists and is complete
Result
A list of missing test data before the run starts

Capabilities

Capabilities and limits

What is read

Records, comments and schema in the bases and workspaces your token covers

What is produced

Test data and expected values for agents' work; nothing is stored in TestingOps by the tool itself

Where it can write

Records and comments in the token's bases when it has :write scopes. Such tools ask first and wait for approval from someone in your organisation with Manage integrations rights (or the TestingOps team); deleting tools also need the TestingOps team's formal approval.

How it connects

Airtable's hosted MCP server (https://mcp.airtable.com/mcp) with the personal access token in the Authorization header

Account and permissions

  • An Airtable personal access token limited to the bases agents should use; it never exceeds your own role there
  • Customer admin (or Manage integrations) rights in TestingOps; the tool is visible only to agents working on your organisation's projects

Limits

  • Writes need both a token with :write scopes and an approval for each call
  • Tools that Airtable does not mark read-only and whose names do not say they read ask first; an approved call still changes the base, so remove the :write scopes if a base must stay unchanged
  • Agents running on Grok receive no MCP tools

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A bank's test team keeps its test customers in an Airtable base, one row per customer with segment, card type and status. They create a token for that base only and connect Airtable.

Before a card-limit case, the agent can read which premium test customers are free; with the team's approval it marks the chosen row as in use, so a parallel run does not pick the same customer.

Frequently asked questions

Can agents change our bases?

Only with a token that has :write scopes, and only after each write call is approved on the request by someone in your organisation with Manage integrations rights (or the TestingOps team). Without :write scopes, Airtable refuses changes.

Which bases can agents see?

Only those you add under Access when you create the token, and never more than your own role in them allows.

Does TestingOps import our tables?

No. Agents read the tables during a task; the tool stores nothing in TestingOps by itself. TestingOps' own test data sets are a separate feature.

How can we tell which changes came from agents?

Airtable shows the token's name in record revision history, so name the token after its purpose, for example TestingOps agents.

Next step

Request a demo with an Airtable test-data base to see what agents can read from it.