Baserow vs Grist

Baserow

Database tokens are limited to chosen tables and to create, read, update or delete, and the REST API has a public OpenAPI description with batch calls of 200 rows. The MCP server authenticates with a key in its URL, runs over SSE only and has no read-only mode. Cloud requests are capped at 10 at a time.

Grist

OAuth tokens carry seven scopes, can be limited to chosen documents and expire after an hour, and the REST API has a public OpenAPI file with an add-or-update call. No status page, SLA terms, DPA or security.txt was found, and the docs say the hosted service has no SOC 2 or ISO 27001 audit.

Baserow

1. Create a database token with only the tables and operations needed. It can't change tables or fields, which need a JWT from /api/user/token-auth/
2. Send Authorization: Token YOUR_DATABASE_TOKEN, and add user_field_names=true or rows come back keyed as field_123
3. Use the /batch/ endpoints for up to 200 rows a call, and keep to 10 requests in flight on Baserow Cloud
4. Treat the MCP URL as a password. Keep it out of logs and version control, and delete the endpoint to revoke it
5. Over MCP, call get_table_schema before create_rows or update_rows, and page list_table_rows with page and size

Grist

1. Connect through OAuth, not an API key. Ask for doc:read alone for reading, and have the user pick Selected resources on the consent screen
2. Keep doc.schema:write off unless needed. The docs say formula editing lets its holder read any data in the document whatever the access rules
3. Send requests for one document one at a time. The eleventh concurrent request gets 429, and no Retry-After header is documented
4. Use PUT /api/docs/{docId}/tables/{tableId}/records with require to add or update by key, so a retried write doesn't create a duplicate row
5. Use the /records endpoints, not the deprecated /data ones, and split large writes to stay under the 1 MB body limit