🤖 MCP Server for Seatable - Talk to your data!

Are there any plans in adding an MCP Server for SeaTable?
So far if I’m using any AI Agents I create a tool and give it to the agent, would be very interesting to use MCP Server instead directly from Claude Desktop for example.
No idea if other people also need this feature.

2 Likes

We’ll release an AI assistant soon. We’ll work on an MCP server thereafter.

4 Likes

I just published a Seatable MCP server GitHub - brianmoney/mcp-seatable

I’ve tested against https://cloud.seatable.io/ and my hosted instance v5.2

Please give a try and LMK if you encounter any issues.

1 Like

Update: Official SeaTable MCP Server

We’re happy to announce that we’re working on an official SeaTable MCP Server. It started as a fork of @brianmoney’s excellent community contribution — we agreed to build on his work, improve it, and release it as the official SeaTable MCP server. Thanks Brian!

What’s available:

Design philosophy:

The MCP server focuses on talking to your data, that means reading, writing, searching, linking, and querying rows. It deliberately does not support structural changes like creating/renaming tables, adding/modifying columns, or changing views. These operations can break automations, integrations, and workflows that depend on your base structure, so they should always be done intentionally through the SeaTable UI.

We’re looking for testers!

The server is in beta and we’d love feedback from the community. If you’d like to help test, just grab an API token for one of your bases and connect to https://mcp.seatable.com/mcp with Bearer authentication. Details are in the GitHub README.

Let us know how it goes — any feedback, issues, or feature requests are welcome here on the forum.

1 Like

I know this video is in German, but it shows how powerful this new feature is.

I will create an English version in the next few days.

3 Likes

When using @seatable/mcp-seatable (v1.3.3) in stdio mode with Claude Desktop on Windows, a validation error popup appears on every MCP request. The MCP tools work correctly and return data, but the error popup is distracting and confusing.

Error message

MCP seatable: [ { "code": "invalid_union", "errors": [ [ { "code": "invalid_value", 
"values": [ "2.0" ], "path": [ "jsonrpc" ], "message": "Invalid input" }, { "code": 
"invalid_union", "errors": [ [ { "expected": "string", "code": "invalid_type", "path": [], 
"message": "Invalid input" } ], [ { "expected": "number", "code": "invalid_type", "path": [], 
"message": "Invalid input" } ] ], "path": [ "id" ], "message": "Invalid input" }, { "expected": 
"string", "code": "invalid_type", "path": [ "method" ], "message": "Invalid input" }, { "code": 
"unrecognized_keys", "keys": [ "level", "time", "service", "version", "mode", "tools", "msg" ], 
"path": [], "message": "Invalid input" } ] ...

Root cause

The MCP server writes structured log messages (containing fields like level, time, service, version, mode, tools, duration_ms, msg) to stdout.

In stdio transport mode, stdout is reserved exclusively for JSON-RPC protocol messages. When the client (Claude Desktop) receives these log lines, it attempts to parse them as JSON-RPC messages and fails Zod validation — resulting in the invalid_union / unrecognized_keys error.

This is documented in MCP best practices:

“Avoid logging via STDIO when running MCP servers. Writing logs to STDIO can disrupt the MCP protocol stream.”

Expected behavior

Log/debug output should be written to stderr (not stdout) when running in stdio mode, so it doesn’t interfere with the JSON-RPC communication channel.

Environment

  • Package: @seatable/mcp-seatable v1.3.3
  • Client: Claude Desktop (Windows)
  • Node.js: v24.14.0
  • OS: Windows 11
  • Transport: stdio

Configuration

{
  "mcpServers": {
    "seatable": {
      "command": "npx",
      "args": ["-y", "@seatable/mcp-seatable"],
      "env": {
        "SEATABLE_SERVER_URL": "https://example.com",
        "SEATABLE_API_TOKEN": "***"
      }
    }
  }
}

Suggested fix

Redirect all log output (e.g., pino, console.log, or similar logger) to stderr instead of stdout when the server detects it is running in stdio mode. This is the standard approach recommended by the MCP specification.

Thanks for this detailed problem description. I have updated the npm package to v1.3.4. This should redirect all log outputs correctly.