Skip to main content
Glama
enesjakozh
felores

Airtable MCP Server

by felores
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Airtable MCP サーバー

Airtable APIを操作するためのツールを提供するモデルコンテキストプロトコル（MCP）サーバー。このサーバーは、Claude Desktopやその他のMCPクライアントを介して、Airtableのベース、テーブル、フィールド、レコードをプログラムで管理することを可能にします。

このMCPサーバーは、Claudeのエージェント機能を活用し、段階的にテーブルを構築できる特別な実装を採用しています。これにより、複雑なテーブル構築時に他のAirtable向けMCPサーバーで一般的に見られる失敗率を最小限に抑えることができます。また、システムプロンプトとプロジェクトナレッジマークダウンファイルも含まれており、Claude Desktopのプロジェクトを活用する際にLLMに追加のガイダンスを提供します。

要件: Node.js

  1. nodejs.orgから Node.js (バージョン 18 以上) と npm をインストールします。

  2. インストールを確認します:

    node --version
npm --version

⚠️重要: 実行する前に、Airtable APIキーを設定してください

Related MCP server: Airtable MCP Server

Airtable APIキーの取得

  1. airtable.comでAirtableアカウントにログインしてください

  2. Airtableのビルダーハブで個人アクセストークンを作成する

  3. 個人アクセス トークン セクションで、次のスコープを選択します。

    • データ.レコード:読み取り

    • データ.レコード:書き込み

    • schema.bases:読み取り

    • schema.bases:書き込み

  4. 個人アクセストークンへのアクセスを許可するワークスペースまたはベースを選択します

  5. このキーは安全に保管してください。設定に必要になります。

インストール

方法1: npxを使用する（推奨）

  1. Claude 構成ディレクトリに移動します。

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

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

    Claude Desktop アプリ内にも以下のディレクトリがあります: Claude Desktop > 設定 > 開発者 > 設定の編集

  2. claude_desktop_config.jsonを作成または編集します。

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

注: Windows パスの場合は、二重のバックスラッシュ (\) またはスラッシュ (/) を使用します。

方法 2: mcp-installer を使用する:

mcp-installer は、他の MCP サーバーをインストールするための MCP サーバーです。

  1. mcp-installerをインストールする

  2. Claude Desktop にプロンプトを表示して、Airtable MCP サーバーをインストールします。

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

Claude はサーバーをインストールし、構成ファイルを変更し、環境変数 AIRTABLE_API_KEY を Airtable API キーに設定します。

方法3: ローカル開発インストール

コードに貢献したり変更したい場合は、ターミナルでこれを実行してください。

# 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

次に、ローカル インストールを使用するように Claude Desktop 構成ファイルを変更します。

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

インストールの確認

  1. Claudeデスクトップを起動

  2. Airtable MCPサーバーは「接続されたMCPサーバー」セクションにリストされているはずです。

  3. 簡単なコマンドでテストします。

List all bases

特徴

利用可能な操作

基地管理

  • list_bases : アクセス可能なすべてのAirtableベースを一覧表示する

  • list_tables : ベース内のすべてのテーブルを一覧表示する

  • create_table : フィールドを持つ新しいテーブルを作成する

  • update_table : テーブルの名前または説明を更新する

フィールド管理

  • create_field : テーブルに新しいフィールドを追加する

  • update_field : 既存のフィールドを変更する

レコード操作

  • list_records : テーブルからレコードを取得する

  • create_record : 新しいレコードを追加する

  • update_record : 既存のレコードを変更する

  • delete_record : レコードを削除する

  • search_records : 条件に一致するレコードを検索する

  • get_record : IDで1つのレコードを取得する

フィールドタイプ

  • singleLineText : 1行テキストフィールド

  • multilineText : 複数行テキストエリア

  • email : メールアドレスフィールド

  • phoneNumber : 電話番号フィールド

  • number : 精度をオプションで指定できる数値フィールド

  • currency : 通貨記号付きの金額フィールド

  • date : フォーマットオプション付きの日付フィールド

  • singleSelect : オプションからの単一の選択

  • multiSelect : オプションからの複数選択

フィールドカラー

選択したフィールドで使用可能な色:

  • blueBright 、 redBright 、 greenBright

  • yellowBright 、 purpleBright 、 pinkBright

  • grayBright 、 cyanBright 、 orangeBright

  • blueDark1 、 greenDark1

貢献

Airtable MCP サーバーの改善に向けた貢献を歓迎します。貢献方法は以下の通りです。

  1. リポジトリをフォークする

    • https://github.com/felores/airtable-mcpにアクセスしてください

    • 右上の「フォーク」ボタンをクリックします

    • フォークをローカルにクローンします。

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

  2. 機能ブランチを作成する

    git checkout -b feature/your-feature-name

  3. 変更を加える

    • 既存のコードスタイルに従う

    • 該当する場合はテストを追加する

    • 必要に応じてドキュメントを更新する

  4. 変更をコミットする

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

  5. フォークにプッシュする

    git push origin feature/your-feature-name

  6. プルリクエストを作成する

    • GitHubのフォークに移動する

    • 「新しいプルリクエスト」をクリックします

    • 機能ブランチを選択してください

    • 変更内容を詳しく説明してください

開発ガイドライン

  • 新しいコードにはTypeScriptを使用する

  • セマンティックコミットメッセージに従う

  • 新機能のドキュメントを更新

  • 新しい機能の例を追加する

  • 変更を徹底的にテストする

ヘルプの取得

  • バグや機能リクエストについては問題を開いてください

  • 既存の問題に関する議論に参加する

  • プルリクエストで質問する

あなたの貢献は、このツールをより良くするために役立ちます。例えば、

  • 新機能の追加

  • バグの修正

  • ドキュメントの改善

  • 機能強化の提案

Airtable MCP サーバーをより強力でユーザーフレンドリーなものにするためにご協力いただきありがとうございます。

ライセンス

マサチューセッツ工科大学

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