How a tool goes from your terminal to your team.
ToolDrop is the workspace layer around agent-built apps. Your agent writes the tool; the platform owns everything that makes it real software — sign-in, secrets, storage, hosting, versions, and sharing. Here is the whole machine, end to end.
Your machine
You and your coding agent, building the way you already do.
One deploy
tooldrop deploy validates, builds, and ships a numbered version.
The workspace
One login, a real address, sharing and rollback the team can trust.
four stations · one contract · zero glue code
tooldrop initStart from a scaffold that already knows the rules.
One command creates a working app with the ToolDrop contract built in. It isn't a boilerplate to fight — it's the sanctioned starting point your coding agent can actually follow.
- The SDK is wired in. Identity, Tool Storage, env vars, and logging are one import away in lib/tooldrop — no setup step for your agent to skip.
- The rules are written down. AGENTS.md and CLAUDE.md tell Claude Code or Codex where identity comes from, where state lives, and what never to touch.
- The manifest declares intent. tooldrop.json names the tool and its required env keys, so the workspace knows what the tool needs before anyone relies on it.
- The gateway guard ships by default. proxy.ts rejects any request that didn't come through the workspace gateway — private is the starting state, not a setting.
- refund-console/
- AGENTS.mdthe contract your agent reads first
- CLAUDE.mdsame rules, Claude Code entry point
- tooldrop.jsonmanifest — name, env keys, schedules
- design.mdthe workspace design language
- proxy.tsgateway guard — rejects unsigned traffic
- lib/tooldrop/the SDK — identity, storage, env, logs
- app/a working Next.js app, yours to reshape
claudeBuild with the agent your team already likes.
ToolDrop is not the IDE and not the model. Use Claude Code, Codex, or whatever ships next — locally, the way you already work. The platform's job is to make sure the agent builds against real conventions instead of guessing.
- Docs speak agent. tooldrop docs, llms.txt, and docs.md put the whole contract in your agent's context in one call.
- An MCP server, if you want it. Add the hosted server and your agent gets td_* tools for docs, env keys, storage, and logs while it works.
- Secrets stay tagged, not pasted. Agents look up which env keys exist and what they're for — a database URL is a named, described thing, not a string in a prompt.
- Local dev is one command. tooldrop dev runs the app with workspace identity simulated, so what you see is what teammates get.
the contract, in four lines
- no app auth code — identity comes from the gateway
- no hardcoded secrets — read tagged env vars
- app-owned state goes in td.storage
- run tooldrop validate before deploy
tooldrop deployDeploy a version, not a vibe.
No repos required, no CI to configure, no YAML. The CLI validates the contract, builds the app, checks that the workspace has every declared env key, and publishes a numbered version with your name on it.
- Validation runs first. tooldrop validate catches app-owned auth code, raw secrets, and missing manifest keys before they reach teammates.
- Preflight builds catch breakage. The deploy fails on your machine, not in front of the team.
- Every version is kept whole. Source, owner, message, and timestamp — so history, rollback, and cloning work without git ever entering the picture.
- Risky changes can stage first. On Pro, stage a version in its own environment and share it before making it the live one.
rollback anytimev5add bulk refundsdavelivev4filter by card brandpriyarestorev3first shared versiondaverestore
It lands where the team already is.
The tool appears in the workspace launcher at a stable address, behind the sign-in everyone already has. Sharing is a decision, not a link that escapes.
- One login for every tool. No per-app passwords, no magic links, no “who has access to this?” The workspace is the front door.
- Visibility is explicit. Keep a tool personal, share it with the whole workspace, or invite specific people to just that tool.
- Guests stay lightweight. App-only guests open up to two specific tools for free — occasional collaborators never become billable seats or shadow admins.
- Ownership survives people. Every tool shows who built it, who shipped each version, and can be handed to a new owner intact.
refund console
churn radar
deal desk
on-call rotation
commission tracker
usage explorer
workspace authWhat actually happens when a teammate clicks the tool.
This is the part your agent never has to build — and the reason an agent-built app can be trusted with real work. Every single request walks the same path.
- 1
gatewayGET /refund-console — request hits the ToolDrop gateway, never your app directly
Every tool lives behind the workspace gateway. There is no public origin to leak, guess, or index.
- 2
authworkspace session found — dave@yourteam.com, role: member
Teammates use the sign-in they already have. No session means a workspace login screen, not your tool.
- 3
identityidentity signed and attached to the request
The gateway forwards who is asking on every request, cryptographically signed. Your app verifies it with one SDK call — it never handles passwords, sessions, or cookies.
- 4
appyour route runs — env vars decrypted, td.storage scoped to this tool
Secrets are injected server-side from the encrypted vault. Tool Storage reads and writes are scoped to the app, so tools can't step on each other.
- 5
response200 — rendered for dave, logged for the workspace
The tool responds like any web app, and the workspace keeps the operational trail: logs, errors, and who used what.
The six things you never build again.
Each one is table stakes for "real software" — and none of them is the reason you wanted the tool.
Identity & access
One workspace sign-in gates every tool. Signed identity rides along on each request, so “who is asking” is a fact, not a feature you build.
Env vars & secrets
Credentials live encrypted at the platform level, tagged so agents can find the right keys. Nothing gets pasted into another .env file.
Tool Storage
Saved filters, notes, and small app-created records get a scoped key-value home — instead of a table quietly added to production.
Hosting & address
Every tool gets a stable URL in the workspace. No preview links drifting through Slack, no laptop that must stay awake.
Versions & rollback
Every deploy is kept with source, owner, and message. Roll back in one click, clone a tool, or hand it off without archaeology.
Logs & audit
td.log and td.error stream into per-app logs you can read from the dashboard or CLI, alongside the audit trail of every deploy.
Who does what.
The whole model in one glance: creativity stays with you, discipline lives in the scaffold, and the boring-but-critical parts belong to the platform.
You + your agent
- Decide what the tool does
- Build the UI and the logic
- Query your real systems
- Iterate as the team asks for more
The scaffold
- Ships the SDK and gateway guard
- States the rules in AGENTS.md
- Declares env keys in tooldrop.json
- Keeps agents on the sanctioned path
The platform
- Auth, identity, and sharing
- Encrypted env vars & Tool Storage
- Hosting, versions, and rollback
- Logs, schedules, and webhooks
Four kinds of people, clearly separated.
Access maps to what someone actually does — and only workspace members are paid seats.
Admin
Runs the workspace — members, billing, env vault, and which tools are team-visible.
Builder
Ships tools. Deploys from the CLI, manages app env vars, versions, and rollback.
Member
Uses the workspace — the launcher, team tools, and search. This is the paid seat.
App-only guest
Gets specific tools, not the workspace. Up to two tools each, free on every plan.
Day two, handled too.
Shipping is the easy part. These are the moments — a week or a year later — where a loose app falls apart and a dropped tool doesn't.
Roll back a bad deploy
Every version is kept whole. One click returns the tool to the last good state while you fix forward.
Edit in the browser
Chat with an AI editor against a live draft preview, then publish as a clean new version.
Schedule jobs
Declare schedules in the manifest and the platform calls your cron routes, with run logs kept.
Receive webhooks
Public webhook URLs forward into explicit route handlers, with delivery logs for debugging.
Grow into a database
When td.storage isn't enough, a managed per-app database arrives as a provisioned DATABASE_URL.
Convert an existing app
Already built it? The Convert guide walks agents through adopting the contract route by route.
You've seen the machine. Feed it a tool.
Two workspace members and three live tools are free — enough to run the whole loop on something real this afternoon.