I built a Google Sheets MCP server so Claude reads my sheets

At my day job we kept our FAQ in a Google Sheet so non-technical teammates could edit it without touching code. A third-party service turned that sheet into an API the website could read. It worked until the FAQ page started showing up blank. No error, no warning, just an empty page. The service's free tier had a low monthly request cap, and ordinary traffic had quietly used it up.

My fix was not a good one. I made three more accounts on the same service and rotated them by hand, so we never leaned on any one account long enough to hit its limit. Two simple sheets now needed four juggled logins just to stay online.

That is the problem PasteSheet exists to solve. You paste a Google Sheet URL and it gives you a reliable, cached API for that sheet. This post is about a newer part of it: the MCP server, which lets an AI agent like Claude read your sheet directly. If you have ever wanted Claude or Cursor to answer questions straight from your own spreadsheet, this is how you do it.

What an MCP server actually is

MCP, the Model Context Protocol, is the standard way AI clients like Claude and Cursor connect to outside data. An MCP server hands the AI a set of tools it can call. The AI decides when to use them and what to do with the results.

A "Google Sheets MCP server" is simply a server that gives the AI tools for reading one spreadsheet. PasteSheet builds and hosts that server for you. You paste a share URL, and any MCP-compatible client can connect to it. There is no Google Cloud project, no OAuth consent screen, and no service-account file to set up.

Publish a sheet, don't connect your account

Most tools solve this by connecting your entire Google account to the agent, behind OAuth and a Cloud project you have to configure yourself. That hands the agent far more than the one sheet you actually care about. Google's own tooling works this way, and so does Zapier.

PasteSheet does the opposite. You publish a single sheet as its own endpoint, and the agent can read that sheet and nothing else in your Drive. There is also no write path anywhere in the product, so the connection is read-only by design. That is what makes an endpoint safe to hand to an autonomous agent: there is no tool it could call to overwrite your source of truth.

The three tools your agent gets

Once connected, the AI has three read-only tools:

• list_tabs shows the tabs in the sheet and which one is the default.
• get_schema shows each column's name and type, so the AI knows what it is working with before it runs a query.
• query_rows reads the rows, with filtering, full-text search, sorting, and pagination.

The middle one, get_schema, is what makes this reliable. If the AI does not know your column names, it guesses them, and half its queries fail. When it can read the schema first, it uses the real names and the queries work. That single tool was the difference between "usually works" and "just works."

Connecting it

Every endpoint has its own MCP URL. In a Claude Desktop style client you add it to the config:

{
  "mcpServers": {
    "pastesheet": {
      "url": "https://pastesheet.com/mcp/sheets/your-endpoint-id"
    }
  }
}

In Claude Code it is a single command, with no config file to edit:

claude mcp add --transport http pastesheet https://pastesheet.com/mcp/sheets/your-endpoint-id

The Claude connection guide walks through Desktop, web, Code, and Cursor step by step. Public endpoints need no key. For a private one you pass ?api_key=... in the URL, or send an Authorization: Bearer header.

After that you just ask questions in plain English. Here is a real exchange against a products sheet:

Me:     Which rows in my catalog are out of stock and under $50?
Claude: [calls get_schema, sees columns: name, price, stock, category]
        [calls query_rows filter stock=0, price<50, sort by price]
        4 items: Ceramic Mug ($12), Sticker Pack ($6), Notebook ($18), Cable ($24).

I never told Claude the column names. It read the schema, wrote the query, and answered.

Why it caches, and where that stops

AI agents ask a lot of small questions. To answer one prompt, Claude might list the tabs, read the schema, and then run several filtered queries in a row. If each of those hit Google directly, you would run into Google's limits fast. The Sheets API allows 300 reads per minute per project and only 60 per minute per user, and it returns a 429 error once you cross that line. It is the same kind of silent cap that broke my FAQ page in the first place.

So PasteSheet reads your sheet once and caches the rows. Every tool call after that is served from the cache, which means the agent's tenth query costs Google nothing.

That cache comes with a cost worth being honest about. You choose how long it lasts, from 30 seconds to an hour, and within that window the agent sees the cached copy rather than an edit you made a moment ago. And because everything is read-only, the agent can analyze your sheet but never change it. If you need an agent that writes back to a spreadsheet, this is the wrong tool. If you want a source of truth that agents can read safely, that read-only limit is exactly the feature you want.

It's in the MCP Registry

You don't have to take my word for the setup. The server's docs, client config, and registry manifest are public on GitHub, and it is listed in the official MCP Registry as com.pastesheet/google-sheets, so any client that browses the registry can find and connect to it.

---

I build PasteSheet. Paste a Google Sheet URL and get a cached JSON API plus a read-only MCP server your AI agent can query. Free tier, no credit card, no Google Cloud project.

Comments

[Mads Hansen]

Nice example of capability minimization: one sheet, three read tools, and no write path is a much smaller authority surface than Drive-wide OAuth.

Two contracts would make the cached source especially trustworthy for agents. First, return a snapshot identifier plus fetched-at/source-modified-at timestamps on every schema and row result, so multiple tool calls in one answer can be pinned to the same cache generation and the user can judge staleness. Second, version inferred column types: Sheets is weakly typed, so one newly entered value can change filtering or sorting semantics even when headers stay unchanged.

For private endpoints, I would strongly prefer the Authorization header over ?api_key=. Query-string secrets are prone to appearing in shell history, client config, proxy/access logs, screenshots, and monitoring. It would also help to document rotation/revocation, cache eviction after access changes, pagination/result limits, and whether a previously public sheet remains cached after its sharing settings are tightened. Read-only protects the source; those details protect the copied data and the answer built from it.