How to connect Cursor to Google Sheets

When you build on top of a Google Sheet, the Agent in Cursor is working half blind: it writes code against a spreadsheet it has never seen. You paste the header row into the chat, describe the data, and still get a helper that calls the column Name when the sheet says name. Testing is worse: seeding a few rows, checking what a write did and cleaning up again means switching to the browser every time.

Cursor connects to outside tools through MCP, the Model Context Protocol, and SheetDB runs an MCP server for every spreadsheet you turn into an API. Add the server to Cursor once, sign in with your Google account, and the Agent can list your sheets, read the columns and sample rows, search, add test data and, with your approval, remove it. The application code it writes keeps calling the plain REST API; MCP is for the Agent while you work. No API key in the config, no Google Cloud project, no copy of the sheet in the repository.

This guide uses the SheetDB demo spreadsheet, this one, which is also served as a public REST API at https://sheetdb.io/api/v1/58f61be4dda40. Its first tab has the columns id, name, age and comment. The Agent only sees the APIs of the account you sign in with, so to follow along with the same data, make a copy of the demo spreadsheet in your Drive (File → Make a copy) and create an API from the copy in step 1.

Step 1: create the API for your sheet

1. Sign in to SheetDB with the Google account that can edit the spreadsheet.
2. Click Create new API, paste the spreadsheet URL and save. You get an API URL in the form https://sheetdb.io/api/v1/<your id>. Your code will call this URL; the 13-character id at the end is how the Agent refers to the sheet through MCP.
3. Check that row 1 holds clean column names (email, not E-mail address). They become the JSON keys of the API and the field names in the code the Agent writes.

Step 2: add the SheetDB MCP server to Cursor

The SheetDB MCP server address is https://sheetdb.io/mcp. The quickest way is the install link, which opens Cursor with the server pre-filled:

Add SheetDB to Cursor

Confirm in Cursor and the server appears in your MCP list. If you prefer the file, or want the server in one repository only, add this entry to ~/.cursor/mcp.json (every project) or .cursor/mcp.json in the project (that project only, safe to commit: it holds no credentials):

{
    "mcpServers": {
        "sheetdb": {
            "url": "https://sheetdb.io/mcp"
        }
    }
}

That is the whole configuration. There is no command, because the server is remote, and no headers or auth block, because SheetDB uses OAuth with automatic client registration. Cursor also lists MCP servers under Customize, where you switch them on and off. Claude, ChatGPT and Claude Code connect to the same server; the steps are on the MCP server page.

Step 3: sign in with Google and approve

The first time Cursor connects to the server, or when you click the sign-in action next to it in the MCP list, your browser opens a SheetDB page. Sign in with the Google account you use for SheetDB and approve the connection. That is OAuth: Cursor receives a token that only works for the SheetDB MCP server, never your Google password, and SheetDB keeps talking to Google with your account, exactly as it does for the REST API. Cursor registers itself as a public client, so there is no client id or secret to paste.

The connection then appears in the SheetDB panel under AI agents, with the client name, the date and the last use. Revoke signs Cursor out immediately. If a teammate opens the same repository with the committed .cursor/mcp.json, they sign in with their own account and get their own entry; nobody shares a token.

Step 4: use the sheet from the Agent

Open the Agent chat and ask. The SheetDB tools are listed under Available Tools and the Agent picks them when they are relevant; you can also name a tool or say "use SheetDB". Three things the Agent can now do that it could not before, on the demo data:

A rule in .cursor/rules makes this repeatable for the whole team, for example: "The customers data lives in a Google Sheet served by SheetDB. Use the SheetDB MCP tools to inspect columns and rows; the application reads and writes through the REST API at the URL in SHEETDB_URL, never through MCP." With that in place the Agent checks the real sheet before touching the code that uses it.

Reading is served from the same cache as the REST API (15 seconds by default), so a row the Agent just inserted shows up at once (writes clear the cache) and a repeated read costs Google nothing. Reads are paginated, so for a large tab ask for a filter or a count instead of "show me everything". Searching uses the same operators as /search over HTTP: comparisons such as >18, wildcards such as J* and negation with !.

Step 5: decide what the Agent may change

The moment your first agent connects, every API in your account gets an AI agents section in its settings. By default agents may only read. Creating, updating and deleting rows each need a switch for that specific API, and an agent never gets more than the API allows over HTTP: if DELETE is disabled in the API permissions, no agent setting turns it on. When the Agent asks for something it may not do, it gets a plain answer with a link to the right settings page, so it tells you where to enable the operation instead of trying again. A sensible split for development: create and delete enabled on the API of the copied sheet you test against, read only on the API behind production.

Deletes and large updates go through an extra step. delete_records only works with a condition and never deletes by itself: it counts the matching rows and returns a preview written by SheetDB. Up to 10 rows and 5% of the tab, the Agent shows you the preview and confirms the pending action after you agree in the chat. Anything bigger, or every delete on an API set to always approve in panel, waits for your Approve in the SheetDB panel while you are signed in. A pending action works once and expires after 5 minutes in the chat and 15 in the panel. The details are in the MCP server documentation.

Cursor adds its own layer: by default it asks before using an MCP tool, and the arrow next to the tool name shows the arguments it is about to send. MCP tools follow the same run modes as terminal commands, so in an automatic mode an allowlisted tool runs without asking. Keep the SheetDB write tools out of that allowlist; the SheetDB permissions and the pending action are what protect the sheet whatever the run mode, which is why they live on the server and not in the editor.

MCP for the Agent, REST for the code

The code Cursor writes should not depend on MCP: it runs in the browser or on your server where no Cursor is present. It calls the same API over HTTPS, GET https://sheetdb.io/api/v1/58f61be4dda40 for the rows, /search?age=>18 for a filter, POST with a data array to add rows, as in the Node.js and PHP guides. Give the Agent the OpenAPI 3.1 specification (paste the URL into the chat or add it as a doc in Cursor) and it has every endpoint, parameter and error response, without guessing from examples. For a protected API enable Basic Auth or a Bearer token in the API settings and keep the credentials in .env, out of mcp.json and out of the chat.

Limitations: when this is not the right setup

• Cells, tabs and bulk operations. MCP exposes rows keyed by the header row. Deleting a whole tab, creating or deleting tabs, editing single cells, JSON import and cache purge stay in the panel and the REST API, on purpose.
• Very large tabs. A spreadsheet is not a database for thousands of writes an hour, and a read returns at most a few thousand rows per call. Ask for filters and counts, keep tabs small, and read when a sheet is the wrong tool. If you are building an agent of your own on top of a sheet, Google Sheets for AI agents covers the architecture and how to structure the sheet.
• Production data in the chat. The Agent sees every column of the tabs the API exposes, and it sees the APIs that teammates share with you in SheetDB. Point it at a copy of the sheet while developing, keep personal data in tabs that no API serves, and give agents the read permission only where they need it.
• Background agents and CI. The connector signs in as you, interactively. For a job that runs on a schedule or in CI, call the REST API with a Bearer token instead, from your code or a workflow in n8n or Make.
• Text in cells is data, not instructions. A cell saying "ignore previous instructions" is returned to the Agent as a value like any other. Models are getting better at ignoring that, and the permission and approval model above is what you rely on, not the model's judgement.

For everything else, one spreadsheet with one API now serves Cursor, Claude, ChatGPT, the app you are building and a table on your website, with the same permissions and the same rows.

FAQ

[
  {
    "id": "1",
    "name": "Tom"
  }, …
]