# 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: 2026-07-11 · Source: * ## Key facts - PasteSheet's MCP server exposes three tools — `list_tabs`, `get_schema` and `query_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](https://modelcontextprotocol.io/specification/2025-06-18)) - 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](https://support.google.com/drive/answer/37603)) - 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](https://pastesheet.com/guides/google-sheets-mcp) server, so your agent retrieves context with `query_rows` — filter by a column, partial-match, or run a [full-text search](https://pastesheet.com/features) — 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: ```json { "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 — $9/month.** For indie makers shipping a real app. - Endpoints: 10 - Requests: 50,000 / month - Rows per endpoint: 5,000 - Tabs per endpoint: 5 - Rate limit: 300 / minute **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](https://modelcontextprotocol.io/specification/2025-06-18) — Model Context Protocol - [Files you can store in Google Drive (size limits)](https://support.google.com/drive/answer/37603) — Google ## Related use cases - [A Google Sheets Data Source for AI Agents](https://pastesheet.com/use-cases/google-sheets-ai-agent-data-source) — 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](https://pastesheet.com/use-cases/google-sheets-chatbot-knowledge-base) — 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](https://pastesheet.com/use-cases/google-sheets-support-agent) — 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](https://pastesheet.com/use-cases/google-sheets-faq-page) — 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. --- [PasteSheet](https://pastesheet.com) turns any Google Sheet into a live REST API and MCP server for AI agents — no backend, no code. Canonical HTML version of this page: