Tea gives your AI application a real Postgres database with a REST API, MCP and permissions already wired up. Your team gets a grid they can edit by hand.
Postgres native · MCP out of the box · Permissions built in
One backend, three ways in
The UI, the REST API and the MCP tools are thin adapters over the same server functions. One implementation, one permission check, no drift between what a human sees and what an agent gets.
For your agents
Paste one link into Claude or ChatGPT and sign in, or point any client at /mcp with a bearer token. Catalogue-driven tools discover every table you add, now and in the future, and anything destructive asks before it runs.
For your product
Every table is instantly live under /api/v1. Filter, sort, search, paginate, import and export, with no endpoint to write. Your app hears about changes as they happen, over a stream or a signed webhook.
For your team
Your backend comes with an admin UI. Edit text, dates, selects, ratings, people, files and relations right where they live — and see the same table as a grid, a kanban board or a form.
Safe to hand to an agent
An agent is only as safe as the credential it carries. In Tea a token can never reach further than the person who minted it, so handing one to a model is not a leap of faith.
Manage, read and write are independent flags, not a ladder. An agent that writes rows need not be able to read them.
Scope a role to every row or only the ones it created. One agent's records stay invisible to the next.
A token does exactly what its owner can do and absolutely nothing they cannot — over REST, over MCP, in the UI.
Collect surveys, requests and sign-ups from people with no account — and no credential for your agents to handle. Responses land in the table your application already queries.
One Tea per company
The mobile app, the internal tool, the customer portal and next month's experiment are apps inside one Tea. Everyone who works there signs in once and reaches whichever ones they have been given.
Tables belong to the company; an app reaches one through a grant its roles carry. So your internal admin tool and your customer app read the same rows on purpose, and nothing has to be synced to itself. Delete an app and its roles, tokens and membership go — the tables stay.
An app publishes a sign-up link and whoever arrives holds exactly the role it nominated. Make that role own-rows-only and each person sees just their own records, off the author every row already records. Sessions, password reset and verification come with it — there is no second auth system to build.
An app with no nominated sign-up role has no sign-up at all, so knowing its name admits nobody. Everyone else arrives by invitation, which can let somebody into several apps at once.
A table you make is a genuine Postgres table, live under /api/v1 and available as an MCP tool the moment it exists. Mint a token, point something at it, and you are building — files go to any S3-compatible bucket and every write is recorded.
curl -H "Authorization: Bearer $TEA_TOKEN" \
https://your-tea.app/api/v1/tables{
"mcpServers": {
"tea": {
"url": "https://your-tea.app/mcp",
"headers": { "Authorization": "Bearer $TEA_TOKEN" }
}
}
}Ship the backend
Tell us where you are going and we will set up your company and its first app.