Coda, renamed Superhuman Docs in July 2026, now hosts an official MCP server that Claude and ChatGPT connect to with one click, and it also has a REST API that has been stable since 2020. The MCP server can build a table from scratch; the API cannot. The API can sync only the rows that changed since your last run; the MCP server has no equivalent. And the two paths authenticate users in completely different ways. This guide compares what each lets an agent do, the credential each one puts you on, and how to run either across many customers in production.
Your agent needs to work inside your customers' Coda docs: read the launch tracker, update the status of 40 rows after standup, append meeting notes to the right page, or press the button that files a Jira ticket from a row. Coda now hosts an official MCP server that Claude and ChatGPT connect to with one click, and it also has a REST API that has been stable since 2020. The MCP server can build a table from scratch; the API can't. The API can sync only the rows that changed since your last run; the MCP server has no equivalent. And the two paths authenticate users in completely different ways. Here's how to pick.
The Superhuman Docs MCP server is a remote Model Context Protocol (MCP) server maintained by Superhuman (formerly Coda, part of the company formerly called Grammarly). It was announced in public beta on April 1, 2026, gained charts, comment resolution, and richer view configuration in a June 4 update, and was opened to all users when Coda became Superhuman Docs. The server URL is https://docs.superhuman.com/apis/mcp; existing connections to the legacy coda.io endpoint keep working.
The tools reference lists 32 tools, including search, document_create, document_outline, page_create, table_create, table_rows_read, table_rows_manage, table_columns_manage, table_view_manage, content_read, content_modify, comment_add, formula_execute, and control_manage, along with delete tools for documents, pages, tables, rows, columns, views, comments, and controls. The same page warns that tool names and parameters may change and tells agent builders to discover tools at runtime with listTools rather than hardcoding names.
Clients connect with OAuth 2 (Claude, ChatGPT, Cursor) or with a personal access token whose restriction type is set to MCP (Codex, Copilot Studio, Google Antigravity). The connection guide is the official setup reference.
The Coda API v1 is a REST API at https://coda.io/apis/v1. It covers docs, folders, pages, tables, columns, rows, formulas, controls, sharing and permissions, publishing, analytics, page content export, and a whoami endpoint. Row operations include list, get, insert, upsert by key columns, update, and delete. Two action endpoints matter for agents: pushing a button column on a row, and triggering a doc automation whose trigger is "Webhook invoked."
Authentication is a Bearer API token created under API settings on the user's Coda account page. A token can do everything its creator can do unless it is restricted to read only, write only, or read and write, and optionally to one doc or one table. The API is free on both free and paid plans, though creating a doc requires the token owner to be a Doc Maker.
The pattern is clear. The MCP server is a doc builder: it shapes structure, views, and content the way a person in the editor would. The API is a data plane: it moves rows in and out reliably, tracks what changed, and fires the actions a doc author already defined. Neither is a superset of the other.
Building a doc. "Turn these meeting notes into a tracker with Owner, Status, and Due date columns, grouped by Status" is one conversational turn on the MCP path, because table_create, table_columns_manage, and table_view_manage exist. On the API path, that request is impossible without a human creating the table first.
The MCP server also handles name resolution that the API pushes onto you. name_match turns "the Q4 roadmap table" into a table ID, and search spans docs, pages, and rows at once. On the API, the agent chains coda_docs_list, coda_tables_list, and coda_columns_list before it can write a single cell, and Coda discourages addressing tables and columns by name because users rename them.
Writing the schema is the hard part. Not the API call. Superhuman wrote these schemas and keeps them current; the tradeoff is that they may change during the server's development, so anything you hardcode against them can break without a version bump.
OAuth 2 is the default for Claude, ChatGPT, and Cursor. The scope is always read and write, but during consent the user picks Full access or Limited access, and Limited access restricts the connection to specific workspaces or folders. That folder boundary is the most useful least-privilege control on either path, because it bounds which docs the agent can touch, not just which verbs it can use.
The alternative is a personal access token with its restriction type set to MCP, which can be read only, write only, or read and write. The token type matters: a token created for the REST API returns 401 against the MCP endpoint, so the two paths need separate credentials even for the same user.
Plan and role shape what the credential can do. Doc Makers on paid plans get every tool. Doc Makers on free plans get 30 requests per week, capped at 60 per month. Editors get the same allowance and read tools only. A B2B agent whose customers include free-plan users will hit that ceiling in the first afternoon.
The REST API has no OAuth flow. Each user generates an API token in their account settings and hands it to your app. By default that token can do anything the user can do, across every doc they can open, until they delete it. A token can't be viewed again after creation.
Restrictions are the mitigation, and they are good ones. A token restricted to read only on /docs/AbCDeFGH/tables/grid-pqRst-U can read one table and nothing else. For an agent that only syncs a single tracker, ask users for exactly that. The cost is onboarding friction: users must create the right token, with the right restriction, for the right doc, by hand. whoami returns a scoped boolean and the tokenName, so your app can at least verify whether a pasted token is restricted before storing it.
What the user can't do, the agent can't do. On Coda, an unrestricted token makes that the only boundary there is.
In a multi-tenant B2B agent, MCP gives you a credential per user and the direct API gives you a credential per user. In neither case does the path itself solve storage, rotation, or revocation; those are infrastructure problems regardless of which path you choose.
Coda sharpens the API side. A long-lived Bearer token has no refresh cycle that would surface a revoked grant. If a user deletes the token in Coda, your agent finds out on the next call with a 401, mid-task. Until then, it keeps working for as long as it sits in your database.
Recommended reading: OAuth vs API keys for AI agents
Superhuman hosts the server, owns the tool schemas, and runs the OAuth authorization server. You own the client side: storing each user's OAuth tokens or personal MCP tokens, handling consent that a user narrowed to two folders when the agent needs a third, and handling the free-plan request allowance when it runs out.
You also own drift. The tools reference says names and parameters may change. An agent that discovers tools at runtime survives that; a deterministic workflow that calls table_rows_manage with a fixed argument shape may not. And the MCP server is session-bound: it has no triggers or schedules, and it does nothing until a client calls it.
You own the asynchronous write model. Every insert, upsert, update, page change, button push, and automation trigger returns 202 Accepted with a requestId. The change usually lands within a few seconds, but it can fail after you received the 202. An agent that writes a row and immediately reads it back may see stale data; one that reports "updated" without checking mutationStatus may be wrong. Edits made in the Coda UI also take a few seconds to appear in the API.
You own rate limits, which are per user and shared across all docs: reading data, 100 requests per 6 seconds; writing data, 10 requests per 6 seconds; writing doc content, 5 requests per 10 seconds; listing docs, 4 requests per 6 seconds. A 429 means back off and retry. Batch row writes into one upsert rather than one call per row, or a 40-row standup update becomes four 6-second windows of throttling.
You own ID hygiene. Doc IDs come from the URL segment after _d, table IDs look like grid-pqRst-U, columns like c-tuVwxYz, rows like i-tuVwxYz. Names work but break silently when someone renames a column, so a production agent resolves names to IDs once and stores the IDs.
The REST API is versioned as v1, and Coda commits to a three-month deprecation notice for removals. That stability is the reason Superhuman's own staff recommend the API over the MCP server for deterministic scripts. The MCP server moves faster: four months after the beta opened it had gained charts, view layouts, and conditional formatting. Faster features, less predictable contracts.
Both paths give you a Coda credential per user. Neither gives you a vault. A multi-tenant agent with 80 customers and 6 users each holds 480 Coda credentials. On the API path, each is a long-lived Bearer token that grants everything the user can do unless they restricted it, has no refresh cycle, and can be deleted by the user at any time without notice to you. On the MCP path, each is an OAuth grant or a typed personal token, with its own expiry and refresh behavior.
Every one of those must be encrypted at rest, kept out of logs and out of LLM context, mapped to exactly one user and one customer, and destroyed when the user disconnects or the customer churns. The tempting shortcut is one admin's token for the whole customer. That turns every user's agent into the admin, collapses your audit trail to one identity, and gives one leaked string access to every doc that admin can open.
Scalekit's coda connector collects each user's Coda API token through a hosted page, stores it in the token vault, and injects it on every call, so the MCP vs API decision doesn't change your auth infrastructure. Your agent passes an identifier; the token never enters the agent runtime or the LLM context.
Recommended reading: why a token vault matters for AI agent workflows
Scalekit's coda connector is an API-path connector with 37 tools: 26 read and 11 write. It has no destructive tools, so an agent built on it cannot delete a doc, page, or row through a prebuilt tool. Users authenticate with their Coda API token, entered once on a Scalekit-hosted page and stored as that user's connected account.
In the Scalekit dashboard, go to AgentKit > Connections and create a Coda connection. There is no OAuth client to register, because Coda's API uses per-user tokens. The connection name you choose is the connection_name your code passes, and the string must match the dashboard exactly. This is the most common integration error.
Copy SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers > API Credentials into .env. Tell your users to create a Coda API token under API settings on their Coda account page, restricted to the narrowest doc or table and access level your agent needs.
get_or_create_connected_account returns the user's connected account. If it is not ACTIVE, get_authorization_link returns a link to a Scalekit-hosted page. For an API token connector like Coda, that page asks the user to paste their token instead of running an OAuth consent flow. Your app never sees the token, and it never appears in chat or agent context.
The coda_current_user_get call wraps Coda's whoami, so the response tells you whose token this is and whether it is scoped. Check it before the first real run.
This is not a catalog load. The agent asks for the tools this user's connected account is authorized to call, then narrows them to the five a tracker-review agent needs. coda_rows_upsert, coda_row_button_push, and coda_automation_trigger never reach the model, so it cannot rewrite rows or fire a doc's automations while answering a question about status.
The loop runs until the model stops requesting tools. Every tool call executes with this user's Coda token, injected by Scalekit. The doc ID comes from your app's config for this customer; it is the part of the doc URL after _d.
For pipelines, skip the model. execute_tool runs one tool with a fixed input and returns data plus an execution_id you can log. This job pages through a table once, keeps the nextSyncToken Coda returns at the end of the full listing, and on later runs fetches only the rows that changed.
Writes are asynchronous. coda_rows_upsert with key_columns updates the row whose key matches and inserts it otherwise, so a retry after a timeout doesn't create duplicates. The response carries a requestId; coda_mutation_status_get confirms the change actually applied.
Column names keep this example readable. In production, resolve them once with coda_columns_list and store the c- IDs, because a renamed column breaks a name-based write.
To run logic the doc already owns, trigger an automation whose trigger is set to "Webhook invoked." The rule ID comes from the automation's settings in the doc; the payload is whatever JSON the automation reads.
When a capability has no prebuilt tool, such as deleting a row, Scalekit's API proxy calls Coda's REST endpoint directly with the same user's vaulted token, so the destructive operation stays an explicit choice in your code rather than a tool the model can pick.
The coda connector has 37 tools. At roughly 200 tokens each, that is about 7,400 tokens of tool definitions before the agent reads a row, and a model choosing among coda_row_update, coda_rows_upsert, coda_row_button_push, and coda_automation_trigger will sometimes choose wrong. A digest agent needs three of them. A Scalekit virtual MCP server declares exactly which tools an agent role can see, and session tokens keep each run bound to one user's connected accounts. Docs: set up a virtual MCP server.
One server definition serves every user. Before each run, check that the user's accounts are active and mint a short-lived session token scoped to them. Any MCP client that speaks Streamable HTTP can connect; this example uses langchain-mcp-adapters (pip install langchain-mcp-adapters) and passes the token as a Bearer header.
The agent sees four tools, not 37. The endpoint is static; the identity is per-user. This also gives you an MCP endpoint backed by Coda's versioned REST API rather than a beta tool surface, with a credential that can be restricted to one table.
Every execute_tool call returns an execution_id, and every execution is attributed to a connected account, which maps to one of your users and one customer. Coda adds its own reference: each write returns a requestId. Log both together, and when a customer asks which agent run changed 40 rows in their launch tracker or pressed the button that filed duplicate tickets, the answer is a lookup, not an investigation.
A shared token breaks that. If every user's agent runs on one admin's Coda token, Coda's doc history shows the admin making every edit, and your logs can only prove that the shared token did it. Shared credentials are a single-user solution. They do not survive a second user.
Recommended reading: audit trails for agent auth
If your agent is a person's assistant inside Claude, ChatGPT, or Cursor, building tables, restructuring pages, and working through comments on request, use the Superhuman Docs MCP server: it can do things the API cannot, and its folder-limited OAuth is a sound boundary for interactive use. If your agent runs on a schedule, syncs rows, presses buttons, or triggers automations for many customers, build against the Coda API: you get syncToken, versioned contracts, and tokens restricted to one table. Many teams will end up with both, the MCP server for authoring and the API for operations. Either way, every user brings a Coda credential that has to be stored, scoped, and revoked, and that's what needs production-grade infrastructure.
Yes. Superhuman Docs, formerly Coda, hosts it at https://docs.superhuman.com/apis/mcp. It went into public beta on April 1, 2026 and opened to everyone with the rename on July 8, 2026. Its 32 tools build and edit docs: create tables and columns, configure views and charts, add and resolve comments, evaluate formulas, and delete docs, pages, tables, and rows. Superhuman warns that tool names and parameters may change.
Incremental row sync with a syncToken, page export to Markdown or HTML, pushing a button column on a row, triggering a webhook-invoked automation, and inspecting sharing and permissions. It cannot create a table or a column, and every write is asynchronous: a 202 with a requestId that you confirm through the mutation status endpoint.
The MCP server supports OAuth 2 with Full or Limited access, where Limited restricts the connection to specific workspaces or folders, plus personal tokens with an MCP restriction type. The REST API takes only a Bearer API token, which can be restricted to read, write, or both and to a single doc or table. A token created for the REST API returns 401 against the MCP endpoint, so the two paths need separate credentials.
Per user, shared across all docs: 100 read requests per 6 seconds, 10 write requests per 6 seconds, 5 doc content writes per 10 seconds, and 4 doc listings per 6 seconds. Batching row writes into one upsert matters, because a 40-row update sent one call at a time spans four throttling windows.
When it runs headless on a schedule and pulls only changed rows with a syncToken, when it upserts CRM records keyed on a column with idempotency and mutation checks, when it should fire logic the doc author built through buttons and automations, or when it needs a credential scoped to one table so a compromised token exposes one tracker rather than a workspace.
The coda connector exposes 37 tools over the Coda API with no destructive tools. Each user pastes their Coda API token once on a Scalekit-hosted page, Scalekit stores it in the token vault and injects it on every call, coda_current_user_get reports whether the token is scoped, a virtual MCP server narrows the tools per agent role, and every execution returns an execution_id next to Coda's requestId.
Browse the Scalekit Coda connector and the Coda connector docs with the full tool list. See Scalekit pricing, or talk to us.
