Skip to main content
Glama
enesjakozh
felores

Airtable MCP Server

by felores
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Servidor MCP de Airtable

Un servidor de Protocolo de Contexto de Modelo que proporciona herramientas para interactuar con la API de Airtable. Este servidor permite la gestión programática de bases, tablas, campos y registros de Airtable mediante Claude Desktop u otros clientes MCP.

Este servidor MCP cuenta con una implementación especializada que le permite crear tablas por etapas, aprovechando las capacidades de agente de Claude y minimizando la tasa de fallos que suelen observarse en otros servidores MCP para Airtable al crear tablas complejas. También incluye indicaciones del sistema y archivos Markdown de conocimiento del proyecto para proporcionar orientación adicional al LLM al utilizar proyectos en Claude Desktop.

Requisitos: Node.js

  1. Instale Node.js (versión 18 o superior) y npm desde nodejs.org

  2. Verificar la instalación:

    node --version
npm --version

⚠️ Importante : antes de ejecutar, asegúrese de configurar su clave API de Airtable

Related MCP server: Airtable MCP Server

Obtener una clave API de Airtable

  1. Inicie sesión en su cuenta de Airtable en airtable.com

  2. Crea un token de acceso personal en el Builder Hub de Airtable

  3. En la sección Token de acceso personal, seleccione estos ámbitos:

    • datos.registros:leer

    • datos.registros:escribir

    • esquema.bases:leer

    • esquema.bases:escribir

  4. Seleccione el espacio de trabajo o las bases a las que desea dar acceso al token de acceso personal

  5. Mantenga esta clave segura: la necesitará para la configuración

Instalación

Método 1: Usar npx (recomendado)

  1. Navegue hasta el directorio de configuración de Claude:

    • Windows: C:\Users\NAME\AppData\Roaming\Claude

    • macOS: ~/Library/Application Support/Claude/

    También puede encontrar estos directorios dentro de la aplicación Claude Desktop: Claude Desktop > Configuración > Desarrollador > Editar configuración

  2. Crea o edita claude_desktop_config.json :

{
  "mcpServers": {
    "airtable": {
      "command": "npx",
      "args": ["@felores/airtable-mcp-server"],
      "env": {
        "AIRTABLE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Nota: Para las rutas de Windows, utilice barras invertidas dobles (\) o barras diagonales (/).

Método 2: Usar mcp-installer:

mcp-installer es un servidor MCP para instalar otros servidores MCP.

  1. Instalar mcp-installer

  2. Instale el servidor MCP de Airtable solicitando a Claude Desktop:

Install @felores/airtable-mcp-server set the environment variable AIRTABLE_API_KEY to 'your_api_key'

Claude instalará el servidor, modificará el archivo de configuración y establecerá la variable de entorno AIRTABLE_API_KEY en su clave API de Airtable.

Método 3: Instalación de desarrollo local

Si quieres contribuir o modificar el código ejecuta esto en tu terminal:

# Clone the repository
git clone https://github.com/felores/airtable-mcp.git
cd airtable-mcp

# Install dependencies
npm install

# Build the server
npm run build

# Run locally
node build/index.js

Luego modifique el archivo de configuración de Claude Desktop para utilizar la instalación local:

{
  "mcpServers": {
    "airtable": {
      "command": "node",
      "args": ["path/to/airtable-mcp/build/index.js"],
      "env": {
        "AIRTABLE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Verificación de la instalación

  1. Iniciar Claude Desktop

  2. El servidor MCP de Airtable debería aparecer en la sección "Servidores MCP conectados".

  3. Prueba con un comando simple:

List all bases

Características

Operaciones disponibles

Gestión de bases

  • list_bases : Lista todas las bases de Airtable accesibles

  • list_tables : enumera todas las tablas en una base

  • create_table : Crea una nueva tabla con campos

  • update_table : Actualizar el nombre o la descripción de una tabla

Gestión de campo

  • create_field : Agrega un nuevo campo a una tabla

  • update_field : Modificar un campo existente

Operaciones de registro

  • list_records : Recuperar registros de una tabla

  • create_record : Agregar un nuevo registro

  • update_record : Modificar un registro existente

  • delete_record : Eliminar un registro

  • search_records : Encuentra registros que coincidan con los criterios

  • get_record : Obtener un solo registro por su ID

Tipos de campo

  • singleLineText : Campo de texto de una sola línea

  • multilineText : Área de texto de varias líneas

  • email : campo de dirección de correo electrónico

  • phoneNumber : Campo de número de teléfono

  • number : Campo numérico con precisión opcional

  • currency : Campo de dinero con símbolo de moneda

  • date : campo de fecha con opciones de formato

  • singleSelect : elección única entre opciones

  • multiSelect : Múltiples opciones

Colores del campo

Colores disponibles para campos seleccionados:

  • blueBright , redBright , greenBright

  • yellowBright , purpleBright , pinkBright

  • grayBright , cyanBright , orangeBright

  • blueDark1 , greenDark1

Contribuyendo

Agradecemos sus contribuciones para mejorar el servidor MCP de Airtable. Aquí le mostramos cómo puede contribuir:

  1. Bifurcar el repositorio

    • Visita https://github.com/felores/airtable-mcp

    • Haga clic en el botón "Bifurcación" en la parte superior derecha.

    • Clona tu bifurcación localmente:

      git clone https://github.com/your-username/airtable-mcp.git

  2. Crear una rama de funciones

    git checkout -b feature/your-feature-name

  3. Realice sus cambios

    • Seguir el estilo de código existente

    • Agregue pruebas si corresponde

    • Actualice la documentación según sea necesario

  4. Confirme sus cambios

    git add .
git commit -m "feat: add your feature description"

  5. Empuja hacia tu tenedor

    git push origin feature/your-feature-name

  6. Crear una solicitud de extracción

    • Ve a tu bifurcación en GitHub

    • Haga clic en "Nueva solicitud de extracción".

    • Seleccione su rama de funciones

    • Describe tus cambios en detalle

Directrices de desarrollo

  • Utilice TypeScript para código nuevo

  • Seguir los mensajes de confirmación semánticos

  • Actualizar la documentación para nuevas funciones

  • Añadir ejemplos de nuevas funcionalidades

  • Pruebe sus cambios exhaustivamente

Obtener ayuda

  • Abra un problema para errores o solicitudes de funciones

  • Únase a las discusiones sobre problemas existentes

  • Hacer preguntas en solicitudes de extracción

Tus contribuciones ayudan a mejorar esta herramienta para todos. Ya sea:

  • Añadiendo nuevas funciones

  • Corrección de errores

  • Mejorar la documentación

  • Sugerir mejoras

¡Agradecemos su ayuda para hacer que el servidor Airtable MCP sea más potente y fácil de usar!

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Hecho con ❤️ por la comunidad Airtable MCP

Available Tools

12 tools
create_fieldB

Create a new field in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_idYesID of the table
fieldYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits like whether the field is added to the table schema immediately, if it affects existing records, or any required permissions. Minimal information.

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

Conciseness4/5

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

The description is a single clear sentence, front-loaded with the key action and resource. However, it could be slightly more informative without losing conciseness.

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

Completeness2/5

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

Given the complexity of the nested field object and no output schema, the description is too minimal. It does not explain what happens after creation, return values, or error conditions.

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

Parameters3/5

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

Input schema has 67% coverage with descriptions for parameters. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states the action (Create) and resource (new field in a table), which distinguishes it from sibling tools like create_record or update_field.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as update_field (for modifying an existing field) or creating records. The description lacks context for decision-making.

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

create_recordB

Create a new record in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
fieldsYesRecord fields as key-value pairs

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits, but it does not mention what happens after creation (e.g., returned record ID), error conditions, authentication requirements, or rate limits. The description is too brief to inform the agent about the tool's behavior beyond the basic action.

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

Conciseness4/5

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

The description is a single efficient sentence with no wasted words. However, it could be slightly expanded to include essential context without becoming verbose.

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

Completeness2/5

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

The description lacks critical context: it does not specify what the tool returns (e.g., ID of created record), that base and table must exist, or any constraints on fields. Given the presence of sibling tools and no output schema, the description is incomplete for an agent to use reliably.

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

Parameters3/5

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

The input schema already provides clear descriptions for all three parameters (base_id, table_name, fields), so the description does not add much value for parameters. The schema coverage is 100%, earning a baseline of 3.

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 clearly states the action (Create), the resource (a new record), and the context (in a table). It distinguishes from siblings like 'update_record' and 'delete_record', and also from 'batch_create_records' which implies bulk creation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'batch_create_records' for bulk creation, or prerequisites such as requiring the base and table to exist. The description lacks any usage context.

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

create_tableC

Create a new table in a base

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the new table
descriptionNoDescription of the table
fieldsNoInitial fields for the table

TDQS

C2.9/5.0
Behavior2/5

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

The description is minimal and does not disclose behavioral traits beyond the core action. With no annotations available, the description should explain aspects like whether the operation is reversible, if it requires specific permissions, or what happens if a table with the same name exists. None of these are addressed.

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 a single, concise sentence that efficiently conveys the tool's purpose. There is no unnecessary information, and it is appropriately front-loaded.

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

Completeness2/5

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

Given the absence of an output schema and annotations, the description should cover more contextual aspects such as return values, error conditions, or the effect of optional parameters. The current description is too brief for a tool with four parameters and no output schema, leaving significant gaps in understanding.

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

Parameters3/5

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

The input schema provides full descriptions for all four parameters, so the baseline is 3. The description does not add additional meaning or context beyond what the schema already offers. For example, it does not clarify how the 'fields' parameter affects the table creation or provide examples.

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

Purpose4/5

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

The description clearly states that the tool creates a new table in a base. While it is specific enough to distinguish from tools like 'create_field' or 'create_record', it lacks explicit differentiation that could help an agent immediately decide when to use this tool over similar ones. The verb and resource are clear.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as 'create_field' or 'update_table'. It also does not mention prerequisites or context where this tool is appropriate.

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

delete_recordC

Delete a record from a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
record_idYesID of the record to delete

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, and the description only mentions 'delete', which implies mutation. It fails to disclose irreversibility, confirmation requirements, or any side effects.

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

Conciseness4/5

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

The description is a single, clear sentence with no fluff. However, it could be slightly more informative without sacrificing conciseness.

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

Completeness2/5

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

Given the lack of annotations and the presence of many sibling tools (e.g., batch_delete_records, create_record, update_record), the description is incomplete. It does not explain the prerequisite base/table context or confirm that this is for single records.

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

Parameters3/5

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

All 3 parameters are described in the schema (100% coverage), so the description adds no additional meaning beyond what the schema already provides.

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

Purpose4/5

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

The description states the action (delete) and the resource (record from a table), clearly distinguishing it from create, update, or batch operations. However, it does not differentiate from other delete tools like batch_delete_records.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as batch_delete_records or update_record. The context of usage (single record deletion) is only implied.

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

get_recordB

Get a single record by its ID

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
record_idYesID of the record to retrieve

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so the description must disclose behavior. It only states the tool gets a record, without mentioning it's a safe read operation, permissions, or side effects. Minimal transparency.

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

Conciseness4/5

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

Single sentence with no waste, but very sparse. Could include more structure (e.g., what is returned) without losing conciseness.

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

Completeness2/5

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

No output schema, no annotations, and the description is too bare. It does not explain return values, constraints, or how it fits with sibling tools. Incomplete for the tool's complexity.

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

Parameters3/5

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

Input schema has 100% coverage, so the schema already describes parameters adequately. The description adds no extra meaning beyond what is in 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 clearly states 'Get a single record by its ID', using a specific verb and resource. It distinguishes from siblings like list_records (which returns multiple) and search_records.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like list_records or search_records. The description does not mention context or exclusions.

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

list_basesA

List all accessible Airtable bases

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations provided; description implies read-only behavior but doesn't explicitly state it or mention any constraints like pagination. Adequate for a simple listing.

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?

Single concise sentence with no unnecessary words.

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

Completeness4/5

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

For a tool with zero parameters and no output schema, the description adequately conveys the core functionality. Could mention return format, but not critical.

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?

No parameters, baseline 4. Description adds no parameter info but none needed.

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 'List all accessible Airtable bases' clearly specifies the action (list) and the resource (Airtable bases), distinguishing it from sibling tools like list_tables or list_records.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or when not. However, for a simple list tool with no parameters, the usage is straightforward and implicit.

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

list_recordsC

List records in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
max_recordsNoMaximum number of records to return

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or any side effects. The description assumes a straightforward list operation but leaves important details implicit.

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

Conciseness2/5

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

The description is extremely concise (4 words), but it is under-specified. Important information such as scope (all records vs filtered) and behavioral details are missing, making it insufficiently informative for the agent.

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

Completeness2/5

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

Given the presence of sibling tools and no output schema or annotations, the description lacks completeness. It does not explain return format, pagination, or differentiation from similar tools, leaving agents with insufficient context to use the tool correctly.

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

Parameters3/5

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

The input schema has 100% description coverage, so the baseline is 3. The description does not add any additional meaning beyond what is already in the schema. Parameters are adequately described in the schema, but the description offers no extra context.

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

Purpose4/5

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

The description clearly states the action (list) and resource (records in a table). It is specific enough for basic understanding, but does not differentiate from sibling tools like advanced_list_records, which may offer additional filtering options.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as advanced_list_records or search_records. The description lacks any context about appropriate use cases or exclusions.

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

list_tablesB

List all tables in a base

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or side effects, leaving the agent uninformed.

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?

Single short sentence with no wasted words, efficient and front-loaded.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks details on return format, pagination, or error handling.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter base_id, which is already described in the schema. The description adds no additional semantic meaning.

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 clearly states the verb 'list', resource 'tables', and scope 'in a base', making it distinct from sibling tools like list_records or list_fields.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Implied usage only.

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

search_recordsB

Search for records in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
field_nameYesName of the field to search in
valueYesValue to search for

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations available, the description carries the full burden for behavioral disclosure. It only states 'search' without mentioning pagination, limits, security implications, or any side effects, providing minimal transparency.

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

Conciseness4/5

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

The description is a single concise sentence that is easy to parse. While it is functional, it lacks structure or front-loaded key constraints. It is appropriately sized but could be more informative without becoming verbose.

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

Completeness2/5

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

Given the complexity of the tool (4 required parameters) and the absence of an output schema or annotations, the description is too brief to be contextually complete. It does not explain expected results, error conditions, or usage context.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already fully explains each parameter. The description adds no additional semantic value beyond the schema, meeting the baseline but not exceeding it.

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 clearly states 'Search for records in a table', which is a specific verb-resource combination. It distinguishes from siblings like 'list_records' by implying filtering criteria, making the purpose unambiguous.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'advanced_list_records' or 'get_record'. The description lacks context for appropriate usage, exclusions, or prerequisites.

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

update_fieldC

Update a field in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_idYesID of the table
field_idYesID of the field to update
updatesYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are present, and the description does not disclose behavioral traits like idempotency, error handling, permissions, or response behavior. This is insufficient for a mutation operation.

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

Conciseness3/5

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

The description is a single concise sentence, but it is too brief to cover necessary details. It is structured but lacks substance.

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

Completeness2/5

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

Given the complexity of the tool (4 parameters, nested updates object, no output schema), the description is incomplete. It omits important context about how updates are applied, which fields are optional, and error scenarios.

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

Parameters3/5

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

Schema description coverage is 75%, and the descriptions for base_id, table_id, field_id, and the updates object are adequate but generic. The tool description adds no extra semantic value beyond the schema.

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

Purpose4/5

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

The description clearly states the verb 'Update' and the resource 'field in a table', which distinguishes it from sibling tools like create_field or update_record. However, it lacks specificity about which field properties can be updated.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as update_record or create_field. There are no prerequisites or contexts provided.

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

update_recordB

Update an existing record in a table

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_nameYesName of the table
record_idYesID of the record to update
fieldsYesRecord fields to update as key-value pairs

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden. It only states 'Update an existing record' without disclosing what happens if the record is not found, what fields can be updated, whether partial updates are allowed, or any authentication requirements.

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

Conciseness4/5

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

The description is a single concise sentence with no extraneous words. However, it could potentially include more information without losing conciseness, so it's not the most efficient use of space.

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

Completeness2/5

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

Given the complexity (4 required parameters, nested object) and lack of annotations or output schema, the description is too minimal. It does not explain return values, error handling, or the scope of updates, leaving significant gaps for the agent.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already defines each parameter. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.

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 'Update an existing record in a table' clearly states the verb (update) and resource (record in a table). It distinguishes from siblings like 'create_record' (create) and 'batch_update_records' (batch), making the tool's purpose specific and unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as 'batch_update_records' (for multiple records) or 'create_record' (for new records). No prerequisites or when-not-to-use hints are provided.

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

update_tableC

Update a table's schema

ParametersJSON Schema
NameRequiredDescriptionDefault
base_idYesID of the base
table_idYesID of the table to update
nameNoNew name for the table
descriptionNoNew description for the table

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the action. It does not disclose whether updates are idempotent, require special permissions, or affect existing data. The optional parameters suggest partial updates, but this is not explained.

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

Conciseness4/5

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

The description is a single sentence with no wasted words, but it could be slightly expanded to include usage context without losing conciseness.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand when and how to use it. Sibling tools exist but no differentiation is provided.

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

Parameters3/5

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

Schema coverage is 100%, so the parameter meanings are clear from the schema. The description adds no extra context beyond what is in the schema, such as constraints on name or description values.

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

Purpose4/5

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

The description 'Update a table's schema' clearly states the action and resource, and distinguishes from sibling tools like update_field and update_view. However, 'schema' could be misinterpreted as structural schema changes, while the parameters only allow updating name and description.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like update_field or update_view. No context about prerequisites or typical use cases is given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 12 tool updatesv1.0.0
    • First observedcreate_field
    • First observedcreate_record
    • First observedcreate_table
    • First observeddelete_record
    • First observedget_record
    • First observedlist_bases
    • First observedlist_records
    • First observedlist_tables
    • First observedsearch_records
    • First observedupdate_field
    • First observedupdate_record
    • First observedupdate_table
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.5/5.0

Scored across 12 tools

Disambiguation5/5

Every tool has a clearly distinct purpose targeting specific resources (bases, tables, fields, records) and actions (create, list, get, update, delete, search), with no ambiguity or overlap. For example, list_records and search_records are differentiated by listing all versus searching with criteria.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case, such as create_record, list_tables, and update_field. This predictable naming scheme makes it easy for agents to understand and select the correct tool based on the intended action and resource.

Tool Count5/5

With 12 tools, the server is well-scoped for managing Airtable resources, covering bases, tables, fields, and records. Each tool earns its place by providing essential CRUD and listing operations without being overly sparse or bloated.

Completeness5/5

The tool set offers complete CRUD/lifecycle coverage for the Airtable domain, including create, list, get, update, and delete operations for bases, tables, fields, and records, plus search functionality. There are no obvious gaps that would cause agent failures in typical workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • airtable-mcp-server

    domdomegg
    A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol server that provides read and write access to Airtable databases. This server enables LLMs to inspect database schemas, then read and write records.
    2,607 npm
    456
    TypeScript
    MIT

  • Airtable MCP Server

    AM1010101
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides read and write access to Airtable databases, enabling LLMs to inspect database schemas, then read and write records.
    2,607 npm
    MIT

  • Airtable OAuth MCP Server

    onimsha
    A
    license
    A
    quality
    D
    maintenance
    A production-ready Model Context Protocol server that enables AI assistants and applications to interact with Airtable bases through a standardized interface with secure OAuth 2.0 authentication.
    10
    3
    MIT

  • Effect Airtable MCP Server

    glassBead-tc
    A
    license
    Not graded
    quality
    D
    maintenance
    A production-ready MCP server for Airtable that enables programmatic management of bases, tables, fields, and records through Claude Desktop or other MCP clients using Effect for type-safe and robust API interactions.
    7 npm
    1
    MIT

Appeared in Searches