SeaTable

# Fix list: SeaTable

From Anchor Terminal's listing at https://www.anchorterminal.com/tools/seatable, the October 2026 research run, assessed 8 October 2026. Grade B, 66.3 out of 100.

This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.

For a coding agent working on SeaTable: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.

## 1. Payments & pricing, 30 out of 100, up to 8.8 more on the total

Why it scored 30: Graded on the hosted cloud. No x402, MPP or L402 found (0). Plan prices are public in euros, Plus at €7 and Enterprise at €14 a user a month billed yearly, each with a monthly API call quota and no per-call price (10). A permanent Free plan with 3,000 API calls a month, and the registration page says no credit card is required. We didn't complete a signup (20). Access starts with registration in a browser, and the security page lists a captcha among access controls. API tokens can then be created by API with an Account-Token (0).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):

The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).

- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.
- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login.
- 20, a free tier or trial that doesn't need a card.
- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).

Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.

Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.

## 2. Security & auth, 59 out of 100, up to 7.2 more on the total

Why it scored 59: API tokens are limited to one base, set to read-only or read-write, named, deletable and listed with their last access time. They never expire unless the one-hour temporary kind is used, and can't be limited to a table. The Account-Token comes from the username and password, never expires and carries the whole account. The MCP server's OAuth flow has PKCE and dynamic client registration but no scopes, and wraps the same API token. No secret in a query string was found (25 of 30). Read-only tokens per base, and the MCP server leaves out schema changes and marks destructive tools, but `query_sql` accepts UPDATE and DELETE and there is no confirmation step (13 of 20). Rows and comments can hold text written by others, and no prompt-injection guidance was found. Write tools reject unknown columns (3 of 15). Tokens show last access time, each base has an activity log and row history, and team admins get operation and login logs. No per-call log for a token was found (10 of 15). The security page gives security@seatable.com, links the management report of a September 2024 penetration test, says SeaTable has no certification and that a bug bounty is under construction. No security.txt and no published advisory found (8 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-security):

- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.
- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.
- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.
- 0 to 15, audit logs or per-call visibility for the operator.
- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.

Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.

## 3. Reliability, 69 out of 100, up to 6.2 more on the total

Why it scored 69: Graded on SeaTable Cloud's REST API and hosted MCP server, with the hosted lines. Status page at status.seatable.com, a Gatus dashboard with 15 components and uptime per component for up to 365 days (20). It publishes no incident reports. The base operations API shows 99.23 per cent over 30 days and 99.38 per cent over 365, the account API 99.95 per cent and the MCP server 99.98 per cent over 30 days. The failed checks we could read, from 5 to 8 October 2026, answered HTTP 200 with a body status of degraded, the longest stretch 34 minutes on 8 October. That is frequent degradation with no outage established, so 15 of 30 as a judgement call. Rate limits are published with numbers, 200 base calls and 1,000 account calls a minute on the cloud, plus monthly quotas (15). The docs recommend exponential backoff and base calls return `x-ratelimit-limit`, `x-ratelimit-remaining` and `x-ratelimit-reset` headers, but a 429 has no body, no Retry-After header is documented and there are no idempotency keys. The MCP server retries a 429 three times with backoff (9 of 15). No SLA text found. The pricing page names optional SLAs for Dedicated only (0). The REST API is generally available and the MCP server is at 1.6.4 (10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):

Hosted APIs, MCP servers, models and platforms.

- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).
- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.
- 15, rate limits documented with numbers.
- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.
- 10, an SLA published for any paid tier.
- 10, the surface agents use is generally available, not beta or preview.

Local packages, SDKs, frameworks and stdio MCP servers.

- 20, installs from an official package with supported runtimes stated.
- 25, a public CI and test suite, passing on the default branch.
- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).
- 15, semver discipline and breaking changes called out in a changelog.
- 15, version 1.0 or later, or declared stable.

Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.

## 4. Agent ergonomics, 74 out of 100, up to 4.2 more on the total

Why it scored 74: The hosted MCP server registers 21 tools, in the 11 to 30 band, and leaves out table and column changes by design. REST list calls take `start` and `limit`, and SQL can select columns (17 of 25). List rows pages by `start` and `limit` up to 1,000 and reads a saved view, SQL takes WHERE, ORDER BY and LIMIT up to 10,000 rows, and MCP has `page` and `page_size` (20). The reference lists status codes and says most 4xx answers carry an error code, but a 429 has no body and few operations document an error response. The MCP README maps common error messages to causes (11 of 20). No idempotency keys on the REST API. Every MCP tool carries readOnlyHint, destructiveHint and idempotentHint, and `upsert_rows` writes by key columns (14 of 20). Official clients for Python, JavaScript and PHP. A REST caller has to exchange the API token for a Base-Token and renew it every 3 days, which the clients and the MCP server do for it (12 of 15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):

- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).
- 20, pagination, filtering and output-size controls.
- 20, actionable, documented error responses, codes and messages an agent can recover from.
- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.
- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.

Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.

## 5. Schema & documentation, 81 out of 100, up to 3.1 more on the total

Why it scored 81: Public OpenAPI 3.0 files for version 6.2, 404 operations in 8 files, and every MCP tool has a JSON Schema generated from a Zod model (25). `llms.txt`, `llms-full.txt` and Markdown copies of the reference pages are served at api.seatable.com (10). MCP tool descriptions say which tool to use for which job, and `query_sql` lists its syntax limits and tells the caller to switch tools after a failure. REST descriptions are specific but uneven (16 of 20). Parameters are typed, with a UUID pattern on `base_uuid`, 67 enums in the base operations file and column types as a oneOf, but row bodies are free-form objects keyed by column name and SQL is one string (9 of 15). The base operations file has 136 examples. Most operations document only a 200 response, and the status codes page is a generic table (8 of 15). The API changelog has an entry per server version with breaking changes marked, the spec repository has a branch per version, and paths carry `v2` or `v2.1`. No changelog file was found in the MCP repository (13 of 15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):

APIs and MCP servers.

- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).
- 10, llms.txt or Markdown docs served for agents.
- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.
- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.
- 0 to 15, examples and documented error responses.
- 15, versioning and a public changelog.

Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.

## 6. Transparency & trust, 75 out of 100, up to 2.2 more on the total

Made of editorial 65, provenance 85.

Why it scored 75: SeaTable Cloud is a closed service with clear terms, and the MCP server and its tool definitions are MIT (18 of 30). The privacy policy (version 1.3.0, 5 February 2026), a public data processing agreement and a page of technical and organisational measures agree on hosting in German data centres. Server logs are deleted within 180 days and deleted bases after 30 days in the recycle bin, but account data is removed 'after a few days' with no figure. The 2022 terms name only Frankfurt and say processor agreements are available on request, while the security page adds Munich and the agreement is public (23 of 30). No deprecation policy found. Breaking changes are marked in the API changelog at release, and the terms say they may be updated without prior notice (6 of 20). A sub-processor list (version 1.1.5, 16 October 2025) gives six companies with addresses and roles, and the security page names the two data centres (18 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):

- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.
- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).
- 0 to 20, a deprecation policy or notices with dates.
- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).

The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.

Provenance checks not met in full (half of this category, computed from checked facts):

- Terms of service: read, states 5 of the 7 things a reader expects, and has 1 clause that costs points (6.3 of 10)
- Privacy policy: read, states 6 of the 8 things a reader expects (8.5 of 10)
- security.txt: not found (0 of 10)

## 7. Maintenance & community, 76 out of 100, up to 2.1 more on the total

Why it scored 76: The newest release we could date is MCP server 1.6.4 on 4 September 2026, 34 days before the check. SeaTable Cloud reported server version 6.2.13, whose date we didn't find. The product changelog gives 6.2.12 on 17 July 2026 (20 of 30). Five MCP server releases since 25 August 2026 and the API changelog entry for version 6.2 on 21 July (20). The forum's latest topics each had replies within a few days, in English and German. We didn't read who replied, and GitHub's API refused us, so issue reply times are unread (14 of 25). The MCP server is in the official MCP registry as `io.github.seatable/seatable` at 1.6.4, and the Python client had release 4.0.0 on 17 July 2026 (15). The MCP repository's CI runs lint, a type check and tests before each publish, and the OpenAPI repository has an API test suite. We didn't read the current CI result (7 of 10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):

- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.
- 20, at least three releases or dated changelog entries in the last 90 days.
- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.
- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).
- 10, package health, current dependencies and CI.

Models are read for deprecation notice periods and model churn rather than release counts.

## What we couldn't check

What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.

- unchecked: incident history before 5 October 2026. The status page keeps only the last 50 events per component and publishes no incident reports, so the record rests on its uptime percentages
- unchecked: GitHub stars, issue reply times and the current CI result. GitHub's API answered with a rate limit, so `githubStars` is empty
- unchecked: the hosted MCP server's live tool list. The 21 tools come from the source at tag release-v1.6.4, and the endpoint answered 401 without a token
- unchecked: whether signup asks for email confirmation or a captcha. We didn't create an account. The registration page says no credit card is required
- unchecked: the release date of server version 6.2.13, which SeaTable Cloud reported. The product changelog page lists 6.2.12 on 17 July 2026
- unchecked: the registration record of seatable.io, the domain the REST API answers on
- unchecked: the rendered API reference pages. api.seatable.com answered 429 to our later requests, so limits, authentication, status codes and the changelog were read from the Markdown sources in the OpenAPI repository and from `llms-full.txt`
- No SLA text, security.txt, bug bounty, certification, deprecation policy, Retry-After header, idempotency key or prompt-injection guidance was found in the reviewed pages
- The limits page gives 200 base calls a minute for SeaTable Cloud, and the MCP server's README gives a default of 500 per base, which is the figure for Dedicated and Server
- The pricing page lists prices in euros only, so `unitPrices` is empty and the figures are in `pricingNotes`
- The lead was right on vendor, URL and the REST interface. It missed the official MCP server, hosted at mcp.seatable.com and listed in the official MCP registry. API tokens are per base and read-only or read-write, with no finer scope, and base calls need a 3-day Base-Token generated from them

## Weaknesses

- Monthly API call quotas by plan, 3,000 for a whole Free team, 10,000 per user on Plus and 50,000 per user on Enterprise
- A 429 response has no body and no Retry-After header is documented, and the REST API has no idempotency keys
- Tokens can't be limited to a table, and the MCP tool `query_sql` accepts UPDATE and DELETE statements with no confirmation step
- The security page says SeaTable holds no certification, and its bug bounty, expected in 2025, is still described as under construction
- No SLA text is published. The pricing page names optional SLAs for Dedicated only, and the terms exclude liability for uninterrupted availability

## What costs an agent a turn today

The notes we give agents before they call it. Each one is a workaround an agent shouldn't need.

- Create an API token for the one base with read-only permission unless writes are needed, then exchange it at `/api/v2.1/dtable/app-access-token/` for a Base-Token
- Renew the Base-Token before it expires after 3 days, and send it as `Authorization: Bearer` to `/api-gateway/api/v2/dtables/{base_uuid}/`
- Read `x-ratelimit-remaining` and `x-ratelimit-reset` on every base call. SeaTable Cloud allows 200 base calls a minute and answers 429 with no body
- Batch writes to save the monthly quota. One call appends or updates up to 1,000 rows over REST and 100 over MCP
- Over MCP, prefer `update_rows` and `delete_rows` to `query_sql`, which can run UPDATE and DELETE, and call `get_schema` before writing

## When it's done

Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.