# Toolcrow guide

Toolcrow hosts small web tools ("drops") that makers build, often with an AI assistant, and share by link. This guide describes how the platform works. Each topic below is a separate page.

- `drops`: **What a drop is**. A drop is a small web tool that Toolcrow hosts at its own link: it runs entirely in the visitor's browser, with storage, AI and feedback provided by Toolcrow.
- `building`: **Building and importing**. How a tool becomes a drop: what can be pasted or uploaded, how each type is run, the size limits, and how a new version replaces the old one.
- `data`: **Saving data**. How a drop keeps data: per visitor in the browser, as submissions the maker collects, or as shared values every visitor sees, plus the exact functions, the Submissions page, Google Sheets, forwarding submissions to a webhook and the limits.
- `ai`: **AI inside a drop**. How a drop can call an AI model without an API key: the functions, which model answers, what the maker can configure and what happens when a limit is reached.
- `feedback`: **Feedback and Nest**. How visitors of a drop send feedback to its maker, where the maker sees it (Nest), what Toolcrow suggests for each report, how visitors see what changed and that their report was fixed, and which emails the maker gets.
- `versions`: **Versions, backups and drafts**. How a drop changes over time: uploading a new version, the backup of the previous version, and drafts that the maker's AI prepares and the maker publishes.
- `connect-your-ai`: **Connecting your own AI**. How a maker connects their own AI assistant (Claude or ChatGPT) to Toolcrow, what that AI can read and do, and what it cannot do.
- `sharing`: **Sharing and access**. Who can open a drop: the three access levels, passwords, email invitations and what open drops add for sharing.
- `security`: **How your tools are protected**. From open to invite only: who can reach a tool at each access level, where its data goes, and the protection that is always on.
- `limits`: **Limits**. All limits in one place: the fixed limits that are the same for everyone, and the limits that depend on the maker's plan.
- `not-supported`: **What Toolcrow does not do**. The boundaries of the platform: what a drop cannot contain or do, and what Toolcrow does not offer.

---

Source: https://www.toolcrow.app/docs/drops
Last updated: 2026-10-28

# What a drop is

A drop is a small web tool that Toolcrow hosts at its own link: it runs entirely in the visitor's browser, with storage, AI and feedback provided by Toolcrow.

## The basics
- A drop is a single web page: an HTML file, a React or Vue component, a static bundle from a ZIP file, or a PDF. See the topic `building` for what can be uploaded.
- A drop has no server of its own. All of its code runs in the visitor's browser. Saving data, calling an AI model and collecting feedback go through services that Toolcrow adds to the page.
- The maker manages each drop on its drop page in the Toolcrow app. The top of the page shows the name, the version ("v3 · updated 2 days ago"), the buttons "Change with your AI" and "Open drop", and two round buttons: Live (turn off, turn on, delete) and how it is shared (Private, Password or Open). Below that, "Needs you" lists what is waiting for the maker (a broken connection, an update from their AI, new reports), followed by the tiles Sharing, Usage and Connections, with a small Submissions tile under Connections about the Toolcrow database: "Saving", "Only what failed" (when the copy is turned off), "Not in use" (a chosen Google Sheet takes its place) or "Not saving" (the tool keeps nothing). Its arrow opens the Submissions page. The arrow on a tile opens its details: Sharing opens a window to change who can open it, send the link and set what visitors can do; Usage and Connections open a side panel (visits over 7 or 30 days, where submissions are saved, AI use per day and reports; and what the tool talks to, split into what Toolcrow runs and what the tool calls itself). In the Connections panel, "Manage" or "Review" opens the panel of one connection, the same one as on the Connections page, with what this drop does with it on top; "Add a connector" (under "Through Toolcrow") connects a service to this drop step by step, and the panel shows where submissions go, with the switch "Keep a copy in Toolcrow" when the drop forwards to a webhook; "How it's built" shows what Toolcrow saw in the code. The submissions themselves are on their own Submissions page (the arrow on the Submissions tile, or "View" in a panel). The drop page has no tabs: everything is on this one overview.
- Drops do not expire. A drop stays online until the maker turns it off or deletes it.

## Where a drop lives
- Every drop is served from its own address on `toolcrow.live`, a random subdomain such as `https://<label>.toolcrow.live`. This is a separate domain from the Toolcrow app (`toolcrow.app`).
- Because each drop has its own address, the browser keeps each drop's storage separate: one drop cannot read another drop's data or the visitor's Toolcrow session.
- Older share links of the form `www.toolcrow.app/<name>/<slug>` forward to the drop's own address.
- Drops are kept out of search engines (`noindex` on every response). A drop is found through its link, not through Google.

## What Toolcrow adds to every drop
Toolcrow injects a small runtime script into every drop page. The maker's own HTML and code run unchanged; the runtime adds:
- **Storage**: `localStorage` and `sessionStorage` keep working and survive refreshes (topic `data`).
- **Shared data**: `Tooldrop.opslaan()` / `Tooldrop.lezen()` for submissions and `window.storage` for shared values (topic `data`).
- **AI**: `window.claude.complete()` and AI calls without an API key (topic `ai`).
- **The "Powered by Toolcrow" badge**: shown on every drop. On open drops it also opens a share panel with a "Report abuse" link.
- **A feedback button**, when the maker turns feedback on for that drop (topic `feedback`).

## A copy of a free tool
Toolcrow's own free tools on `toolcrow.app/tools` have a "Make this your own" button. A signed-in maker who clicks it gets a copy of that tool as a new drop in their own account, and lands on its drop page. Without an account, the button asks to sign in or sign up first (signing up needs an invitation code during the beta).
- The copy is private, like every new drop: only the maker can open it until they change who has access in the Sharing window.
- Only the tool's code is copied. The copy starts without the original's password, connections, feedback, saved data or settings, and is scanned like any new drop.
- The copy belongs to the maker and stands on its own: they can change it like any other drop, for example with their connected AI (topic `connect-your-ai`), and later changes to the original never reach the copy.
- A maker can make 10 copies per day. A second click within a couple of minutes opens the copy that was just made instead of making another one.

## Language of the frame
The badge, the share panel, the feedback button and Toolcrow's own screens around a drop (password, private, turned off, not available) are in English or Dutch. They follow the tool's own language, set in its first HTML tag: `<html lang="nl">` gives a Dutch frame, `<html lang="en">` an English one. Without that, the frame follows the language of the visitor's browser, and otherwise it is English. On the password, private, turned-off and not-available screens the visitor can switch with "NL | EN"; that choice wins and is remembered in their browser for that drop. A pasted React, Vue or JavaScript snippet has no `<html>` tag of its own, so its frame follows the browser. Toward visitors the frame says "tool", not "drop".

## Status of a drop
- **Live**: visitors who have access see the tool.
- **Turned off**: the maker switched it off with the Live button on the drop page. Visitors see an "inactive" page with a button to ask the owner to turn it back on. Turning it on again restores it as it was.
- **Deleted**: the link no longer works. To delete, the maker types the drop's name to confirm.
- **Taken down by Toolcrow**: after an abuse report, Toolcrow can block a drop. Visitors see "This tool is not available". The maker sees the reason on the drop page and cannot turn it back on themselves.
---

Source: https://www.toolcrow.app/docs/building
Last updated: 2026-10-26

# Building and importing

How a tool becomes a drop: what can be pasted or uploaded, how each type is run, the size limits, and how a new version replaces the old one.

## Ways in
On the New drop page (`/new`) the maker drops a file or a whole folder (or clicks "browse files"), or lets a connected AI send the tool. Accepted files: `.html`, `.htm`, `.jsx`, `.tsx`, `.js`, `.mjs`, `.vue`, `.css`, `.txt`, `.zip` and `.pdf`. A dropped folder is packed in the browser and handled like a ZIP. Most tools arrive as code generated by an AI assistant (ChatGPT, Claude, Gemini and similar). A connected AI can also create a drop directly, from one code file or from the files of a static website (topic `connect-your-ai`); on `/new` the maker copies one sentence for the AI, and the page shows the tool as soon as it arrives. The same scan and limits apply; one request from an AI can be about 4 MB.

`/new` works in steps:
1. **Add**: the file, folder or AI.
2. **Check**: the name (taken from the page title or the file name) and what the scan found, in plain words. If the maker already has a drop with the same name, `/new` offers to publish the file as a new version of that drop instead of making a second one. "Put it live" creates the drop, always **Private**.
3. **Connect** (only for a tool that saves submissions): keep the submissions in Toolcrow, or send them to a Google Sheet.
4. **Share**: only the maker, link and password, or anyone with the link. Opening it to anyone asks for a confirmation. A tool that shows submissions back to visitors also gets the switch "Visitors can read submissions", off by default.

After the last step the maker lands on the drop page, where everything can be changed later.

## How each type runs
- **HTML**: served exactly as written. This is the most predictable format.
- **React component (JSX or TSX)**: Toolcrow wraps it in a page that loads React 18 and compiles the component in the browser. Tailwind CSS is available. Imports of npm packages (for example `lucide-react` or `recharts`) are loaded automatically from a CDN. The component that is exported by default, or a component named `App`, is rendered.
- **Vue component**: loaded with Vue 3, and the `App` component is mounted.
- **Plain JavaScript or CSS**: wrapped in a page, with Tailwind CSS available.
- **ZIP file**: a static website bundle (HTML, CSS, JavaScript, images, fonts and similar). It needs an HTML entry page; an `index.html` closest to the top of the ZIP is preferred. Only static file types are kept, other files are skipped.
- **PDF**: shown in a built-in PDF viewer.
- **PowerPoint (.pptx)**: new uploads are no longer accepted (exporting the slides to PDF works). Existing PowerPoint drops keep working.
- **Markdown** is not an input format.

## Language
Toolcrow's frame around a drop (badge, share panel, feedback button, password screen) is in English or Dutch and follows the `lang` on the tool's `<html>` tag. An HTML tool in Dutch that starts with `<html lang="nl">` gets a Dutch frame. React, Vue and plain JavaScript are wrapped in a page without a language, so there the frame follows the visitor's browser (topic `drops`).

## Size limits
- Pasted code: up to 500,000 characters.
- One uploaded code or HTML file: up to 10 MB.
- ZIP: up to 10 MB compressed, at most 60 files, 8 MB unpacked in total, and 5 MB per file.
- PDF: up to 25 MB.

When a connected AI creates a drop, it writes out the whole tool in one message. How long one message can be depends on the AI app and the plan, and is usually well below the limits above. A very large single file, for example one with libraries, fonts or images built in, therefore goes in by uploading it on the New drop page (`/new`), which takes files up to 10 MB. Updates to a large drop work through a connected AI as usual: it reads the code in parts and sends only the changes (topic `connect-your-ai`).

## The scan
Every drop is scanned when it is deployed. "How it's built" on the drop page (open Connections, or the "How it's built" link when the tool talks to no other services) shows the result: what kind of tool it is, its libraries with their versions, what it uses (shared data, AI, outside services, knowledge files, MCP actions, browser storage) and a verdict on whether it will run on Toolcrow. Only the parts the tool uses get a row; the rest is listed on one line. Code that needs a server of its own, such as a Node project with a build step (`package.json`, Vite or webpack config), PHP, Express, Flask or code that starts a web server, is deployed but marked as not able to run, because a drop has no server.

## Automatic adjustment after deploy
After the first deploy of a single-file drop, Toolcrow checks whether the tool is interactive but forgets everything on refresh (data only held in memory). If so, Toolcrow can rewrite only the saving and loading points so the data is kept per visitor in the browser (`localStorage`). The change is checked automatically: when it passes it is applied quietly, otherwise it is offered to the maker on the drop page. It never turns a tool into one that collects or shares data between visitors; that remains the maker's choice (topic `data`).

## New versions
The drop page has an "Upload new version" action, in the Versions panel that opens from the version line at the top. The new code replaces the old code at the same link and the version number goes up by one. The name, description, password and visibility stay as they were. The previous version is kept as a backup (topic `versions`). A connected AI can also prepare a new version as a draft (topic `connect-your-ai`).
---

Source: https://www.toolcrow.app/docs/data
Last updated: 2026-11-02

# Saving data

How a drop keeps data: per visitor in the browser, as submissions the maker collects, or as shared values every visitor sees, plus the exact functions, the Submissions page, Google Sheets, forwarding submissions to a webhook and the limits.

## Three ways a drop can keep data
1. **Private per visitor.** Each visitor keeps their own data on their own device; nobody else sees it. This is plain `localStorage` (or `sessionStorage`). Nothing reaches Toolcrow and nothing shows up on the Submissions page.
2. **Collected submissions.** Every entry (a form, a vote, a sign-up) becomes a row that the maker sees on the Submissions page and can export. This is `Tooldrop.opslaan()`.
3. **Shared for everyone.** One shared state that all visitors see and update, like a shared list, settings or a counter. This is `window.storage` with `shared` set to `true`.

A drop can combine them, for example collect submissions and keep a visitor's draft in `localStorage`. Which one fits depends on what the maker wants visitors to see: Toolcrow never switches a tool from private to collected or shared data on its own.

## Private per visitor: localStorage and sessionStorage
- Inside a drop, `localStorage` and `sessionStorage` work as usual, but Toolcrow backs them with the browser's IndexedDB. Data survives refreshes and is not limited to the usual ~5 MB of browser storage.
- `sessionStorage` is kept as well and is shared between tabs, so it behaves like `localStorage`.
- The data is stored per drop (each drop has its own address) and per device. Values are stored as text.

## Submissions: Tooldrop.opslaan and Tooldrop.lezen
- Toolcrow adds `Tooldrop.opslaan` to every drop, but the drop's own code has to call it, for example when the form is sent. A tool built elsewhere often doesn't. Then what people fill in reaches nobody: the Submissions page stays empty and there is nothing to send to a sheet or another service. When the scan sees a form but the tool keeps nothing at all (no `Tooldrop.opslaan()`, no shared values, no database of its own and nothing in the visitor's browser), the drop page (Needs you and the Connections panel) and Nest say "Your tool has a form, but doesn't save what people send", with a ready-made instruction for the AI behind "Send to your AI" (open it in Claude or ChatGPT, or copy it; "See prompt" shows the text first); a connected AI can propose the change as a new version for the maker to check. Toolcrow never changes the code itself. For a form that only calculates or looks something up, the maker can click "This form doesn't need saving".
- `Tooldrop.opslaan(data)` saves one submission. `data` is a plain object; flat text or number values work best (nested objects and lists are stored as JSON text). It returns a promise of `{ gelukt: true }` or `{ gelukt: false, reden }`.
- The keys of `data` are the field names. They become the column names on the Submissions page, the export and a connected Sheet, exactly as written. Any non-empty text works, including spaces, accents and symbols such as `€`. Names are case-sensitive: `Name` and `name` are two columns. `submittedAt` and `Submitted at` are used for the time of saving; a field with one of those names can get lost or overwrite that time.
- `Tooldrop.lezen()` returns a promise of `{ gelukt: true, rijen: [...] }`, or `{ gelukt: false, reden, rijen: [] }`. Each row is an object with a `submittedAt` field plus the saved fields, in the order they were saved. `submittedAt` is the time of saving in UTC, as ISO text such as `2026-10-15T09:30:00.000Z`. All values come back as text (numbers and objects included), the same way a spreadsheet cell does.
- In the built-in database a row only has the fields that this submission saved. With a connected Sheet every row has every column, with an empty text where a submission had no value.
- Reading submissions back only works when the maker has turned on **"Visitors can read submissions"** in the Sharing window (under "For visitors") or on the Access tab. It is off by default for privacy, and turning it on asks the maker to confirm first, because everyone who can open the drop can then read every submission; while it is off, `lezen()` answers `{ gelukt: false, reden: "niet-publiek", rijen: [] }`. Saving always works.
- While it is on, every visitor can read every field of every submission, including fields the tool itself does not show. With a connected Sheet this is the whole first tab, including columns the maker adds there by hand.
- `Tooldrop.context` holds `{ dropId, titel, access }` for the current drop. `access` is `"open"`, `"password"` or `"private"`: how the drop is shared right now. A tool can use it to decide what to keep in shared storage, for example to share data only while the drop is behind a password or private. Outside Toolcrow (a downloaded file, an AI chat preview) there is no `Tooldrop.context`.

## Shared values: window.storage
`window.storage` is an asynchronous key-value store. Its signature matches the storage API of Claude artifacts, so an artifact built in Claude keeps working on Toolcrow.
- `window.storage.get(key, shared)` returns `{ key, value, shared }`, or `null` when the key does not exist.
- `window.storage.set(key, value, shared)` returns `true` or `false`.
- `window.storage.delete(key, shared)` returns `true` or `false`.
- `window.storage.list(prefix, shared)` returns an array of keys.
- Only when the last argument is exactly `true` is the value shared between all visitors. Without it, the value is stored on the visitor's own device only.
- Values are text. Objects and lists are stored with `JSON.stringify` and read back with `JSON.parse`.
- Shared keys are at most 200 characters, without spaces, slashes or quotes. These rules apply to shared keys only; keys kept on the visitor's device have no rules.
- Shared values can be read and changed by everyone who can open the drop. The "Visitors can read submissions" switch does not apply to them.
- A shared `get` also answers `null` when reading fails, the same as for a key that does not exist. To tell the two apart, a tool can first read a key it knows exists; a tool that reads a value, changes it and writes it back then never replaces shared data it could not read.
- If a drop defines its own `window.storage`, Toolcrow leaves it alone.

## Failing softly
None of these functions throw. `Tooldrop` calls answer with `{ gelukt: false, reden }`; `window.storage` answers `false` or `null`. Common `reden` values:
- `vol`: the store for this drop is full (see limits below). Toolcrow tells the maker (see "When the built-in database is full").
- `te-groot`: one value or submission is too large.
- `drop-limiet`: the daily number of storage calls for this drop is used up; it resets the next day.
- `niet-publiek`: reading submissions is not allowed (see above).
- `geen-data` / `ongeldige-data`: the submission is not a plain object (for example a list or a text), or it cannot be turned into JSON.
- `ongeldige-sleutel`: the key breaks the key rules.
- `niet-verbonden`: the connected Google Sheet is no longer reachable (the maker needs to reconnect Google).
- `schrijffout` / `leesfout`: saving to or reading from the store failed. With a connected Google Sheet this usually means Google refused: the Sheet was deleted or moved to the bin, it is no longer shared with the connected Google account, or Toolcrow was connected without permission to use files (when Google asks, the box for files used with this app has to be ticked). It can also be a short hiccup at Google. When the Sheet is gone or can no longer be edited, Toolcrow notices it by itself and tells the maker (see "Where the data is stored"). The maker can open the Sheet to check it still exists, and reconnect Google from the drop page (Reconnect under Connections) or the Google Sheets page under Connections. Without a connected Sheet, it is a problem on Toolcrow's side; trying again later usually works.
- `unauthorized`: the page's access has run out or changed since it was opened: it has been open for a long time, or the maker has since made the drop private, changed its password or turned it off. Reloading the page fixes it, as long as the visitor still has access.
- `netwerk` / `niet-beschikbaar`: no connection to Toolcrow, or the page is not running as a drop (for example in an AI chat preview).

## When the functions are there
Toolcrow sets up `Tooldrop`, `window.storage`, `window.claude` and the storage behind `localStorage` before any of the page's own code runs, so a script can use them from its first line, without waiting for a load event. In a ZIP upload this holds for the start page; other HTML pages in the ZIP are served as plain files, without these functions.

Outside Toolcrow, for example in the preview inside ChatGPT or Claude, `Tooldrop` does not exist. Code that checks for it and falls back to `localStorage` keeps working in both places.

## Where the data is stored
- By default, submissions and shared values are stored in Toolcrow's built-in database (in the EU), separately for each drop.
- The maker can connect a **Google Sheet** to a drop. They connect a Google account once (on the Google Sheets page under Connections); every drop can then use that connection without signing in again, and each drop picks its own Sheet. On the drop page, Connections → "Add a connector" → Google Sheets lists the maker's Google accounts (or "Sign in with Google" if there is none yet); picking one leads to "Create a new Google Sheet" (named "Submissions · <drop name>") or "Choose an existing sheet", and the last step has "Open in Google Sheets". Toolcrow only gets access to the files it creates or the maker picks, not the whole Drive. From then on the same calls write to that Sheet instead: submissions go to the first tab (column A is "Submitted at", a column is added for each new field) and shared values to a tab named `toolcrow_data` (key, value, updated). The drop's code stays the same.
- "Stop using it in this drop" in the drop's Google panel only takes that drop off Google; the connection stays for the other drops. Deleting the connection on Connections gives the access back to Google straight away, and every drop that used it stores new data in the built-in database again. The rows already in the Sheets stay in the maker's Google Drive.
- "Submissions saved" in the Usage panel on the drop page counts only what is in the built-in database, not the rows in a connected Sheet.
- A connected Sheet always wins. If Google cannot be reached, the call fails softly; it does not fall back to the built-in database.
- If Google stops Toolcrow's access to the Sheet (someone removed Toolcrow from the Google account, the password changed, or Google ended the connection), calls answer `niet-verbonden` and nothing is saved until the maker reconnects. Because the connection belongs to the Google account and not to one drop, every drop that uses it stops at once, and reconnecting once fixes them all. Toolcrow first checks with Google that the connection is really broken, then emails the maker (one email per account at most once a day, listing every tool that broke) and shows it as a Problem at the top of Nest and of "Needs you" on the home page, with a "Reconnect Google" button. Toolcrow keeps no copy of what failed in the meantime: those submissions are lost unless the tool kept its own copy. Toolcrow also checks the connected Sheets once a day, so the maker can often reconnect before anyone submits something.
- If the chosen Sheet itself is no longer usable, Toolcrow tells the maker in the same way: the Sheet was deleted (or the connected Google account can no longer open it), it was moved to the Google Drive trash, or the connected account can only view it, not edit it. Before it says anything, Toolcrow asks Google itself whether the file still exists and can be edited; it asks only that, never for the contents. Google empties its trash after 30 days and saving into a Sheet in the trash often still works until then, so Toolcrow also checks every chosen Sheet once a day, even when nobody uses the drop. The Problem says what happened and what was not saved in the meantime. Its button opens the Connections panel on the drop page to choose another Sheet ("Choose a Sheet"), or the Google Drive trash to restore it ("Open Google Drive trash"). It closes by itself once the Sheet works again, or when another Sheet or Google connection is chosen.
- Toolcrow puts every value in its column by name, so a value never lands under the wrong heading. If the maker renames or deletes a column, or the tool starts sending a new field, the next submission adds a column with that name. If the column cannot be added (for example because the first row is protected), the value is still saved, as `field: value` at the end of the row, in a column without a heading.
- Toolcrow writes every value to the Sheet as plain text, including numbers, dates and "Submitted at". Google does not turn them into numbers or dates, and does not run text that starts with `=` as a formula. To calculate with a column in the Sheet, it has to be converted first, for example with `VALUE()`.
- Reading back from a Sheet gives each cell as the Sheet displays it. Values Toolcrow wrote come back unchanged. Cells the maker typed or edited in the Sheet come back in the Sheet's own format: a date as the Sheet shows it (in the Sheet's locale), a number with its formatting, a formula as its result.
- Rows come back in the order of the Sheet's rows, so sorting the Sheet changes the order `lezen()` returns.
- Toolcrow writes to the Sheet with the maker's own Google account. Google does not send notifications about changes made with your own account, so a notification rule the maker sets in the Sheet does not email them about new submissions. To get a message for each new submission, forward submissions to Slack or Discord (below).

## Webhooks: sending submissions to other apps
The maker can have every new submission also sent to a webhook: an address from a service such as Slack, Discord, Microsoft Teams, Airtable, a HubSpot form, Zapier, Make or n8n that turns it into an action, like a message in a channel, a new row in a table or a new contact. The drop's code stays the same.
- The usual way is to ask the AI connected to Toolcrow (topic `connect-your-ai`), for example "send every new submission of this drop to my Slack channel". The AI creates the webhook in that service if it has access to it (otherwise it explains where to find it) and proposes it to Toolcrow with `propose_forwarding`. The proposal appears on the drop page (Needs you, and under Connections as "Waiting for you") and in Nest as a request; "Review" opens the panel of that connection, and nothing is forwarded until the maker clicks "Approve…" and then confirms the address with "Approve and start sending". The proposal shows the address (the host, such as hooks.slack.com) first; the name and explanation come from the AI. If the AI replaces the proposal in the meantime, the maker sees the new address before anything is approved. Using a webhook from the maker's own list on a drop also asks the maker to confirm the address. "Decline" removes the proposal. In the drop's Connections panel, "Add a connector" goes step by step: pick a service, connect it (one of the maker's own connections for that service, or, if there is none yet, "Let your AI set it up" with a ready-made instruction for that exact service behind "Send to your AI", or "Add it yourself on Connections"), for Google choose the sheet, and a last step that says where submissions now go, with "Send test" or "Open in Google Sheets" and a link to try the tool. The tool's code does not change: it hands each submission to Toolcrow with `Tooldrop.opslaan()`, and Toolcrow sends it on with all the form fields, in the form that service expects.
- The maker can also add a webhook in advance on the Connections page. Under "Your connectors" each service the maker uses has one tile with the number of connections; a red dot means Toolcrow knows something is wrong (the last delivery failed, or Google refused access). Under "Add a connector" each service has a tile that says how it connects ("Webhook": the maker pastes an address from the service; "Sign in": the maker signs in to the service, like Google Sheets); the tile opens the page of that service. "Any webhook" is for a service that is not in the list but can receive a webhook. Each service has its own page (for example `/connections/teams`) with the maker's connections for that service and a table of what it can do. "Add Teams" opens a side panel with the setup steps, the fields (webhook URL and an optional name) and a button that copies a prompt for the AI; once there is a connection, the button reads "Add another". How the connection keeps the address safe is behind the "?" next to "Secret address" at the top. A connection added there is not used by any drop yet: the AI sees it through `list_connections` and proposes it for a drop, or the maker picks it on the drop page (Connections → "Add a connector"). A new connection is only added on the Connections page, never by pasting an address on a drop page. Clicking a connection opens a side panel with Details (where it sends to, how it connects, when it was added), a Used by table (each drop and whether it sends or waits for approval; for Google, which sheet each drop saves to), an Activity table of every delivery in the last 30 days (when, drop, delivered or failed and why, never the content), and Delete (only on the Connections page; on a drop page the panel links to it instead, because deleting stops every drop that uses the connection). A Google connection only shows Reconnect when Google refused access. Opened from a drop page, the same panel starts with "In this drop": what that drop does with the connection (Send test and "Stop using it in this drop" for a webhook; the Sheet it saves to, Change file and "Stop using it in this drop" for Google; Approve or Decline for a proposal from the AI). Toolcrow checks that an address matches the page (a Discord address on the Teams page is refused); "Any webhook" accepts any address.
- Only submissions are forwarded (`Tooldrop.opslaan()`), not shared values from `window.storage`. A drop that never calls `Tooldrop.opslaan()` forwards nothing.
- **Where submissions go.** Without anything connected, Toolcrow keeps every submission (the Submissions page). A chosen Google Sheet replaces that: submissions go only to the Sheet. A webhook comes on top: Toolcrow keeps the submission and also sends it on. The drop page shows this under "Where submissions go".
- **Keep a copy in Toolcrow.** When a drop forwards to a webhook and has no Google Sheet, the maker can turn off the copy Toolcrow keeps. The copy is on by default and handy as a backup, but not required. With the copy off, new submissions only go to the webhook and do not show up on the Submissions page, and the tool cannot read them back with `Tooldrop.lezen()`. Toolcrow still keeps any submission it could not send (the daily limit was reached, the address was refused or the delivery failed), so nothing is lost. Without an approved webhook the switch has no effect and Toolcrow keeps everything.
- Forwarding comes on top of saving. The submission is still stored in the built-in database or the connected Sheet, and it is forwarded even if saving failed. A submission refused by the daily storage call limit is not forwarded.
- Toolcrow recognises the service from the address. Slack and Discord get a short message listing the fields, with a link to the drop's Submissions page; mentions such as @everyone are switched off. Zapier, Make, n8n and any other address get JSON: `{ "event": "submission", "tool": { "name": …, "url": … }, "submitted_at": …, "data": { … } }`, with `data` holding the fields exactly as the tool saved them. Slack workflow webhooks (`hooks.slack.com/triggers/…`) get the fields as flat text values.
- Microsoft Teams: the address comes from the Teams workflow "Send webhook alerts to a channel" (the older Office 365 connectors no longer work). Teams gets a card with the tool name, the fields and a "View in Toolcrow" button. Teams accepts at most 28 KB per message, so very long submissions are shortened.
- Airtable: the address comes from an automation that starts with "When webhook received". Airtable gets one flat object: `{ "event": "submission", "tool": …, "tool_url": …, "submitted_at": …, <your fields> }`. After the first message (use "Send test"), the maker adds a "Create record" step in Airtable and picks which field goes where. Each message counts as an automation run in Airtable.
- HubSpot form: the address is `https://api.hsforms.com/submissions/v3/integration/submit/<portalId>/<formId>` (both IDs are in the form's embed code; no key needed). Each submission becomes a form submission in HubSpot, and so a contact. The drop's field names must match the form's internal field names (for example `email`, `firstname`, `company`): HubSpot refuses the whole submission when a field is not on the form, which shows as HTTP 400 under "Activity" in the webhook's panel. The drop's name and address are sent as the page it came from. A form with reCAPTCHA turned on refuses submissions sent this way. "Send test" creates a test contact with the address `test@toolcrow.app`.
- "Send test" sends one message with `"event": "test"` and the field names of the latest saved submission (with the value "example"), so a Zap or scenario can be set up before the first real submission.
- The address is stored encrypted on Toolcrow's side and never shown again in full, only its domain. Visitors never see it. Toolcrow sends from its own server after answering the visitor, so the tool does not wait, and the service's answer never reaches the browser: `Tooldrop.opslaan()` only reports whether saving worked.
- Toolcrow only sends to public `https` addresses on the standard port, does not follow redirects, and waits at most 5 seconds for an answer. A message larger than 64 KB is not forwarded.
- Up to 10 forwards per visitor and 100 per drop per day (Amsterdam time), plus 10 tests per drop per day. This keeps a drop from flooding the maker's channel or using up the task allowance of a service like Zapier. Above it, submissions are still saved, just not forwarded. To count per visitor without tracking anyone, Toolcrow uses a code made from the IP address and the drop that changes every day and cannot be turned back into the address.
- "Activity" in the panel of a webhook shows its deliveries: when, whether it arrived, and why not (for example HTTP 404 when the webhook was deleted at the service), never the content. Toolcrow keeps this record for 30 days.
- If messages stop arriving, Toolcrow says so in Nest and under Needs you, with the button "Check webhook". That button opens the webhook's panel on the drop page. One line at the top says what went wrong; "Details" next to it shows why it usually happens and what to do. Connections on the drop page shows "Not arriving" next to the webhook for as long as this lasts. Toolcrow does not email about this, because the submissions themselves are saved; only the message is missing, and Toolcrow does not send a failed message again. It shows up when the webhook no longer exists or no longer accepts messages (two failed deliveries in a row), when the service keeps refusing what the tool sends or has an outage (three in a row, or more than half of at least five in a day, spread over at least 15 minutes, so a short hiccup never shows up), or when the address no longer passes Toolcrow's safety check (two in a row, spread over at least 15 minutes). It closes by itself when a delivery arrives (after a refusal or an outage: three in a row, or a week without a failure), when "Send test" works, or when the maker picks another webhook or stops forwarding.
- Toolcrow never sends a test message by itself to check a webhook, because it would land in the maker's channel. It only knows from real deliveries, so a webhook that stopped working on a drop nobody uses shows up with the next submissions. Whether the service does something with a message it accepted is something Toolcrow cannot see.
- When a drop reaches the daily limit of 100 forwards, Nest shows one line that does not count as needing the maker: nothing is lost and forwarding starts again the next day. It closes after a day without hitting the limit. The limit per visitor never shows up: that is the limit doing its work.
- One webhook per drop. A proposal to switch to another webhook leaves the current one working until the maker approves it. "Stop using it in this drop" in the webhook's panel on the drop page stops forwarding for that drop and keeps the webhook for other drops. Removing a webhook on the Connections page stops forwarding for every drop that used it. Deleting a drop stops its forwarding.

## The Submissions page
Each drop has a Submissions page (`/drop/<slug>/data`, opened with "View submissions" in the Usage panel on the drop page). Only the maker can open it. It shows what the built-in database holds for that drop: a table of submissions and a table of shared keys, with search across all columns, sorting, selecting and deleting rows, adding a row by hand, export to CSV or JSON, and "Clear all data". Rows cannot be edited in place: a submission can only be deleted (and a new one added by hand), and a shared value is changed by adding a row with the same key, which overwrites it. When a Sheet is connected, the data lives in the Sheet. When the page is empty, it shows a ready-made prompt to paste into an AI assistant together with the tool, so the tool starts saving its data to Toolcrow.

## Limits per drop
- 50,000 characters per shared value or per submission.
- 1,000 shared keys (overwriting an existing key always works).
- 5,000 submissions.
- 1,000 storage calls per day, reading and writing together, for submissions and shared values. The day runs on Amsterdam time.
- 10 forwards per visitor and 100 per drop per day, when forwarding to a webhook is on.
The first three apply to the built-in database. With a Google Sheet connected, Google's own limits apply instead, such as 50,000 characters per cell. The daily call limit applies in both cases. Private per-visitor storage has none of these limits.

## When the built-in database is full
When a drop's built-in database holds 5,000 submissions (or 1,000 shared keys), new ones are refused with `vol`; overwriting an existing key still works. The first refusal makes it a Problem in Nest and under "Needs you", with an email in the daily bundle (topic `feedback`): it says how many submissions were refused since the store was full. "Make room" opens the Submissions page, where the maker can export what to keep and delete the rest. Connecting a Google Sheet also works: new submissions then go to the Sheet. The Problem closes by itself as soon as there is room again.
---

Source: https://www.toolcrow.app/docs/ai
Last updated: 2026-10-26

# AI inside a drop

How a drop can call an AI model without an API key: the functions, which model answers, what the maker can configure and what happens when a limit is reached.

## How a drop calls AI
- `window.claude.complete(prompt)` returns a promise with the answer as text. This matches the function Claude artifacts use, so an AI artifact built in Claude keeps working on Toolcrow.
- Calls with `fetch` to the Anthropic Messages API (`api.anthropic.com/v1/messages`) or the OpenAI Chat Completions API (`api.openai.com/v1/chat/completions`) are picked up by Toolcrow and answered in the same response format the code expects.
- All of these go through Toolcrow's AI proxy. The maker does not need an API key, and no key is ever placed in the page.

## Which model answers
- Every call is answered by a small, fast OpenAI model that Toolcrow chooses (currently gpt-5.4-nano), whatever model the code asks for.
- Streaming requests get the full answer in one piece.
- An answer is at most 4,096 tokens long. `window.claude.complete()` always uses this maximum. A `fetch` call that sets `max_tokens` (or `max_completion_tokens`) gets that maximum instead. A longer answer is cut off.
- A call that gets no answer from the model within 25 seconds is stopped and fails (see below).
- The maker can set a custom system prompt for a drop on the drop page: Connections, then "How it's built", then "Edit prompt" next to AI. It replaces the system message in the drop's code, so the behaviour can be tuned without a new version, and it works right away for everyone using the tool. "Go back to the prompt from your code" removes it again. If the code has more than one prompt, the custom prompt replaces all of them.

## Limits
- AI calls per drop per day depend on the maker's plan. The "AI credits" tile on the home page shows how many are left today on the maker's busiest tool (the limit counts per tool and resets at midnight, Amsterdam time), and the Usage panel on the drop page shows how much that drop used today; the Usage panel also shows the requests per day over the last 7 or 30 days.
- AI that Toolcrow runs for a drop on the maker's behalf (such as summing up its feedback) counts toward the same daily limit.
- Toolcrow also has an overall daily AI budget and can switch the AI proxy off.
- The day runs on Amsterdam time.

## When a call fails
- When a limit is reached, the call is answered with HTTP status 429 and `{ error: "rate_limited", reden }`, where `reden` is `drop-limiet` (this drop's daily limit), `globaal-budget` (Toolcrow's daily budget) or `uit` (AI switched off).
- When the model does not answer in time or answers with an error, the call is answered with status 502 and `error` set to `upstream_unreachable` or `upstream_error`, without a `reden`.
- When the page's access has run out or changed since it was opened (see `unauthorized` in topic `data`), the call is answered with status 401.
- A `fetch` call gets these responses as they are, so the code can check `res.ok` and `res.status`.
- `window.claude.complete()` rejects with an `Error` whose message is "Toolcrow AI: " followed by the `reden`, for example `Toolcrow AI: drop-limiet`. Without a `reden` (time-out, model error, expired access) the message is `Toolcrow AI: unavailable`. When Toolcrow cannot be reached at all, it rejects with the browser's own network error, without the "Toolcrow AI:" prefix.
- Code that catches these errors can show a friendly message, for example that today's AI limit has been reached.

## Where it works
AI works on open, password-protected and private drops. A drop that is turned off or taken down gets no AI.
---

Source: https://www.toolcrow.app/docs/feedback
Last updated: 2026-11-01

# Feedback and Nest

How visitors of a drop send feedback to its maker, where the maker sees it (Nest), what Toolcrow suggests for each report, how visitors see what changed and that their report was fixed, and which emails the maker gets.

## Feedback from visitors
- The maker turns feedback on per drop in the Sharing window, under "For visitors". It is off by default. On a drop with Password access it switches on directly. On an open drop (anyone with the link) Toolcrow first asks the maker to confirm, because then people they don't know can send feedback too; for a known group, Password access is usually the better fit.
- When it is on, visitors see a "Feedback" button (a speech bubble) in the small white Toolcrow pill in the bottom right corner of the drop, next to "What's new" (see below), the Toolcrow crow and, on open drops, the share button. Visitors can drag the pill elsewhere by its grip. They pick a category (bug, idea, unclear, love or other), write a message or attach screenshots, and can leave their name and email. No account is needed. The pill speaks the drop's language (English or Dutch) and stays out of the way of the drop's own buttons.
- The button never appears on private drops, and the maker does not see it on their own drop.
- Submissions are rate-limited per drop, per hour and per day, against spam.

## What's new and "your report is fixed"
- Next to Feedback, visitors can see a **What's new** button with short notes about what changed in the drop, newest first. A small blue dot on the button means there is a note they have not seen yet. A first-time visitor gets no dot for older notes.
- The notes come from the maker: when publishing a new version, the side panel and "Upload new version" have a field "Note for your visitors". In the side panel it sits right under "What your AI changed" (the explanation for the maker), so it is clear which text visitors see. The maker's AI can suggest the sentence when it prepares a draft; the maker edits it or leaves it empty. Publishing is the approval of the note. Empty means that version gets no note. In the Versions panel of the drop page (click the version in the header) the maker sees the note of each version in a table and can remove one.
- What's new is part of Pro. It is off by default; the maker switches it on per drop in the Sharing window, under "For visitors" ("What's new"). When What's new is still off and the maker publishes with a note, Toolcrow asks once, showing the exact note: "Publish and show to visitors" turns What's new on and publishes, "Publish without the note" publishes the update without a note and leaves What's new off. The button only appears once there is at least one note. Never on private drops.
- The pill only appears when there is something in it. If a drop's code wipes the page after it has loaded, Toolcrow puts the pill back.
- A visitor who sent feedback keeps a receipt in that browser, for that drop only. When the report is fixed (by a published update that closes it, or by "Mark as fixed"), the visitor sees a small card "Fixed: what you reported" with their own words the next time they open the drop, once. In What's new the note of that version is marked "You reported this". Reports closed without a fix show nothing.
- This works without accounts or emails, so it only works in the same browser on the same device. Visitors who clear their browser data or switch devices do not see it.
- "Restore" (topic `versions`) hides the notes of the versions it rolls back, and a report fixed in such a version no longer shows as fixed to the visitor. The same report is open again in Nest, so the maker and the visitor see the same thing.

## What Toolcrow watches, and what it can't see
- Toolcrow watches a connected Google Sheet (the connection and the file, every morning and each time the tool saves to it) a drop's built-in database (whether it is full) and forwarding to a webhook (whether messages arrive). It also notices a form that saves nothing. When something breaks it says so in Nest (below); see the topic `data`.
- Toolcrow doesn't warn yet about errors on the page in visitors' browsers, the libraries a drop loads, or AI requests. No warning about those doesn't mean all is well.
- Toolcrow can't see the services a drop calls itself from the visitor's browser, what is inside a Google Sheet, what visitors keep in their own browser, whether an AI answer is right, or what a service does with a message after it arrives. Things only a person notices, like a button that does nothing, come in through feedback.

## Nest: one place for everything that needs the maker
- Nest (`/nest`, in the sidebar) is the one list of everything around the maker's drops. It has four kinds of items:
  - **Problem**: Toolcrow noticed something broken by itself that loses what people send: a Google connection that stopped working, a connected Google Sheet that was deleted, moved to the trash or can no longer be edited, or a drop whose built-in storage is full (topic `data`). It also tells the maker when messages to a webhook stop arriving; the submissions themselves are saved, so that one is marked "Needs a look" instead of "Broken" and comes without an email. One problem is one item, however often it happens. Toolcrow checks first that the problem is real, so a short hiccup does not show up here.
  - **Feedback**: one item per report from a visitor.
  - **Request**: someone is waiting on the maker, for example a visitor who asked to turn a switched-off drop back on.
  - **Update**: the maker's AI (or Toolcrow) prepared a new version that is waiting to be checked (topic `versions`).
- The list can be filtered on Needs you (exactly what the counter counts), All, Problems, Feedback, Requests and Done, and on one drop. Nest opens on Needs you. From a drop page, "Open in Nest" in the Usage panel opens the list for that drop only, and the home page of the app shows the top 3 under "Needs you", with a link to the rest in Nest. Publishing never happens from the home page: "Check update" opens the drop page, where the maker reviews the update first.
- Selecting an item shows it on the right: what the visitor wrote (with the browser and device it came from, and any screenshots) or what Toolcrow noticed, what Toolcrow suggests, and one next step: "Fix with your AI", "Check update", "Reconnect Google", "Choose a Sheet", "Open Google Drive trash", "Make room", "Check webhook" or "Turn back on".
- Status is simple: an item is open, fixed (with the date, for example "Fixed on Oct 22") or closed without a fix. A report is fixed by publishing an update that fixes it, or by "Mark as fixed". "Dismiss" closes it without a fix; closed items can be reopened.
- The orange counter in the sidebar counts only what needs the maker: bug reports, problems, requests and waiting updates. Ideas, questions and love are in the list but do not count.

## What Toolcrow suggests
- When a report comes in, Toolcrow's AI reads the open reports of that drop together with the drop's code. For each report it writes a short title, its advice in plain words (the likely cause and what to do) and an instruction for the maker's own AI ("Show the prompt Toolcrow wrote").
- Reports with the same cause are grouped: the advice says so, and "This fix also covers" lists the other reports, so one fix can close several.
- The advice is a starting point, not a change: Toolcrow does not edit the drop. The maker's AI makes the change as a draft and the maker publishes it.
- Toolcrow pays for this AI. It runs at most once every few minutes per drop and only on open reports.

## Fixing a report with the maker's own AI
"Fix with your AI" opens a new chat in the maker's connected AI app (Claude or ChatGPT) with a prompt: the drop, the selected reports with their ids, Toolcrow's analysis, and the steps. With the maker's AI connected to Toolcrow (topic `connect-your-ai`), that AI reads the code, prepares a fix as a draft linked to the reports it fixes, and the maker reviews it, confirms which reports it closes and publishes it (topic `versions`). "Copy prompt" copies the same prompt. Toolcrow does not pay for or run the maker's AI.

## Emails
- **When something breaks** (a Google connection is lost, the connected Sheet is gone or in the trash, or the built-in storage is full, so what people send is not being saved), Toolcrow emails right away: one email per account, at most once a day, listing every tool that broke. This one cannot be turned off.
- **The summary email**: one email for all drops, weekly (the default) or daily, and only when new feedback came in since the last one. It lists what is still broken, the new feedback (with Toolcrow's title for each report), and what is waiting on the maker. Every line links to the item in Nest.
- There are no other feedback emails: no email per bug, no email when the maker's AI prepared an update, and no email per request. Those are in Nest and in the summary.
- The summary is set under Account, Notifications: weekly, daily or off, which drops are included, and "Send me a test summary".
- **What's new**: also under Account, Notifications, a switch for an email when Toolcrow itself ships something new (the items on the What's new page). It is off until the maker turns it on, and every such email has a link to turn it off again without signing in.
---

Source: https://www.toolcrow.app/docs/versions
Last updated: 2026-11-06

# Versions, backups and drafts

How a drop changes over time: uploading a new version, the backup of the previous version, and drafts that the maker's AI prepares and the maker publishes.

## New versions
- "Upload new version" on the drop page replaces the code at the same link. The version number goes up by one (v1, v2, v3 and so on).
- Name, description, password, visibility and stored data stay as they are. Data saved by visitors is not part of a version.

## The version list
- Clicking the version line at the top of the drop page ("v3 · updated …") opens the Versions panel: every version of the drop, newest first, with the date, who made it ("Uploaded by you", "Update from your AI", "Restored from version 2", "Adjusted by Toolcrow"), what the AI wrote about an update, and how many reports it solved.
- Toolcrow keeps the code of the latest versions, the live one included. How many depends on the plan; the panel says the number. Older versions stay in the list as "Code not kept". Versions from before the list existed (November 2026) show that line too. When a plan keeps fewer versions (for example after a downgrade), the code of the older ones is removed within a day, without waiting for a new version.
- **View** and **Restore** are on every version whose code is kept. View opens that version in a new tab, as a private link for the maker that is valid for a short time; nothing changes. Restore makes it the live version again (see "Restoring" below).
- The bar at the top of the maker's own view of a tool shows the same list under the version number, with a link to the Versions panel.
- **Delete code**: the maker can delete the saved code of any version except the live one, for example when it held a key or personal data that was removed later. The code is removed everywhere Toolcrow kept it, including the backup if it is that version. The version stays in the list as "Code deleted by you". To remove something from the live version, upload a new version first.

## The backup and restoring
- The previous version is the backup.
- "Restore" on any kept version makes it the live version again. The current version becomes the backup, so a restore can itself be undone, and the restored code is saved as a new version with a new number ("Restored from version 2"). Restoring the backup swaps the two.
- Viewing and restoring older versions is not possible for a drop that Toolcrow took down, or for an account that can no longer publish (the maker can email hello@toolcrow.app).
- A restore reopens feedback whose fix was in a version it rolls back: the report is open again in Nest with the line "Reopened: the fix in v5 was rolled back", and the drop page says how many reports were reopened. Reports marked as fixed by hand (not linked to a version) stay closed. Restoring the version with the fix again does not close them by itself; the maker marks them as fixed.

## Downloading the code
- The code of a drop belongs to its maker. "Download code" in the Versions panel (under the live version) downloads the code of the live version, so the maker can keep a copy or run the tool somewhere else.
- What comes out: a single HTML file stays one `.html` file. A React component, a Vue component or plain JavaScript comes as a `.zip` with the code as it was uploaded (`source.jsx`, `source.vue` or `source.js`) and `index.html`, the page Toolcrow made of it, which opens in a browser as it is. A drop made of several files (an uploaded website, a PDF) comes as a `.zip` with all its files and folders.
- It is the maker's own code: what Toolcrow adds around a drop while serving it (the "Powered by Toolcrow" badge, the feedback button, sharing and the storage helpers) is not in the download. A change in the code itself, such as a published update or an automatic adjustment after deploy (topic `building`), is in it, because that is the live version.
- Only the owner of a drop can download its code; anyone else gets a refusal. A drop that Toolcrow took down cannot be downloaded (the maker can email hello@toolcrow.app).
- Data that visitors saved is not part of the code. It is exported separately on the Submissions page, as CSV or JSON (topic `data`).
- Outside Toolcrow, what the code gets from Toolcrow stops working: `Tooldrop.opslaan()`, shared `window.storage`, `Tooldrop.context` and AI calls through Toolcrow (topics `data` and `ai`). Everything else runs as it does in a browser; a tool that only saves on the visitor's own device keeps doing so.

## Drafts (updates) from the maker's AI or from Toolcrow
- With an AI connected to Toolcrow (topic `connect-your-ai`), the AI can prepare an improved version of a drop as a **draft**. A draft is never live by itself.
- Toolcrow can also prepare a draft itself, for example when a tool loses its data on refresh. The side panel then says "Update from Toolcrow" instead of "Update from your AI".
- When the draft came from an AI app connected by signing in, the drop page names that app: "ChatGPT prepared an update" and "Update from ChatGPT" (or Claude, or Claude Code). The name comes from where that connection sends the maker back after signing in, not from what the AI says about itself. A draft from the personal link says "your AI", because Toolcrow does not know which app uses that link.
- Each drop has at most one open draft. A new proposal from the maker's AI replaces it (also a draft from Toolcrow; the AI's response then says so), or the AI builds on it in rounds; the drop page shows how many rounds the AI has made. Toolcrow never replaces a draft from the maker's AI.
- On the drop page the maker sees "Update ready" and a **Check update** button. It opens a side panel that shows what changed and why (the code changes stay folded away until asked for), and the maker can open "Try it" (a private test link that is valid for a short time), and then chooses **Publish** or **Discard**. While the maker's AI is reading the tool's feedback or code, the drop page says "Your AI is working on an update", and the update appears there by itself, without reloading. There is no email for a draft from their AI: the maker asked for it, and it also shows in Nest.
- "Try it" runs the draft the way the live tool runs: shared `window.storage`, `Tooldrop.opslaan()`, `Tooldrop.context` and AI calls through Toolcrow all work (topics `data` and `ai`). That means the draft uses the **real data of the live tool**. What the maker saves while trying a draft is saved for real, shows up for everyone and is forwarded like any other submission (topic `data`). A notice at the top of the draft says so. Only the maker can open this test link; the badge, the feedback button and What's new are not shown there, and opening it does not count as a visit.
- Publish turns the draft into the next version, with the current version kept as the backup. If the live version changed after the draft was made, publishing is refused, so nothing is overwritten by accident.

## Closing feedback with a new version
- A draft can be linked to the feedback items it fixes. The side panel lists them under "Fixes these N reports", each with a checkbox that is on by default. When building on a draft in rounds, the links of earlier rounds are kept.
- Publish marks only the checked items as done, with the version that fixed them, and confirms how many it closed ("3 reports closed in v5"). Unchecked items stay open. Discarding a draft leaves all its items open.
- "Upload new version" asks "Does this version fix any open reports?" with the same checkboxes, off by default, so feedback can also be closed without a connected AI.
- In Nest an open report that is linked to a waiting draft shows "Fix ready", and its next step becomes "Check update", which opens the drop page with the draft. A fixed report shows the date of the version it was fixed in. A draft that is not linked to any open report is its own item in Nest ("Update").
- A draft can change at most 20 files, each up to 10 MB.

## Telling visitors what changed
- Each new version can carry one short note for the people who use the drop, shown under "What's new" in the drop (topic `feedback`). The field "Note for people who use this drop" is in the update side panel and in "Upload new version". Empty means no note.
- The maker's AI can suggest the note when it prepares a draft (`whats_new`, one sentence in the language of the drop, no code or internal details); the maker sees it in the field and can change it before publishing.
- A restore hides the notes of the versions it rolls back, and shows the note of the restored version again.
---

Source: https://www.toolcrow.app/docs/connect-your-ai
Last updated: 2026-11-02

# Connecting your own AI

How a maker connects their own AI assistant (Claude or ChatGPT) to Toolcrow, what that AI can read and do, and what it cannot do.

## The connection
- The connection uses MCP (Model Context Protocol), the standard way AI assistants connect to outside services. There are two ways to connect; both give the same access to all of the maker's own drops.
- **Sign in (the usual way).** In Claude (Settings, Connectors), the maker adds a custom connector with the URL `https://www.toolcrow.app/mcp`. Claude sends the maker to Toolcrow to sign in, and Toolcrow shows which app asks for access, what it can do and where the maker goes back to. The connection starts after "Allow access".
- **Once per Claude account.** The connector belongs to the maker's Claude account, so after adding it once Toolcrow works in Claude chat and in Claude Code, on claude.ai and in the Claude desktop app. A connector added on claude.ai shows up in a desktop app that was already open after the app restarts.
- **Claude Code in a terminal.** Claude Code on the command line can also add Toolcrow on its own: `claude mcp add --transport http toolcrow https://www.toolcrow.app/mcp`, then `/mcp` in Claude Code to sign in.
- **ChatGPT.** On chatgpt.com, the maker opens Plugins (`chatgpt.com/plugins`), chooses the plus button and "Add custom MCP server", gives it the name Toolcrow, pastes `https://www.toolcrow.app/mcp` as the server URL, keeps OAuth as the authentication, confirms OpenAI's warning and chooses "Create as a plugin". ChatGPT then sends the maker to Toolcrow to sign in and "Allow access". In a new conversation, typing `@` and choosing Toolcrow uses it. Whether custom MCP servers are available depends on the ChatGPT plan and, in a workspace, on what the admin allows; OpenAI's own help pages have the details. After a Toolcrow update, "Refresh" on the plugin in ChatGPT loads the new list of tools.
- **Which apps can connect.** Toolcrow accepts Claude (claude.ai and claude.com), ChatGPT (chatgpt.com) and apps on the maker's own computer, such as Claude Code. The name Toolcrow shows for a connected app (on the sign-in screen and on the Connections page) comes from where the app sends the maker back after "Allow access", not from the name the app gives itself: chatgpt.com is ChatGPT, claude.ai is Claude, an app on the maker's computer is Claude Code. Other AI apps can use the personal link.
- The connected app gets its own Toolcrow key that only works for this connection: it cannot sign in to Toolcrow, change the account or reach the database. Toolcrow stores only a fingerprint of it. The key renews itself while it is in use; after 90 days without use, the AI app asks the maker to sign in again.
- The Connections page (`/connections`) starts with "Your AI": a Claude tile, a ChatGPT tile and an "Other AI app" tile, all leading to its own page (`/connections/ai`). There the connected AI apps (each with its name and logo) and the personal link are a list. "Connect your AI" (or "Add AI") opens a side panel with a choice between Claude and ChatGPT and the steps for that app (the address to paste); for Claude, "Other ways to connect" holds the Claude Code terminal command. "Other AI app" opens the steps for an app that cannot sign in (create a personal link, add it in the app as an MCP server). "What it can do" is a table of the Toolcrow MCP tools exactly as the AI sees them, with per tool whether it reads, creates a private drop, or proposes a change the maker approves. Opening a connected app shows when it was connected and last used, and "Disconnect", which stops that app straight away after a confirmation.
- **Personal link.** For an AI app that cannot sign in, the maker can instead create a personal connection URL (in "Connect your AI": "Use a personal link"). The secret is part of that URL, so it works without signing in: whoever has the URL has the same access. It is shown once; Toolcrow stores only a fingerprint of it, so a lost URL is replaced by generating a new one. Each maker has one personal link. "Regenerate" makes a new URL and stops the old one; "Revoke" stops it.
- The AI that is connected is the maker's own (for example their Claude or ChatGPT account). Toolcrow does not run or pay for it.

## What the connected AI can do
Every tool that works on one drop takes the drop's slug (as `list_drops` returns it) or the drop's address: its `toolcrow.live` link or its toolcrow.app link. It only ever finds the maker's own drops.

- `get_toolcrow_guide`: read this guide, as a table of contents or one topic at a time.
- `list_drops`: list the maker's drops, with status, visibility and the number of feedback items, plus the email address of the Toolcrow account the connection belongs to.
- `list_feedback`: read the feedback for one drop, each item with an id, the message, the category, whether the visitor left contact details (not the name or email itself), its status, the version it was fixed in and whether it is already linked to the waiting draft. By default it returns only open items; a filter returns closed items or all.
- `get_drop_code`: read a drop's code, whole or in parts, search in it, or read the open draft instead of the live version.
- `propose_new_version`: save an improved version as a draft, with an explanation for the maker and the ids of the feedback items it fixes (`feedback_ids`). Ids that do not belong to the drop are ignored and listed in the response. Proposing replaces an open draft, also one prepared by Toolcrow itself (the response says so), unless the AI builds on that draft; then the linked feedback items of all rounds are kept together.
- `create_drop`: create a new drop in the maker's account, from one file (`code`: HTML, a React or Vue component, or plain JavaScript) or from the files of a static website (`files`, with an HTML start page). The same scan runs as on the New drop page (topic `building`), and the response gives the verdict with a short explanation and the links to the drop page. A drop created this way is always private (topic `sharing`); at most 20 drops per 24 hours are created through a connected AI.
- `propose_forwarding`: propose a webhook for a drop, so that every new submission is also sent to that webhook URL (Slack, Discord, Microsoft Teams, Airtable, a HubSpot form, Zapier, Make, n8n or another service). It is a proposal: nothing is sent until the maker approves it in Toolcrow (topic `data`). A new proposal replaces a pending one; the webhook that is already forwarding keeps working until the maker approves the new one.
- `list_connections`: see the connectors the maker added on the Connections page (each webhook with its id, service, label, domain, actions, last delivery and the drops that use it; each Google connector with its id, account, status and the drops and files it serves), plus every connector Toolcrow supports with its actions and setup steps. To use a webhook connector the maker already added, `propose_forwarding` takes its `connection_id` instead of a URL. A Google connector is picked per drop by the maker in Toolcrow, together with the sheet; the AI cannot attach it.
- `get_forwarding`: see whether a drop has a webhook, to which service and domain (never the full URL), whether a proposal is waiting, and the latest deliveries with their outcome and HTTP status (never their content).

## Good to know
- **One account per connection.** The AI sees the drops of the Toolcrow account the maker signed in with when connecting; `list_drops` shows which account that is. To use another account, disconnect Toolcrow in the AI app and connect again, and choose "Use another account" on Toolcrow's sign-in screen.
- **Only allow what you started.** Toolcrow's sign-in screen names the app and where the maker goes back to. Someone could send a maker a link that opens this screen for a connection the sender started in their own Claude or ChatGPT account; allowing it would give the sender's AI access to the maker's drops. The screen therefore says to only allow access when the maker just added Toolcrow in that app themselves. A connection the maker does not recognise can be stopped with "Disconnect" on the Connections page.
- **Removing Toolcrow in Claude or ChatGPT.** Toolcrow has the standard address where an AI app can hand its key back (OAuth token revocation). Claude Code uses it when the maker signs out of Toolcrow there (`claude mcp logout toolcrow`, or "Clear authentication" in `/mcp`): the app then disappears from the Connections page straight away. Removing the connector in Claude's settings, or with `claude mcp remove`, does not tell Toolcrow, so the app keeps its access on the Connections page until the maker clicks "Disconnect" there too (or until it goes 90 days unused). The same goes for removing Toolcrow in ChatGPT: OpenAI does not document that ChatGPT hands the key back, so disconnecting it on the Connections page too is the safe way.
- **Very large tools.** With `create_drop` the AI writes out the whole tool in one message, and how long that message can be depends on the AI app and the plan. A single file with libraries, fonts or images built in can be longer than that. The maker then uploads the file on the New drop page (`/new`), up to 10 MB, and the AI can work on it from there: it reads a large drop in parts and sends only the changes (`propose_new_version`).
- **New tools after an update.** An AI app remembers the list of tools from the moment it connected. When Toolcrow adds a tool, an AI that was connected before may say it does not have it, even though this guide mentions it. Disconnecting and connecting Toolcrow again in the AI app (in Claude: Settings, Connectors) and starting a new conversation loads the current list. In ChatGPT, "Refresh" on the Toolcrow plugin does the same.
- **Claude asks permission before it saves something.** The first time Claude wants to use a Toolcrow tool that saves something (such as `propose_new_version`), claude.ai asks the maker for permission in the chat. Until the maker answers, Claude waits, so the update does not appear in Toolcrow. Choosing "Always allow" avoids the wait. That is safe because every update stays a draft until the maker publishes it, and a webhook proposal only starts sending after the maker approves it in Toolcrow.
- **Both Claude and ChatGPT connected.** Both have the same access, and Toolcrow never sends anything to an AI by itself: the AI app the maker is chatting in does the work. Buttons that open a chat with a prompt ("Change with your AI" on the drop page, "Fix with your AI" in Nest, and on the New drop page) open the maker's default AI, with a small arrow next to it to open the other one instead; with one app connected they open that one. The default is set on the Connections page, below the AI apps, or under Connections, Your AI ("Default AI": Last used, Claude or ChatGPT), and the default app is marked "Default" there; "Last used" opens the app that was used most recently. When a second AI app is connected, Toolcrow asks once, the next time the maker is in Toolcrow, whether it should become the default. A drop has one open draft: when the other AI proposes a change too, its draft replaces the first one (or builds on it), and the drop page names the app that prepared the current draft.
- **Opening ChatGPT with a prompt.** "Open in ChatGPT" puts the prompt in the link (`chatgpt.com/?q=…`), as "Open in Claude" does for claude.ai. ChatGPT opens with the prompt filled in and waits until the maker sends it, so the maker can still change it first. OpenAI does not document this link, so it could change; the prompt is also copied, so pasting it always works.
- **The AI may ask you to confirm first.** Before it proposes a webhook, an AI assistant can ask the maker to confirm in the chat that submissions may go to that address. That check belongs to the AI assistant itself, not to Toolcrow. Toolcrow then still asks the maker to approve the webhook before anything is sent.

## What it cannot do
- It only ever sees the connected maker's own drops. Drops of other makers, and deleted drops, do not exist for it.
- It cannot publish or share. A new drop it creates is private, so only the maker can open it until they choose who has access. A proposal for an existing drop is always a draft that the maker tests and then publishes or discards on the drop page (topic `versions`).
- It cannot delete drops or change settings, visibility, passwords or stored data, and cannot read the data visitors saved. A webhook only starts sending after the maker approves the AI's proposal, and the AI cannot turn a webhook off or send a test; the maker does that on the drop page.

## Data that reaches the AI
Whatever the AI reads through these tools (drop names, code and feedback messages) is sent to the maker's own AI assistant and handled under that assistant's terms. Names and email addresses that visitors left with their feedback are not sent to the AI; the maker sees them in Toolcrow only.
---

Source: https://www.toolcrow.app/docs/sharing
Last updated: 2026-10-26

# Sharing and access

Who can open a drop: the three access levels, passwords, email invitations and what open drops add for sharing.

## Three access levels
The maker sets the access level in the Sharing window of the drop page (the Sharing tile, or the round button that says Private, Password or Open). Opening a drop up further (from private to password, or to open for anyone with the link) asks the maker to confirm first; making it more closed never does.
- **Private**: only the maker, signed in to Toolcrow, can open the drop.
- **Password**: anyone with the link and the password can open it.
- **Open**: anyone with the link can open it.

New drops start as private, or with a password when the maker sets one while creating the drop. A drop created by a connected AI always starts as private. Visitors never need a Toolcrow account. Toolcrow has no visitor logins or per-person access lists: the link, the password and the private setting are the locks. How each level is enforced is in the topic `security`.

## Passwords
- A password is 8 to 200 characters. Toolcrow stores it securely. The drop page does not load it until the maker clicks Show in the Sharing window.
- After entering the right password, a visitor stays unlocked in that browser for 12 hours.
- Repeated wrong guesses are slowed down.
- The maker never needs the password for their own drop.
- Changing the password, or making a drop private, locks out everyone who had unlocked it before.

## Email invitations
- From the Sharing window ("Send the link") the maker can send the drop to people by email. The email contains the link, for a password-protected drop the password, and an optional short note from the maker.
- An invitation does not give extra access: it is a convenient way to send the link, and the list shows who it was sent to.
- Invitations cannot be sent for private or turned-off drops.
- Two numbers depend on the maker's plan: how many email addresses can be on one drop's invitation list, and how many invitation emails the maker can send in 24 hours (counted over all of their drops). Removing an address from the list frees a place on it; the link keeps working for that person.
- These numbers only limit the invitation list. They do not limit how many people can open the drop: that is anyone with the link (and the password, if there is one).

## Open drops
- Open drops show a share panel in the "Powered by Toolcrow" badge, and link previews (title and image) when the link is posted in chats or social media.
- The share panel has a "Report abuse" link. Anyone can report a drop at `toolcrow.app/report`.

## Visit counts
- The maker sees how many visits the drop got, in the Usage panel on the drop page. Toolcrow also notes which site a visit came from (only the site name); the drop page does not show that at the moment. This works the same for open, password-protected and private drops.
- Only people are counted. A visit counts once the visitor actually does something in the tool (moves the mouse over it, clicks, types, scrolls or touches the screen) after a few seconds on the page. Search engines, link previews in chats, AI assistants that read the page, uptime checkers and scripts are never counted, and neither is the maker while signed in to Toolcrow.
- A visitor who opens the tool and leaves without moving the mouse over it or touching it is therefore not counted either. Pressing only keyboard shortcuts (such as closing the tab) does not count. The numbers are a little lower than every page load, but every visit in them is a person.
- Toolcrow counts visits, not people: someone who opens the tool three times counts three times. Days run on Amsterdam time.
- Until 21 October 2026 every page load counted, so totals from before that date may include some automated visits.
- On the drop page, the "?" next to each number in Usage explains how that number is counted.
- No other analytics run on a drop: Toolcrow's own measurement tools stay off the pages where tools are served.

## Data and access
The access level also protects the data functions: a visitor who cannot open the drop cannot save or read its shared data. Shared values (topic `data`) are visible to everyone who can open the drop.
---

Source: https://www.toolcrow.app/docs/security
Last updated: 2026-10-26

# How your tools are protected

From open to invite only: who can reach a tool at each access level, where its data goes, and the protection that is always on.


## Never found through search
Many hosts let search engines list a page, so anyone can find it and use all of it. Toolcrow never does this. Every response from a tool's address sends the HTTP header `X-Robots-Tag: noindex, nofollow`: the HTML, the password and private screens, every file, and the redirect that leads there. Because it is a header, it also covers files that are not HTML and pages that never load the tool's code. Tool addresses are not in the sitemap. A free tool's landing page on `/tools` can be indexed; the tool inside it still sends noindex.

## Level 1: Open
Anyone with the link can open the tool.
- Each tool lives on its own address on `toolcrow.live`, made from 16 cryptographically random bytes (26 characters, 128 bits). Nobody finds it by guessing or searching.
- Share links on toolcrow.app redirect there and carry a random 22-character slug.
- Link previews (name and description) and the share panel only appear on Open tools.

## Level 2: Password
Anyone with the link and the password can open the tool.
- The check runs on the server before the tool's code is fetched. Without the password, the visitor only gets the password screen; the tool's other files answer 404.
- The password (8 to 200 characters) is checked with bcrypt against a hash only the server can read. A copy encrypted with AES-256-GCM lets the maker see the password again; it is decrypted only on the server.
- After the right password, that browser gets a pass for 12 hours: an HMAC-SHA256 signed cookie (`HttpOnly; Secure; SameSite=Lax`) that only works on that tool's address and is tied to the current password. A new password ends every pass at once.
- Repeated wrong guesses are counted per network and per tool, and lock the door for a while.
- The maker never needs the password for their own tool.

## Level 3: Private
Only the maker, signed in to Toolcrow, can open the tool. New tools start here.
- The Toolcrow session stays on toolcrow.app; `toolcrow.live` is a different site and cannot read it. Opening a tool from Toolcrow hands over a signed token that lasts 60 seconds. The tool's address swaps it for a 12-hour owner cookie and redirects, so the token leaves the address bar and history.
- Ownership (the maker or the workspace that owns the tool) is checked on every request. Toolcrow never sets account cookies on `toolcrow.live`.
- Everyone else sees a "this tool is private" screen.

## Level 4: Invite only (coming soon)
Only people on the maker's guest list, each signing in with their own account. This is built as portals and not switched on yet. Guests get an "end user" role that is set on the server inside their signed login, cannot reach any maker page, and are checked against the guest list on every visit. Today, sharing by email only sends an invitation with the link (and the password for a password tool); it does not give access on its own (topic `sharing`).

## Where the data goes
The access level decides who can reach a tool's data; the tool decides where it goes (topic `data`).
- **Only on the visitor's device**: `localStorage` and similar storage stay in that visitor's browser, separate for every tool's address. Nobody else sees it.
- **Sent to the maker**: entries from `Tooldrop.opslaan()` land on the Submissions page or in the maker's Google Sheet. Visitors cannot read them back unless the maker switches on "Visitors can read submissions".
- **Shared by everyone inside**: `window.storage` with `shared: true` is read and written by everyone who can open the tool.

Every data call carries a pass the server only hands out after the door, valid for 12 hours and signed against the tool's current access. A new password, switching to private, switching the tool off or a takedown cancels every pass. The tool never talks to the database directly; calls are only accepted from tool addresses. Limits per tool: 1,000 data calls a day, 5,000 entries, 1,000 shared keys and 50,000 characters per value.

## Always on
- Never in search engines, not even Open tools.
- An address nobody can guess.
- Every tool in its own space: its storage and cookies cannot reach other tools or the maker's Toolcrow account.
- Secret keys stay on the server: AI keys and Google connections are never sent to the tool.
- Other websites cannot show a tool inside their own page.
- A maker can switch a tool off, and Toolcrow can block a tool that is reported for abuse.
---

Source: https://www.toolcrow.app/docs/limits
Last updated: 2026-10-26

# Limits

All limits in one place: the fixed limits that are the same for everyone, and the limits that depend on the maker's plan.

## Fixed limits
Uploading (topic `building`):
- Code sent as text (by a connected AI, or a code file read in the browser): 500,000 characters. A bigger single file is uploaded as a file.
- One uploaded code or HTML file: 10 MB.
- ZIP: 10 MB compressed, 60 files, 8 MB unpacked, 5 MB per file.
- PDF: 25 MB.

Shared data per drop (topic `data`):
- 50,000 characters per shared value or submission.
- 1,000 shared keys.
- 5,000 submissions.
- 1,000 storage calls per day (Amsterdam time).

Forwarding submissions to a webhook (topic `data`):
- 10 forwards per visitor and 100 per drop per day (Amsterdam time); above that, submissions are still saved.
- 10 tests per drop per day.
- Messages up to 64 KB; Toolcrow waits 5 seconds for the service to answer.

AI inside a drop (topic `ai`):
- Answers up to 4,096 tokens, unless a `fetch` call sets its own maximum.
- A call without an answer after 25 seconds is stopped.

Other:
- Drop passwords: 8 to 200 characters.
- Drafts from a connected AI: 20 files per draft, 10 MB per file.
- New drops created by a connected AI: 20 per 24 hours, and one request of about 4 MB (the code and file limits from uploading apply as well). The AI writes the whole tool out in that request, and how much it can write at once depends on the AI app; a very large file goes in by uploading it on the New drop page instead (topic `building`).
- Copies of free tools ("Make this your own", topic `drops`): 10 per maker per day (Amsterdam time).
- Visitor feedback is rate-limited per drop, per hour and per day.

## When a drop hits a limit

AI calls and shared storage answer a limit in one fixed shape, so a tool can show a clear message instead of breaking:

```json
{ "code": "usage_limit", "resource": "ai", "reason": "daily_limit", "retryAt": "2026-10-21T22:00:00.000Z" }
```

- `resource`: `ai` (AI calls), `storage_calls` (calls to shared storage per day) or `storage_space` (stored data).
- `reason`: `daily_limit` (try again after `retryAt`, the next midnight in Amsterdam), `paused` (AI is switched off for now), `full` (the drop holds the maximum number of records) or `too_large` (one value is too big).
- `retryAt` is `null` when waiting does not help.

With `window.claude.complete()` the fields are on the error. With `Tooldrop.opslaan()`, `Tooldrop.lezen()` and shared `window.storage` they are on the answer (`gelukt: false`). With `fetch` to an AI API they are in the JSON body of the 429 response.

```js
try {
  const answer = await window.claude.complete(prompt)
} catch (err) {
  if (err.code === 'usage_limit') {
    const when = err.retryAt ? new Date(err.retryAt).toLocaleTimeString() : 'later'
    showMessage('The AI is busy for today. Try again after ' + when + '.')
  }
}

const r = await Tooldrop.opslaan({ name, email })
if (!r.gelukt && r.code === 'usage_limit') showMessage('Saving is not possible right now.')
```

## Limits that depend on the plan
These are set per plan and can change, especially during the beta:
- AI calls per drop per day (topic `ai`).
- Email addresses on one drop's invitation list, and invitation emails per 24 hours (topic `sharing`). These do not limit how many people can open a drop.
The plans are described at `toolcrow.app/pricing`. The dashboard shows today's AI use.

## What has no limit
- How long a drop stays online: drops do not expire.
- Private per-visitor storage (`localStorage`) in the visitor's browser, beyond what the browser itself allows.
---

Source: https://www.toolcrow.app/docs/not-supported
Last updated: 2026-10-26

# What Toolcrow does not do

The boundaries of the platform: what a drop cannot contain or do, and what Toolcrow does not offer.

## No server code
- A drop has no server of its own. Server-side code (Node.js servers, Express, Next.js API routes, PHP, Python, Flask) does not run on Toolcrow. Projects that need a build step (for example a Vite project with `package.json`) are not built; only static files and single components are served.
- Saving data, AI calls and feedback are what Toolcrow offers in place of a server (topics `data`, `ai`, `feedback`). There is no general database, no scheduled tasks and no sending of email from a drop.

## No email when a submission arrives
Toolcrow does not email the maker when a visitor saves a submission. New submissions show up on the Submissions page, or in the connected Google Sheet. A notification rule set in that Sheet does not help: Toolcrow writes with the maker's own Google account, and Google does not send notifications about your own changes. To get a message for each new submission, forward submissions to Slack, Discord or Microsoft Teams, or to Zapier, Make or n8n to send an email or anything else from there (topic `data`).

## Secret keys stay out of a drop's code
- A drop runs in the visitor's browser, so anyone who can open it can also read its code. That is true for every website that runs in the browser, not something specific to Toolcrow. An API key, password or token written into the code can be copied by any visitor.
- For what Toolcrow provides, the code needs no key. AI calls go through Toolcrow's AI proxy, and the key stays on Toolcrow's server (topic `ai`). A connected Google Sheet is reached through Toolcrow as well, and the access to it is stored encrypted on Toolcrow's side (topic `data`).
- A webhook address works like a key: whoever has it can post to it. Forwarding submissions keeps the address encrypted on Toolcrow's side, so the drop's code never contains it (topic `data`). A tool that posts to a webhook from its own code has the address in its code instead.
- Toolcrow does not store keys for other services. A tool that talks to a service with the maker's own secret key (for example Airtable, Notion or a payment provider) would have that key in its code, readable by visitors.
- Connecting such a service through Toolcrow, so a drop can read from it or write to it without a key in its code, is not available yet. The Connections page only lists connectors that work today; "Suggest a connector" there tells Toolcrow which service a maker needs. Sending submissions to a service already works without a key, also to Airtable and a HubSpot form (topic `data`).

## No custom domains, no search engines, no embedding
- Drops are served on `toolcrow.live` addresses. Custom domains are not supported.
- Drops are kept out of search engines on purpose (`noindex`).
- Drops cannot be embedded in other websites in an iframe; only Toolcrow itself shows them in a frame.
- The "Powered by Toolcrow" badge cannot be switched off.

## No visitor accounts
Visitors do not sign in to a drop. Access is controlled with the link, a password or the private setting (topic `sharing`). There are no per-person accounts or permissions for visitors.

## Nothing published without the maker
A connected AI can read, propose and create private drops, but never publishes or shares, changes settings or reads visitors' data (topic `connect-your-ai`). Automatic adjustments after deploy only keep a tool's data per visitor; Toolcrow never starts collecting or sharing visitors' data on its own (topic `data`).

## File types
Markdown is not an input format, and new PowerPoint files are not accepted (export to PDF instead). See topic `building`.