# WeCanUseAI > A directory of practical AI and browser tools, maintained by Melbin J Paulose. > Most listed tools run client-side with no uploads. Anyone can submit a tool, > including AI agents acting on a builder's behalf. Submissions are machine-readable by design: an agent can list a tool without a human filling in the web form. Nothing goes live until the submitter's email is confirmed. ## Submitting a tool - [Submission format](https://wecanuseai.com/SUBMIT.md): full request/response shape for `/api/submit`, `/api/report`, and `/api/tools`. - [Build guidelines](https://wecanuseai.com/BUILD-GUIDELINES.md): how listings are assessed and ordered, published so it can be checked rather than inferred. Nothing in it decides whether a tool is listed. `POST https://wecanuseai.com/api/submit` with JSON: `name` (2-80 chars), `url` (http/https), `category` (one of: `code`, `communication`, `commerce`, `audio`, `images`, `video`, `documents`, `text`, `3d`, `accessibility`), `description` (20-500 chars), `contact_email`, `data_collection_statement` (plainly state what user data, if any, the tool collects). Returns `201 {"id": "...", "status": "pending"}`. `category` is optional and mostly unnecessary: a tool's categories are derived from its tags, and its tags are derived from its page after confirmation. Send one if you have a considered view; leaving it out is the normal case. ## Vocabularies Both are closed. A value outside them is dropped rather than stored, so inventing one has no effect other than losing the information. Tags are the precise layer, on three axes: - **subject** (What does it work on?): `audio`, `image`, `video`, `text`, `documents`, `3d`, `code`, `data` - **action** (What does it do to that?): `record`, `edit`, `generate`, `transcribe`, `convert`, `analyse`, `answer`, `view`, `organise`, `communicate`, `automate`, `trade` - **audience** (Who is it for?): `developers`, `accessibility` Categories are rollups of those tags, not a separate list. A tool files under every category its tags reach, so a transcriber that aids accessibility appears under both: - `code` (Code & packages) <- `code`, `developers` - `communication` (Communication) <- `communicate` - `commerce` (Buying & selling) <- `trade` - `audio` (Audio) <- `audio` - `images` (Images) <- `image` - `video` (Video) <- `video` - `documents` (Documents) <- `documents` - `text` (Text & writing) <- `text` - `3d` (3D) <- `3d` - `accessibility` (Accessibility) <- `accessibility` Machine-readable at `GET https://wecanuseai.com/api/taxonomy`. ## Querying the catalogue `GET https://wecanuseai.com/api/tools` returns the default list. Every parameter below is optional and combines with the others. - `q` - free text, matched against name, description and tags - `category` - one of the categories above - `tag` - one tag from any axis - `takes`, `gives`, `runs`, `needs`, `form` - the capability record, one value each - `tier=filtered` - the listings held apart from the main list, with the reason - `cursor` - the `next_cursor` from a previous response, to get the next page - `include=assessment` - adds the findings behind a listing's placement, so a recommendation can say why rather than only that a tool exists Sending no parameters returns exactly what it always has, and that response shape will not change. Every response carries `next_cursor`: a string to pass as `cursor` for the next 100 results, or `null` when there are no more. Do not construct a cursor yourself or assume anything about its contents. Treat it as opaque and pass it back unedited. Open to cross-origin reads. No key, no session, no challenge. ## Other endpoints `POST /api/feedback`: `tool_ref`, `source` (`curated` or `community`), `body` (20-1000 chars), optional `contact_email`. Reaches whoever can act on the tool. It is not a report: nothing about it is an input to how a tool is assessed, scored or ordered. `POST /api/report`: for harm rather than improvement. Three distinct reports hide a listing automatically. `POST /api/collaborate`: `contact_email`, `body`, optional `tool_ref`. For proposing work to the maintainer. No listing required, and sending one has no effect on any listing's placement. Notes for agents: - Omit `turnstile_token`. It gates the browser form only; a direct API caller is not asked for one. - The listing goes live only when the confirmation link emailed to `contact_email` is opened. That email confirmation is the anti-abuse gate, so submit a real address the tool's owner controls. - Limit: 5 submissions per `contact_email` per 24 hours. Exceeding it returns `429`. - `data_collection_statement` is published publicly next to the listing. State the tool's actual data handling; do not guess on the owner's behalf. - `contact_email` is never shown publicly and is not returned by `/api/tools`. ## Reading the directory - [Live listings](https://wecanuseai.com/api/tools): `GET /api/tools` returns `{"tools": [...]}`: confirmed community listings only. ## Reporting a problem `POST https://wecanuseai.com/api/report` with `tool_id` and `description` (20-500 chars, the specific concern). No email or identity required. ## Site pages - [Home](https://wecanuseai.com/): one list of tools, a held-apart section for those that ask something of you first, and packages you install. - [Contact](https://wecanuseai.com/contact.html): how to reach the maintainer. - [Privacy](https://wecanuseai.com/privacy.html) - [Terms](https://wecanuseai.com/terms.html)