Coda MCP server: headless auth for server-side agents?

Developers Central
1

Hi all,

Question about the Coda MCP server that I can’t find in the docs: how does auth work for a backend agent, with no human around to do the interactive OAuth flow?

Right now we use the MCP server through Claude Desktop, where auth is the browser OAuth prompt and the token ends up tied to my personal Coda account. That’s fine interactively. But we want to call the same server from a server-side agent runtime (Anthropic’s Managed Agents), where there’s no browser and nobody to click “authorize” at run time.

So:

  1. Is there a non-interactive credential option? A stored OAuth refresh token, a static bearer, or a plain Coda API token? Or is the interactive flow currently the only way in?

  2. If it’s OAuth, can we get and store a refresh token so a backend can mint access tokens unattended and auto-refresh? What does the refresh request look like (token endpoint, client auth)?

  3. Can we authenticate as a dedicated service/bot account rather than a named person, so edits aren’t attributed to an individual?

  4. Can that account be scoped to specific docs instead of the whole workspace, and what scopes does it need for content_read, content_modify, and table_rows_manage?

  5. How stable are the tool names/params during the beta, and is there a rough timeline to GA? Trying to gauge whether we can build on it now.

Background on why we care: we’ve confirmed content_modify does lossless element-level edits on rich cell canvases (inserted a bullet into a list inside a callout, and the embedded grids/views/callouts all survived), noting that this is a capability the standard API doesn’t have. That’s exactly what we want an automated docs agent to do. Headless auth is basically the only thing between us and a real prototype

@Bharat_Batra1 @Bill_French - Hoping one of you might know the answer!

Thanks

Bell

2

Hi @Bell_Arden - Thanks for the detailed questions, I’ll try my best to answer them.

  1. Yes, the Coda MCP supports using Personal Access Tokens (PATs), otherwise known as API Tokens in the Coda UI. When you create one for use with the MCP, make sure to select the MCP restriction, as it’s required for tokens to be used in the MCP.

image
image606×462 19.1 KB

  1. You can also take the approach of approving the OAuth flow once manually and storing the refresh token. This process is a bit more complicated, as you might expect. The URLs you need are in the metadata file, and you can read the MCP spec authorization documentation for more information about the process.

  2. The product doesn’t have a concept of a robot user, but you can provision a regular Coda user that you only use for this use case and then generate a token using that account.

  3. If using the approach above in #3, you can add that user to a different workspace, and then only share individual docs with it. The OAuth flow only has one scope today, mcp:all, so you can’t use scopes as a way to limit access.

  4. I think it’s best to assume that tool names and shapes aren’t stable at all. MCP tools are intended to be consumed by LLMs, which discover and call them on the fly. Building code against an MCP tool is a gamble, as the current convention is that MCP servers don’t provide any guarantee of backwards-compatibility.

You are correct that our MCP provides more capabilities than our REST API, which is unfortunate. My hope is that one day we’ll be able to bring more of this functionality into the REST API for non-agentic use cases, but at the moment there are no plans for that.

3

Hi Eric

Thanks for all the specific details, that’s super helpful and will allow me to get the system into production.

One other comment about the MCP server, as an admin on a Claude Team account - Currently, the tool list is only configurable at the individual account level, and not at the Organizational admin level. And this presents a significant barrier to deploying the Coda MCP server to staff because we cannot disable tools like delete_document or delete_table, which, for obvious reasons, we cannot expose to staff with doc editor access to our organizational docs.
So, would you be able to tell us whether this is functionality you will be adding soon?

I will also note that due to the very high context nature of our Coda docs, which no doubt is the case for many or most companies/organizations, we built our own MCP server for AI to access our organizational data in Coda so that we could provide the required context and specific tool calls to ensure the required control over our data. This was, of course, a fair bit of work, but I did it myself as an experienced Coda builder, without a coding background, so I think it’s within scope for quite a lot of people nowadays. And the results are now consistently good; Claude can, for example, provide a detailed synthesis for high-context scenarios over large datasets quickly and reliably.

Bell

4

Can you say more about this? What sort of experience would you expect?

5

hi @Bell_Arden , I would love to read more about the good work you did for your organisation regarding building your own MCP server. How did you approach that, can you elaborate a bit more, I am rather curious.

Merci, Christiaan