Retrieve rows from a Google Sheet instead of a vector store
Not every retrieval problem needs embeddings. When your knowledge is a few hundred structured rows — SKUs, policies, specs — an agent can retrieve it more precisely by column than by cosine similarity. PasteSheet exposes the sheet over MCP so query_rows handles filters and full-text search, no vector store required.
Last updated
Key facts
-
PasteSheet's MCP server exposes three tools —
list_tabs,get_schemaandquery_rows— and is read-only by design: an agent can query your sheet but can never modify it. - MCP is an open protocol built on JSON-RPC 2.0. A server exposes Resources, Prompts and Tools to any MCP client — Claude, Cursor, ChatGPT, VS Code and Windsurf all speak it. source
- A Google Sheet is capped at 10 million cells (or 18,278 columns), which is the real ceiling on using one as a database. source
- The corpus size is set by plan, not by embeddings: 500 rows on Free, 5,000 on Starter ($9/mo), and no row cap on Pro ($19/mo) — which is also where full-text retrieval lives.
When columns beat cosine similarity
Retrieval-augmented generation usually means chunking documents into a vector store and hoping cosine similarity surfaces the right passage. But a lot of knowledge is not prose — it is a table: SKUs and specs, policies by plan, error codes and their fixes. For that shape, exact and full-text queries over columns retrieve the right rows more reliably than embeddings, with none of the indexing pipeline.
PasteSheet publishes the sheet as an MCP server, so your agent retrieves context with query_rows — filter by a column, partial-match, or run a full-text search — and drops the matching rows straight into the prompt. No embeddings to compute, no vector store to host, and no re-index when a row changes.
When a sheet beats a vector store
Reach for structured retrieval when the corpus is small and tabular:
- Small to mid corpora — up to a few thousand rows that fit comfortably in a spreadsheet.
- Structured facts where a column filter is more precise than a similarity score.
- Data a non-developer must keep current — an edit is live with no re-embedding step.
- Cases where you want the agent to cite the exact row it retrieved, not a fuzzy chunk.
Connect the corpus
Each endpoint has its own MCP URL. Copy it from the Connect via MCP panel and add it as a custom connector so the agent can retrieve from it:
{
"mcpServers": {
"pastesheet": {
"url": "https://pastesheet.com/mcp/sheets/your-endpoint-id"
}
}
}Read-only, so it is safe to retrieve from
Because the endpoint is read-only by design, it is safe to expose publicly or hand to a teammate: consumers can read and query the data but can never change the sheet. And there is no Google Cloud project, OAuth screen, or service account to set up — you paste a share URL and get a live API.
What it costs
Starter
For indie makers shipping a real app.
- Endpoints
- 10
- Requests / mo
- 50,000
- Row cap
- 5,000
- MCP for AI agents
- Full-text retrieval
- Aggregation for agents
MCP is included on the Free plan. Connect any public endpoint over MCP with no Google Cloud project and no credit card. Private endpoints and the account-wide workspace server need a paid plan (from Starter ($9/mo)) for the keys and OAuth they authenticate with.
Pro adds full-text search and aggregation (count, sum, avg, group_by) that your AI agent can call through query_rows.
Frequently asked questions
Is this a replacement for a vector database?
For small, structured corpora, yes — column filters and full-text search over rows retrieve more precisely than embeddings. For large unstructured prose you still want a vector store; the two approaches solve different problems.
How does the agent retrieve the right rows?
Through query_rows: exact-match filters, partial (contains) matches, full-text search across all columns, sorting, and pagination — so the agent pulls only the rows relevant to the prompt.
Do I have to re-index when the data changes?
No. You edit the sheet and the next query reflects it after the cache refreshes. There are no embeddings to recompute and no index to rebuild.
Can the agent write back to the corpus?
No. Retrieval is read-only. The agent can query and cite rows but cannot modify the sheet, so your source data cannot drift underneath it.
Sources
- Model Context Protocol specification — Model Context Protocol
- Files you can store in Google Drive (size limits) — Google
Related use cases
A Google Sheets Data Source for AI Agents
Give any AI agent read-only access to a Google Sheet over MCP. It can list tabs, read the schema, and query rows in plain English — no glue code, no backend.
A Chatbot Knowledge Base in Google Sheets
Keep your chatbot's Q&A and product facts in a Google Sheet it queries over MCP or REST — accurate answers from live rows, with no vector store to run.
A Support Agent Lookup in Google Sheets
Let a support agent look up orders, policies, and account tiers in a Google Sheet over MCP — read-only, so it answers tickets but never edits a record.
Power an FAQ Page from a Google Sheet
Build a searchable FAQ or help page from a Google Sheet — one row per question and answer. Full-text search over questions via a live, read-only JSON API.
Turn your sheet into an API in minutes
Paste a Google Sheet URL and get a live REST API and MCP server — no backend, no code, free to start.