PasteSheet

PasteSheet turns a public Google Sheet into a cached JSON REST API and an MCP server, with no backend, no Google Cloud project, and no API keys. You paste the sheet's share URL, and it reads the tabs, headers, and rows, works out what type each column holds, and hands back a permanent endpoint your app or your AI agent can call.

The problem it goes after turns up on nearly every small project. A spreadsheet is the fastest place to put structured data, and it's usually where the non-technical people on a team are already working happily. Getting that data into software is the part that stops being fast. The official route runs through a Google Cloud project, a service account, OAuth scopes, and a token refresh you'll be maintaining forever, which is a lot of ceremony for a landing page that needs to read forty rows of pricing. It's rarely a deliberate choice to end up there, either. The sheet exists because somebody needed the data yesterday, and by the time anyone asks for a proper API it's already the source of truth for three people who aren't going to migrate. PasteSheet compresses all of that down to one paste.

What comes back is a REST endpoint at /api/{id} that returns JSON, and it isn't just a dump of the sheet. You can filter, search, sort, and paginate straight from URL parameters, so a good chunk of the querying you'd otherwise write server-side happens in the request itself. Responses are cached with a TTL you control. The free tier caches for five minutes, and paid plans let you tune it anywhere from thirty seconds to an hour, depending on whether you care more about freshness or about staying under a rate limit. Rate limits scale with the plan as well, from sixty requests a minute on the free tier up to five thousand on Agency, which tells you the caching isn't decorative. A cached endpoint absorbs traffic that would otherwise hammer Google's own limits, and that's the quiet reason the whole approach holds up under load at all.

The second half of the product explains its timing. Every endpoint is also an MCP server, at /mcp/sheets/{id}, exposing three read-only tools named list_tabs, get_schema, and query_rows. Point Claude, ChatGPT, or Cursor at that URL and the assistant can discover the tabs, learn the schema, and query rows on its own, instead of you pasting CSV chunks into a chat window and hoping the model doesn't lose track of a column halfway through. For anyone building agents, it's a cheap way to hand a model a live, structured data source it can actually navigate. It's a small surface, and that's the point. Three tools are enough for a model to orient itself in a dataset it has never seen before, and few enough that they don't crowd out everything else in its tool manifest.

Schema drift gets specific attention, which is the detail that suggests the product has been used in anger rather than just demoed. Spreadsheets are edited by humans, and humans rename columns and insert rows in the middle without telling anyone. PasteSheet watches for that. You can have it alert you when the shape of the sheet changes, or lock the schema so a breaking edit fails loudly instead of quietly feeding your app the wrong field. Anyone who has had a dashboard break because a colleague retitled a header will understand why that feature exists. The two modes suit different temperaments, since alerts fit a project where you'd rather know and then decide for yourself, while the lock fits anything where silently wrong data is worse than a loud, obvious failure.

It's deliberately read-only and never writes back to the source spreadsheet. That narrows what it can do, and it also removes the entire category of accidents where an integration corrupts the one file everybody depends on. The shape that emerges suits pricing tables, changelogs, content collections, directories, config that a non-developer needs to edit, and internal dashboards. It's a poor fit if what you wanted was a real database with writes and relations. This is an easy tool to outgrow on purpose, and it seems comfortable with that. One constraint is worth thinking through before you start, which is that it reads public sheets, so anything served through an endpoint is already readable by anyone holding the link. Paid plans add private endpoints so the API surface itself can be locked down, but the sharing model on the underlying spreadsheet still applies.

Pricing is freemium and clearly aimed at individuals rather than procurement departments. The free tier is genuinely usable, with three endpoints, two thousand requests a month, five hundred rows per endpoint, one tab, a sixty request per minute limit, and MCP access included, and it doesn't ask for a card. Starter runs $9 a month for ten endpoints, fifty thousand requests, five thousand rows, five tabs, and adds private endpoints, column configuration, custom cache settings, workspace MCP, and the schema alerts and lock. Pro is $19 a month for unlimited endpoints, tabs, and rows, three hundred thousand requests, and it layers on full-text search, aggregation, and webhooks. Agency at $49 a month carries the same feature set out to a million requests a month for client work. MCP sits on every tier including the free one, which is a notably un-greedy choice given that it's the part most likely to pull people in.