Get Airtable Schema Tool

Discover accessible Airtable bases, or inspect the tables, fields, and views inside a base

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

Parameter	Type	Required	Description
baseId	string	No	Airtable base ID (starts with app). If omitted, returns the list of bases the PAT can reach. If provided, returns tables + fields for that base.

Common use cases

List accessible bases

(no arguments)

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

baseId: "appXXXXXXXXXXXXXX"

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

Related tools

• Search Airtable — query records in a table discovered via this tool
• Manage Airtable Records — create/update/delete records