Skip to main content

​
What it does

The Get Airtable Schema tool is how your agent learns what’s in your Airtable account at runtime. It has two modes:
  • Called without arguments — returns every base (workspace) the integration has access to, with each base’s id, name, and permissionLevel
  • Called with a baseId — returns every table in that base with full field metadata (names, types, select choices, linked-table references) plus views
Agents should call this first — it provides the baseId, tableIdOrName, and field names needed by Search Airtable and Manage Airtable Records.

​
Key features

  • Dynamic discovery — no need to hardcode base IDs or field names in the agent’s system prompt
  • Returns select choices for singleSelect and multipleSelects fields so the agent knows valid values
  • Returns linkedTableId for multipleRecordLinks fields so the agent can chase relationships
  • Includes view IDs + names so you can scope later queries to a specific view

​
Parameters

​
Common use cases

​
List accessible bases

Returns all bases the agent can work with. Use this once per session to find the baseId you need.

​
Inspect a base’s tables and fields

Returns each table’s id, name, primary field, full field list (with types and select choices), and views.

​
Agent workflow pattern

  1. Call airtable_get_schema with no args → pick the right base
  2. Call airtable_get_schema with that baseId → learn table + field names
  3. Call airtable_search / airtable_manage_records using the discovered IDs

​
What you get back

No-baseId mode:
  • bases[] — each with id, name, permissionLevel (none, read, comment, edit, create)
  • count — number of bases
  • message — reminder to call again with a baseId to inspect tables
With-baseId mode:
  • baseId, tableCount
  • tables[] — each with:
    • id, name, description, primaryFieldId, fieldCount
    • fields[] — each with id, name, type, description, optional choices (for select fields), optional linkedTableId (for record links)
    • views[] — each with id, name, type (grid, kanban, etc.)

​
Best practices

  • Call it early. Agents that skip discovery and guess field names will fail on any table with custom naming
  • Cache the baseId. Once you’ve identified the right base, reuse its id across calls — it doesn’t change
  • Prefer field IDs over names when the table might be renamed, but names work too and are easier for humans to read
  • Use permissionLevel to avoid write actions on read-only bases — the token may have list access without write access

​
Troubleshooting

“No bases returned”
  • The PAT needs the schema.bases:read scope
  • The PAT must have access granted to at least one base (scopes aren’t enough — you also select specific bases during PAT creation)
“Base not found”
  • Confirm the baseId starts with app and was copied from the same Airtable account as the PAT
  • Use the no-args mode first to list the bases the PAT can actually see
“Missing fields in the response”
  • schema.bases:read is required for field metadata; if the scope was omitted, you may see base-level info but no field details