Skip to content

Google Sheet

Share rows and columns — a list, a tracker, a set of figures — that people read, filter, and add to, all at once. Send a link; they open it. And because your agent reads and writes it by code, the same sheet doubles as a tiny shared database or a live data feed behind a small tool — no backend to build.

Reach for it when the thing is structured data a few people keep, or numbers another tool pulls. Skip it when it's flowing prose (a Doc reads better) or you need a real database with rules and scale.

Last verified: 2026-06-07 · Confidence: high on no-account viewing, the share roles, and the read/write API; lower on whether editing strictly needs sign-in (docs are silent).

It allows you to

  • Hand over structured data in one tap. Send a link; they open the whole sheet in any browser, no sign-up, ~5 sec — read it, sort it, filter it. [confirmed]
  • Let a team append to one shared list. Several add rows at once, every change saved, any version restorable — one tracker instead of ten attachments. [confirmed]
  • Have your agent keep it current — or pull from it. Through the Sheets API it reads rows and writes cells by code, so "add each new signup as a row" is one sentence, no copy-paste — the standout a Doc can't match. [confirmed]
  • Expose the numbers as a public feed. Publish-to-web hands out a read-only link any app or agent can fetch, updating when you edit — a tiny data source without a server. [confirmed]
  • Open or close it in a click — just you, named people, your org, or anyone with the link; revoke and the old link stops opening. Details: Who can get in. [confirmed]

Ideal for

  • A public data feed others pull into their own tools — like the EA Funds public grants database: fund, grantee, amount per row, feeding a sheet people copy and an IMPORTDATA() link they pull straight into their own analysis.
  • A shared signup or tracking sheet a team appends to — an ops rota, a workshop attendee list, an event budget where five people add rows live and you never reconcile versions.
  • A tiny database behind a small tool — your agent writes each form response as a row and a one-page site reads them back, so a sheet stands in for a backend you'd otherwise build.

Who can get in

  • You pick the audience. Lock it to just you, name people you invite, open it to your org, or anyone with the link — at view, comment, or edit for each. [confirmed]
  • Let named people in. Add their email, pick a role, they sign in as themselves → Share a Google Sheet. [confirmed]
  • Open it to a link. Viewing needs no account at all [confirmed] — but adding or editing rows reliably needs a free Google account, so plan on collaborators signing in. [unclear] (why — fine print)
  • Cut someone off. Remove a person or flip the link back to restricted, and they're locked out at once. (Anyone who already copied it keeps that copy — true everywhere.) [estimate]

Which rungs it can hold. Just you / named people / org-only / anyone with the link — each at view, comment, or edit. The org-only rung needs a Workspace (work/school) account; a free Gmail jumps from named people straight to anyone with the link. → Who can see it? [confirmed]

Handing data to the host. The sheet is the thing you meant to hand out, so training barely applies. The shared Google stance (ads, the Gemini knob, the Workspace no-training agreement) is on the Google entry → Can you trust the company?. [confirmed]

What you do to set it up

  • Ask: to share what you have, tell Claude Code "share this Google Sheet so anyone with the link can view, and give me the link." To have it maintain the data, "build a Sheet that tracks [X], keep it updated, and share it." [confirmed]

  • One-time, in order:

    1. Set up Claude Code — does the rest, ~10 min once.
    2. A Google account, signed in — ~5 min once; the sign-up is the un-delegable bit.
    3. For the read/write API path only: a Google Cloud project with Sheets credentials, wired once — ~10 min (the API setup, in the fine print). Not needed just to share with people. [confirmed]

  • Rather click? Share → set access → Copy link, ~30 sec; for a public feed, File → Share → Publish to web → pick CSV → Publish → by hand. [confirmed]

What the other person does

  • Just open and read it. Click the link, it opens in any browser — no account, ~5 sec; sort and filter on the spot, works on a phone. The floor-0 case. [confirmed]
  • Add or edit rows: on an Editor (or Commenter) link they sign in with a free Google account — ~1 min, one most people have. Viewing alone never needs one. [unclear] (why — fine print)
  • Point their own tools at it: a published CSV link feeds straight into their own sheet (IMPORTDATA), script, or agent — no account, no auth, ~1–2 min. [confirmed]
  • Take it with them: copy straight out, or File → Download as CSV, Excel, or PDF. [confirmed]
  • Pay: nothing — viewing, editing, and publishing are all free.

Other ways to share

  • People should submit data, not edit a grid? → a form collects clean responses into the sheet — the friendlier front door when contributors shouldn't see or break the raw rows.
  • It's outgrown a shared grid — a real service that computes answers, not just rows? → a live API (or an MCP server for agents) is the heavier home; a sheet is the simple shared-data floor below it.
  • It's prose, not a grid — or a bundle of files? → a Google Doc reads better for words; a Google Drive folder hands over the sheet plus docs, PDFs, and raw files behind one link.

Sources

Good to know

  • Viewing is account-free; adding or editing rows usually isn't — the common surprise. [unclear] (the full why)
  • "Anyone with the link" is not private, and a published CSV is fully public — keep anything sensitive on named-people. → Who can see it? [confirmed]
  • Publishing is not sharing, and work/school accounts can block link-sharing. Both, with sources → the fine print. [unclear]