TaskLite

Reviewed Jan 1, 2000.

• tools: 58 tools scanned
• metadata: scanned
• packages: 1 checked

No findings.

Tools (58)

• list_organizations

  List the organizations the authenticated user belongs to. Use the returned id as organizationId in other tools.

• configure_external_access

  Read or change how EXTERNAL users (people who sign up to your app through TaskLite auth) get into an organization. They have two ways in, and both obey the policy below: email and password (POST /auth/register-external with this organizationId, then POST /auth/login), or Google (POST /auth/google-external with a Google ID token and this organizationId). Either way the answer carries a token the app sends as Authorization: Bearer on every App API call. registrationPolicy: "open", in at once; "approval", an organization admin approves each signup (TaskLite mails the admins on every signup, and the person once approved; unapproved users are never billed); "invite", a new person gets in only with an invite code (create_app_invite, or a code a user of the app minted on a relation endpoint with allowInvites): the app sends it as inviteCode with POST /auth/otp/verify, /auth/register-external or /auth/google-external, a sign-up without one is refused with 403 INVITE_REQUIRED and a bad code wit

• list_projects

  List projects in an organization. The API returns 50 per page, an organization with more than that needs page 2 and beyond, so check the returned total before assuming a project does not exist.

• list_boards

  List the boards inside a project, id, name, description. Every other board tool needs a boardId, and this is the only way to discover one without being handed a URL.

• create_project

  Create a project (a business process container). Boards with data live inside projects.

• create_board

  Create a board (a data table) inside a project. Add typed columns with create_column afterwards. kind: "tasks" (default) also gives the board the built-in task columns, status, priority, assignee, due date, tags, for work people track; "data" creates a plain table with only the columns you add, for records such as customers, products or orders (requires a TaskLite server from 2026-09-06; older servers ignore kind).

• create_column

  Add a typed column to a board. Valid types: text, rich_text, number, status, date, datetime, duration, people, checkbox, dropdown, label, priority, link, email, phone, relation, lookup, rollup, formula, rating, currency, file. Choose by meaning, date for dates, phone for phones, number/currency for amounts, dropdown/status (with settings.options as an array of labels) for closed choices; text is for free text only. An obvious name/type mismatch is rejected with the suggested type; pass force:true to override. Rules go in settings.validation: { unique, min, max, minLength, maxLength, pattern, patternMessage }, enforced on every write (UI, MCP, App API). Closed choices (dropdown/status) reject values outside settings.options unless settings.allowCustom is true.

• get_board_schema

  Get a board with its full column schema (ids, names, types, settings). Call this before creating items with cells.

• update_board

  Rename a board or change its description. Structure (columns) is changed with update_column / delete_column / reorder_columns.

• delete_board

  Delete a board with every item on it. Destructive and not undoable, confirm with the user first, and prefer delete_column when only part of the model is wrong.

• delete_project

  Delete a project with every board, column and row inside it. Destructive: confirm with the user first, and name the project in the confirmation. The project goes to the organization recycle bin, so it can be restored from the admin until it is emptied.

• update_column

  Change a column after the fact: rename it, change its type (e.g. number -> currency), replace settings (dropdown options), or set isRequired / isHidden. A type change converts existing values (number↔currency, text→number/date/checkbox, anything→text) and clears the ones that cannot convert; the response carries conversion: { converted, cleared }. settings.validation rules apply here too.

• delete_column

  Delete a column and every value stored in it. Destructive, confirm with the user first. Use update_column when the column is right but its name, type or options are wrong.

• reorder_columns

  Set the display order of a board's columns. Pass every column id in the wanted order (get_board_schema lists them).

• export_project

  The whole project as JSON, boards, columns with settings, items with their cells keyed by column id. For migrations, backups and reading a system back. Items are capped per board for the model's sake; the REST endpoint GET /organizations/{orgId}/projects/{projectId}/export.json returns everything.

• query_items

  List items (rows) of a board, including their cell values. Returns all items unless limit/page are given (the API defaults to 50 per page when unpaged, so the tool pages through and concatenates). Narrow the result with search, status, priority and sort instead of fetching everything. This is the admin view; the REST endpoints of a published app take a fuller grammar, filter[column][gte], relation filters, per-field search, see get_app_spec.

• create_item

  Create an item (row) with all of its data in one call. cells maps columnId -> value (use get_board_schema for column ids); every cell is saved with the row. Use set_cell only for later edits.

• update_item

  Update item fields (title, description, status, priority, dueDate, tags).

• set_cell

  Set a single cell value on an item by columnId.

• delete_item

  Delete an item. Destructive, confirm with the user before calling.

• list_comments

  List the comments (the correspondence thread) on an item, oldest first. Each comment includes its author and any @mentions. Needs projectId and itemId (get itemId from query_items).

• add_comment

  Post a comment on an item's thread. To notify people, pass their user ids in mentionedUserIds (each also appears as an @mention). attachmentIds references already-uploaded files. Needs projectId and itemId.

• update_comment

  Edit the text of an existing comment. Only the author can edit their comment. Needs projectId, itemId and the commentId.

• delete_comment

  Delete a comment from an item thread. Destructive, confirm with the user before calling. Needs projectId, itemId and the commentId.

• request_file_upload

  Create a link that puts files onto an item from outside TaskLite: the customer's photos, a signed contract, a logo, a build zip. Returns an address like https://app.tasklite.net/upload/<token> that anyone you hand it to can use with no account, no login and no API key; pass clientEmail and TaskLite emails the link for you. What arrives lands as attachments on that item, and list_uploaded_files reads them back with a download URL. This is the answer when the person has the file and the model does not: a hosted client cannot read a folder on someone's machine. The link is public for as long as it lasts, so keep expiryDays short and maxFiles tight, and revoke_upload_link when the material is in.

• list_uploaded_files

  The files attached to an item, including everything that came in through a request_file_upload link, each with a download URL that is signed and short lived (mint a fresh one by calling again). Also lists the upload links on the item and how many files each has taken, which is how to tell whether the person you asked has delivered.

• revoke_upload_link

  Close an upload link before it expires, so the address stops accepting files. The files already uploaded stay on the item. Use it as soon as the material is in, because until then anyone holding the link can add more.

• create_app

  Create an app, a named API surface over the boards of a project, for an external frontend. Then add endpoints and an API key.

• push_status

  Whether an app can send push notifications to phones, and how many devices are registered. Push goes out through the customer's OWN Firebase project, so it has to be configured once per app before send_push automations do anything. This tool never returns the key.

• send_test_push

  Send one real push notification to the given app users, to prove the chain works before an automation depends on it. Confirm with the user first: this reaches actual phones.

• publish_app

  Publish an app, required before its API endpoints accept external calls.

• create_app_endpoint

  Expose a board as a REST endpoint of an app: /apps/{appSlug}/api/{slug}. exposedColumns limits which columns are readable/writable. rowLevelSecurity.enabled makes the endpoint per-user: the developer's server sends `X-App-User: <their user id>` next to the API key, and the endpoint returns, updates and deletes ONLY that user's rows (401 without the header). Use it whenever the app has its own users. rowLevelSecurity.mode chooses which rows a user reaches: owner (the rows they created), shared (all rows, for authorized users), phone (the rows that carry their verified phone) or relation (the rows linked through a relation column to the row that stands for them). An app with two kinds of people in one organization, coaches and their trainees, is built from these: the Coaches board in mode phone (phoneColumn = its phone column), so each coach reads and edits his own row; Trainees in mode relation with relationColumn = its Coach column and identityPhoneColumn = the Coaches phone column, so

• list_app_endpoints

  List an app's REST endpoints, slug, board, allowed methods, and how many columns each exposes. An endpoint exposing 0 columns is broken: it returns only item metadata and silently discards writes.

• update_app_endpoint

  Change an existing endpoint, most often to set exposedColumns on one that was created without them. Get the endpoint id from list_app_endpoints and the column ids from get_board_schema.

• delete_app_endpoint

  Delete an endpoint of an app for good: /apps/{appSlug}/api/{slug} stops answering at once and the endpoint cannot be brought back (create it again with create_app_endpoint). The board and its rows are not touched. Confirm with the user first: a frontend that calls this endpoint breaks. To take an endpoint offline and keep its definition, use update_app_endpoint with isActive false instead (list_app_endpoints shows active endpoints only, so keep the id). Get the endpoint id from list_app_endpoints.

• configure_app_settings

  Read or change the settings object of an app. Call with only appId to read. To change, pass set: the keys in it are MERGED into the current settings (objects merge key by key at every depth, arrays and plain values replace, null removes a key). The server itself does not merge: PATCH replaces the whole settings object with what it is sent, so this tool reads the app, merges, and writes the full object back; two writers at the same moment can still overwrite each other, so do not run it in parallel on one app. Settings the server reads: passwordReset.returnUrls (array of up to 50 URLs the "reset password" email may send a user back to, matched by scheme, host, port and path prefix; needed only for a custom app scheme such as myapp://reset or a domain other than the app's own {slug}.tasklite.dev and its connected custom domains, which are always allowed; http is never accepted), language (the language of the password reset email: a value starting with "he" gives Hebrew, any other value E

• list_app_users

  List the end users of an app: everyone who ever called it with X-App-User or signed in to it with a code. Each has userId (the id link_app_user, list_app_user_links and send_test_push take), externalId (the developer's own id for them, or null for a user who signed in by code), name, source (api or otp), role (viewer, editor or submitter; editor when never set), isActive, lastSeenAt and itemCount (rows they own on the app's boards). Use it to find the userId of the person to link to a row.

• create_app_invite

  Create an invite code for an app (8 characters shown as XXXX-XXXX, typed without regard to case or the dash). The person signs up or signs in through the app with the code: the app sends it as inviteCode with POST /auth/otp/verify, /auth/register-external or /auth/google-external, after it may check it with POST /auth/invites/check. An invite does one or both of two things, and must do at least one: itemId links the new user to that row, so they "are" the row for every endpoint in row-level security mode "relation" (invite a trainee to her own Trainees row, or a coach to his Coaches row); role puts them on the app's access list (viewer, editor or submitter), which is what mode "shared" endpoints check. A valid code also admits a new person into an organization whose registration policy is "invite" or "closed" (configure_external_access). An existing access row is never changed by an invite: it does not re-enable a user who was switched off and does not raise a role. Requires organizati

• list_app_invites

  List the invite codes of an app, newest first (the latest 200): the ones created with create_app_invite and the ones the app's own users minted through a relation endpoint with allowInvites (createdVia admin or app). Each carries id, code, itemId, role, label, maxUses, useCount, expiresAt, revokedAt and status: active, used (no uses left), expired or revoked.

• revoke_app_invite

  Revoke an invite code so nobody else can sign up with it. People who already used it stay linked to their row and keep their access; to cut one of them off use unlink_app_user. Cannot be undone, create a new invite instead. Requires organization owner or admin. Get the invite id (not the code) from list_app_invites.

• check_invite_code

  Check whether an invite code works right now, the way an app does before sign-up (POST /auth/invites/check, the same public route, limited to 10 calls a minute per address). A working code answers { valid: true, organizationId, app: { name, slug }, label, expiresAt }; anything else (unknown, revoked, expired, used up, its row deleted, its app switched off or deleted) answers only { valid: false }, with no reason, by design. It does not use the code up. For the reason a code stopped working, read its status in list_app_invites.

• link_app_user

  Link an existing user of an app to a row, so the user "is" that row for every endpoint in row-level security mode "relation": link a coach to his Coaches row and he reaches the trainees whose Coach column points at it. This is the manual form of what an invite code does at sign-up; use it for someone who already has an account (find the userId with list_app_users). A user may be linked to several rows, and linking the same pair again changes nothing. The user must already be a member of the app's organization (anyone who signed in to the app is) and the row must be a live row in that organization, otherwise 404. Requires organization owner or admin.

• list_app_user_links

  List the rows one user of an app is linked to, oldest first: each link has itemId, source (invite or admin) and createdAt. These are the rows the user "is" under row-level security mode "relation". A user can also stand for a row with no link at all, through identityPhoneColumn or identityEmailColumn; those matches are computed on every request and do not appear here.

• unlink_app_user

  Remove the link between a user of an app and a row: the user stops being that row, and at once loses the rows of every relation endpoint they reached through it. The account, the row and the user's app access are not touched, and nothing is deleted. A user matched to the row by identityPhoneColumn or identityEmailColumn still reaches it; change the phone or email in the row to end that. Requires organization owner or admin. Removing a link that does not exist also answers success.

• create_app_api_key

  Create an API key for an app. SECURITY: the key must live server-side only (env var, Next.js API routes), never in browser code. If the app has its own users, the server also sends `X-App-User: <user id>` with the key so per-user endpoints know who is acting.

• build_backend

  Build a whole backend in one call from a spec you compose: the project, its boards, their typed columns (including relations between the boards), optional sample rows, and optionally a published REST API with one endpoint per board and a server-side key. Use it whenever the user describes a system ("a backend for my repair shop: customers, orders, payments") instead of calling create_project, create_board, create_column, create_app, publish_app, create_app_endpoint and create_app_api_key one by one. You do the design, pick column types by meaning (phone, date, currency, dropdown/status with options for closed choices), link boards with a relation column (type "relation", relatedBoard: "<board name in this spec>", relationType: many_to_one for an order→customer link), and this tool executes it and returns one compact summary. API field names are derived from column names and never collide with reserved item fields, so there is nothing to retry. Boards are created as plain data tables (k

• create_automation

  Create an automation on a board: when something happens, do something. The most useful action here is http_request, which calls an external API and writes the answer back into columns, pair it with the "scheduled" trigger and the board keeps itself up to date (prices, exchange rates, shipment status, weather). Triggers: item_created, status_changed, column_value_changed, date_approaching, scheduled. Actions: http_request, send_notification, send_email, send_push, change_status, set_column_value, create_cross_board_item, send_webhook. The scheduled trigger has no cron expression: the server checks once an hour, and triggerConfig takes { intervalHours, runAtHour } only (intervalHours: at least this many hours between runs, default 24; runAtHour: 0-23, run only during that hour of the day in UTC, not in the user's time zone, so convert: 08:00 in Israel is runAtHour 5 in summer and 6 in winter). A scheduled run executes the actions once for every row of the board that passes conditions, so

• update_automation

  Change an existing automation: its actions, conditions, trigger config or name, or switch it off with isActive false. Fields left out stay as they are; actions and conditions, when given, replace the whole list. Use it to fix an automation instead of creating a second one next to it. Get the id from list_automations.

• list_automations

  List the automations on a board, so you can see what already runs before adding another.

• list_apps

  List the apps in the organization, id, slug, status. Call this first when you need an app id: the slug (app-xxxxxx) is what shows up in URLs and in generated code, and this is how you map it back to the app.

• get_app_spec

  Get the machine-readable spec of an app: base URL, endpoints, methods, fields, auth. Two formats: "tasklite" (default), the compact shape the frontend prompts are built from, and "openapi", a standard OpenAPI 3.1 document for developers and other tools. When the user asks for the OpenAPI spec, or wants to hand the API to a developer, pass format "openapi". appId accepts either the app UUID or its slug (app-xxxxxx); list_apps shows both. The returned baseUrl is absolute, use it verbatim, do not rebuild it from the admin URL.

• get_frontend_prompt

  Get a ready-made prompt describing the app backend, for pasting into a frontend generator (v0/bolt/lovable/cursor). appId accepts the app UUID or its slug (app-xxxxxx), use list_apps to find it.

• search

  Full-text search across the projects, boards and items of the organization. Returns { results: [{ id, title, url }] }, the shape ChatGPT connectors and deep research expect; pass a result id to fetch for the full record. When you already know the board, query_items is cheaper and complete.

• fetch

  One project, board or item in full, by the id search returned (project:<id>, board:<projectId>:<boardId>, item:<projectId>:<boardId>:<itemId>) or by an app URL path. Returns { id, title, text, url, metadata }, the ChatGPT fetch contract; text is the record as JSON.

• deploy_frontend

  Deploy a static frontend to TaskLite hosting and get a live URL https://{slug}.tasklite.dev (HTTPS, auto-published on first deploy, versions kept for rollback_deployment). Hand over the frontend in ONE of three ways: `files`, the files inline (path + content), the way to go from ChatGPT or any hosted client: write index.html and its assets, then deploy in the same turn; `zipUrl`, a public https URL of a zip (a Lovable/Bolt export, a GitHub release asset); `dir`, a build output folder on this machine (only when the MCP runs locally next to the files); `fromAppId`, a version already hosted in the same organization, copied on the server (start a new app from an existing site, or bring an old version back as a new one; get_deployment_files reads a version first). A real build that already exists on the person's machine fits none of these from a hosted server: tell them to drop the zip on the app's Versions screen (the adminUrl of the app, then Versions), which deploys the same way and keep

• list_deployments

  List the hosted-frontend deployments of an app, versions, which one is live, and the public URL.

• get_deployment_files

  Read back what a hosted frontend version is made of: every file with its size and its URL on that version, and the full text of the text files (HTML, CSS, JS, JSON, SVG...). This is how a new conversation continues a site an earlier one built: "take my Krispool site and keep going" starts here, not from scratch. For a site written by hand the files ARE the source. For a bundled build (Vite, React) the JS is minified output: fine to inspect, not something to edit, so ask for the project's source instead. Images and other binaries come back as URLs only. Text is capped at 512KB per file and 4MB per call; narrow with `paths` for a big site. To start another app from this version, or bring an old version back as a new one, use deploy_frontend with fromAppId.

• rollback_deployment

  Point the live URL back at a previous deployment version (see list_deployments for available versions).