# TaskLite [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/shimon-ks/tasklite-mcp  
**GitHub Stars:** 0  
**npm Downloads (last month):** 1610  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/tasklite-3

## Description
tasklite.net: hosted backend, REST API and admin for apps built by AI agents

## Tools
Capabilities this server exposes over MCP:

- **connection_status** — Check whether this machine is connected to a TaskLite account. Call this first if any tool fails with an auth error.
- **sign_up** — Create a brand-new TaskLite account + organization and connect this machine, no website visit needed. A strong random password is generated locally and never shown or stored; for web access the user later uses "forgot password" with this email. Ask the user for email, their name, and a business name before calling.
- **connect** — Connect this machine to an existing TaskLite account, or switch to a different one. Takes a personal API key (tl_...) created at TaskLite → Integrations → "Connect Claude Code". Replaces the current connection if there is one, use this to switch user or organization. The switch takes effect immediately; no restart.
- **login** — Connect this machine to an existing TaskLite account with email + password, or switch to a different account. Creates a personal API key named "claude-code" on that account and stores it, so the password is used once and never saved. Replaces the current connection if there is one. Prefer connect when the user already has a tl_ key.
- **disconnect** — Disconnect this machine from TaskLite by forgetting the stored credential. Use before connecting a different account, or to revoke local access. Does not delete anything in TaskLite itself and does not revoke the key server-side.
- **list_organizations** — List the organizations the authenticated user belongs to. Use the returned id as organizationId in other tools.
- **get_email_usage** — How much of the monthly email quota an organization has used: emails sent this month, emails waiting in the queue, the plan limit (Free 300, Plus 3000, Pro 20000; null means unlimited), whether the plan allows marketing email, and whether sending is paused for the organization (too many bounces or complaints). Covers email sent by automations, the communications endpoints and app servers (POST /apps/<slug>/api/_email/send).
- **configure_external_access** — Read or change how EXTERNAL users (people who sign up to your app through TaskLite auth) get into an organization. This policy governs sign-up by email and password and by Google. Sign-in by a phone code (POST /auth/otp/send, then /auth/otp/verify) obeys only "invite": under "closed", "approval" and "open" any phone that verifies a code becomes an external member of the organization, who reaches nothing until an endpoint's row-level security or the app's access list (add_app_user) gives them something; under "invite" a new phone needs an invite code or an add_app_user grant. The two ways in that obey the whole policy: 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 with 403 INVITE_INVALID, while people who are already members keep signing in as before; "closed" (the default), self-signup refused, external users are created by an admin. Under every policy a valid invite code admits its holder as if the organization were open, so "invite" is the policy for an app where people join only through someone who invited them (a coach inviting trainees). appLoginUrl: the page of YOUR app where these users log in, it becomes the "Log in" button in the approval email, so set it whenever you deploy an app that uses this flow; pass "" to clear. Call with no changes to just read the current settings. Requires organization admin.
- **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). On a data board the task fields (status, priority, dueDate, tags) are hidden: its columns, status included, are set with set_cell.
- **set_cell** — Set a single cell value on an item by columnId.
- **get_cells** — Read cells of one item from the database (not a cache): one current value per column, the value set_cells_if_unchanged compares. Use it to decide a conditional write, and pass each value back as `expected` exactly as it came.
- **set_cells_if_unchanged** — Compare-and-set on cells of one item, all or none. Each cell carries the value you read (`expected`, null = empty) and the value to write. If any cell no longer holds its `expected`, nothing is written and the answer is an error with code CELL_CONFLICT and `conflicts` [{columnId, current}]: read again (use `current`), decide again, and never resend the same call. CELL_BUSY (the row is being written) also writes nothing: read again, then retry. Plain columns only (not relation, file, lookup, rollup, formula, button or system columns). Use set_cell for a write that needs no precondition.
- **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.
- **create_signature_request** — Send a PDF for electronic signature and get the signing links back. One call: the PDF (an attachment already on an item, see list_uploaded_files / request_file_upload, or the bytes as base64), the signers, and optionally the row it belongs to. Each signer opens a personal link with an expiry, confirms a one-time code sent to their email or WhatsApp, reads the document and signs; the platform then seals the PDF with an evidence page and emails every signer the signed copy. With no fields, a signature page (name, signature, date per signer) is added at the end, so "read, then sign at the end" needs no coordinates. With itemId and signedFileColumnId (a file column on that item's board), the signed PDF is added to that cell when everyone has signed: build what happens next as an automation on "column value changed" of that column (set a status, notify, webhook). sendEmail=false skips the invitation emails and the links are yours to hand over (WhatsApp, open on the agent's phone). For a customer app the same thing is in its own API: /api/_esign (script /api/_esign/sign, TaskLiteSign).
- **list_signature_requests** — Documents sent for signature, newest first, with each signer's state (sent, viewed, signed, declined). Filter by the row they belong to or by status (out_for_signature, completed, declined, voided, expired, failed).
- **get_signature_request** — One document sent for signature: status, signers and their state, and when complete a short-lived download URL of the signed PDF (with its evidence page).
- **signature_link** — A fresh signing link for one signer whose turn it is, to open on the spot (the agent's phone) or to send yourself. Their previous link stops working.
- **void_signature_request** — Cancel a document that is out for signature: every link stops working. A completed document cannot be voided.
- **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 a coach who signed in by phone sees only his trainees; boards one hop further (weigh-ins of a trainee) in mode relation with relationColumn = the Trainee column and viaColumn = Trainees.Coach for the coach, plus a second endpoint on the same board without viaColumn for the trainee herself. A trainee becomes her row through an invite code (create_app_invite, or allowInvites so the coach mints it in the app) or link_app_user.
- **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: ai (AI actions the app may run: { enabled: true, userDaily?, appDaily?, actions: { "<name>": { instructions, output?: "text"|"json", schema? (a JSON Schema, required for json), inputs?: { "<input>": { maxChars?, required? } }, tier?: "fast"|"smart", maxOutputTokens?, temperature?, audience?: "users"|"server" } } }. The instructions stay on the server: a page runs an action by name with POST /apps/<slug>/api/_ai/v1/run { action, input } and the signed-in user's own token (the app's server may use a key with the "ai" scope). Every run is charged to the owner's usage allowance; 429 AI_QUOTA_EXCEEDED, AI_USER_DAILY_LIMIT or AI_RATE_LIMIT carry messageHe/message to show. An app without sign-in cannot run AI actions), 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 English; left out, the user's own language decides), endUserDeletion.rows ("delete": when an end user deletes their account, the rows they wrote in this app are deleted with it and erased for good 30 days later; left out, the rows stay with the author shown as a deleted account). Other keys are stored as given and returned, and the server does not act on them.
- **list_app_users** — List the people of an app, as { users, pending }. users: everyone who ever called it with X-App-User or signed in to it with a code. Each has userId (the id set_app_user_role, remove_app_user, 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, phone (the phone they proved with a code, or null), source (api or otp), role (viewer, editor or submitter), isActive, hasAccessRow, lastSeenAt and itemCount (rows they own on the app's boards). hasAccessRow says whether they are on the app's access list: when it is false, role and isActive are only defaults, and an endpoint in row-level security mode "shared" refuses them with 403 until add_app_user or set_app_user_role puts them on the list. pending: the phones add_app_user is still holding access for, each with id, phone, role, createdAt, expiresAt and status (pending, or expired); they get in on their first sign-in with a code. Use it to see who can use the app and to find the userId of a person.
- **add_app_user** — Give a person access to an app by their phone number: the phone and a role, nothing else. This is how the people who run an app (the business owner, a manager, staff) get into its admin screen, whose endpoints are in row-level security mode "shared". The person needs no invite code and does not have to sign in first. If the phone already signed in to this organization with a code, access is on at once and the answer has status "active" and their userId. Otherwise the answer has status "pending" and a pendingId: nothing is created for the number yet, and the access opens by itself the first time that phone signs in to the app with an SMS code (POST /auth/otp/send, then /auth/otp/verify). The phone is matched whatever its spelling: 054-1234567, +972 54 123 4567 and 972541234567 are one number; a number outside Israel needs its country code. Calling again for the same phone sets its role again, and switches back on a user who was switched off. Roles: editor (reads and writes), viewer (reads), submitter (creates). The app must still sign people in by phone code; a person who signs in another way (email and password, Google) is a different account, give them access with set_app_user_role after their first sign-in. Requires organization owner or admin (an editor gets 403).
- **set_app_user_role** — Change what an existing user of an app may do, or switch them off or back on. Takes the userId from list_app_users and at least one of role and isActive. It also puts on the app's access list a user who is not on it yet (hasAccessRow false in list_app_users), which is what an endpoint in row-level security mode "shared" checks: use it for someone who already signed in and is refused with 403. isActive false switches the user off in every mode: their calls are refused until it is set back to true; nothing of theirs is deleted. For a person who has not signed in yet there is no userId: use add_app_user with their phone. Requires organization owner or admin (an editor gets 403).
- **remove_app_user** — Take a person's access to an app away. Pass exactly one of two ids from list_app_users: userId, for someone who already signed in, switches them off (the same as set_app_user_role with isActive false: their calls are refused in every mode, nothing of theirs is deleted, and set_app_user_role or add_app_user switches them back on); pendingId, for a phone that add_app_user is still holding access for, cancels it, so that phone's first sign-in opens nothing. Requires organization owner or admin (an editor gets 403).
- **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 organization owner or admin (an editor gets 403). To let the app's own users invite (a coach invites his trainees from inside the app), set allowInvites on the relation endpoint instead; the app then calls POST /apps/{appSlug}/api/{endpointSlug}/{itemId}/invites.
- **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.
- **list_app_roles** — List the business roles of an app's project, as { roles: [{ key, label }] }. Roles are what board policies (set_board_policy) name in their `roles` lists; they are separate from the app access role (viewer, editor, submitter) of add_app_user. Requires organization owner or admin.
- **define_app_role** — Create a business role of an app's project, or change the label of an existing one (calling again with the same key and a label updates the label). A role is only a name; what it may do is written in the board policies. Example: key "manager", label "Agents manager". Roles can also come from the data itself with set_policy_identity (an employees board with a role column) instead of grant_app_role per person. Requires organization owner or admin.
- **delete_app_role** — Delete a business role of an app's project. Check first with list_app_role_grants who holds it and with get_board_policy where policies still name it: a policy that names a role that no longer exists simply matches nobody. Requires organization owner or admin.
- **grant_app_role** — Give an app user a business role (a user can hold several). Takes the userId from list_app_users and a role key from list_app_roles. expiresAt makes the grant temporary. Granting the same pair again changes only expiresAt. This is for personal exceptions; for a whole team prefer set_policy_identity, which reads the roles from an employees board. Requires organization owner or admin.
- **revoke_app_role** — Take a business role away from an app user (a grant made with grant_app_role). A role the user gets from the employees board (set_policy_identity) is not a grant: change the board row instead. Revoking a grant that does not exist also succeeds. Requires organization owner or admin.
- **list_app_role_grants** — List the role grants of an app's project, as { grants }: who holds which role and until when. Pass userId to see one person's. Roles that come from the employees board (set_policy_identity) are not grants and are not listed here; explain_access with a userId shows the roles a person ends up with. Requires organization owner or admin.
- **get_policy_identity** — Read the project's role identity: which board holds the people and how their rows map to roles (see set_policy_identity). Returns { identity }, null when none is set. Requires organization owner or admin.
- **set_policy_identity** — Derive "who is this user and what is their role" from the data, instead of a grant per person: point at the employees board, its phone/email column, the column that says what each person does, and a map from that column's values to role keys. A signed-in user whose verified phone (or email) is in a row of that board gets that row's roles; a row that is not active gives none. Full replace. Example: { "board": "<Employees board id>", "phoneColumn": "<Phone column id>", "roleColumn": "<Position column id>", "roleMap": { "Agent": ["agent"], "Agents manager": ["manager"], "Owner": ["owner"] }, "activeColumn": "<Status column id>", "activeValues": ["Active"] }. Board and columns are ids (get_board_schema). A grant (grant_app_role) adds to what the board gives. Requires organization owner or admin.
- **get_board_policy** — Read a board's access policy: { boardId, policy, updatedAt, updatedBy }, policy null when the board has none. A policy only takes effect on endpoints whose rowLevelSecurity mode is "policy". Requires organization owner or admin.
- **set_board_policy** — Set who may read, write, create and delete rows of a board, and which columns, as a JSON document (a FULL REPLACE of the board's policy; read get_board_policy first to change part of one). It is enforced on the app's endpoints of this board whose rowLevelSecurity.mode is "policy" (create_app_endpoint / update_app_endpoint). Organization owners, admins and editors using the app are let through unless internalBypass is false. Fields:
- schemaVersion: 1 (required).
- internalBypass: default true.
- rows.read / rows.write: a list of { roles, scope }. scope is "all", { "mine": "<column id>" } (rows whose column points at the caller: a relation to the row that stands for them, their verified phone or email, or a people column; add "via": "<relation column id>" for one more hop), { "created": true } (rows they created through the app) or { "where": CONDITION } (rows a condition selects, e.g. open cases older than 3 days, for an escalation view). A user gets the union of the rules that name any of their roles; no rule for their roles means no access.
- rows.create / rows.delete: plain role lists.
- columns: { "<column id or reserved field>": { "read": ACCESS, "write": ACCESS } }. ACCESS is a role list, or { "roles": [...], "orMine": "<column id>" } (these roles, or anyone for whom the row is theirs by that column). A column without an entry follows the row rules. An EMPTY list ("write": []) locks the column for everyone through the app: use it for assignedTo and for any field only an admin or an action may change. Reserved fields are title, description, status, priority, dueDate and assignedTo, addressed by those names. Reserved fields are open to anyone who may write the row unless you lock them, so lock assignedTo.
- CONDITION (in where, rules.when): { "all": [c...] } | { "any": [c...] } | { "not": c } | a leaf { "col": "<column id or reserved field>", "op": OP, ... }. OP: eq / neq (with "value"), in (value is a list), empty, notEmpty, isMe (the column points at the caller; optional "via"), olderThan (col is updatedAt, createdAt or a date column; give "hours" or "days"), changed (this write sets col; only in rules). No free expressions.
- rules: [{ "id", "when": CONDITION, "deny": { "write": "*" | [column ids], "except": [roles] }, "require": [column ids that must be filled after the write], "except": [roles], "message" }]. deny is judged on the row as it is BEFORE the write, require AFTER it. Rules bind people acting through the app; internal bypass users and an action's own columns are not held to deny.
- actions: { "<name>": { "roles": [...], "input": { "<input name>": { "col": "<column id the value is written to>", "required": true } }, "set": { "<column id>": constant }, "event": "TRANSFER", "scope": "write" | "read", "approval": "<approval workflow id of the board>" } }. An action is role-gated, validates its input (an input without col is only data; "reason" is always accepted and goes to the history), writes its set and bound inputs in one transaction, and records event and reason in the history. It is the only way to change a column whose write is []. With approval it files a request for that workflow instead of writing; the write happens when the last step approves. Roles named by approval steps must exist (define_app_role). Actions run through the App API only (see below).
Frontends run an action with POST /apps/<slug>/api/<endpoint>/<itemId>/actions/<name> and the inputs as the body; approvers read GET /apps/<slug>/api/me/approvals and answer POST /apps/<slug>/api/approvals/<requestId>/decide { "decision": "approve" | "reject", "comment"? }; GET /apps/<slug>/api/me/permissions lists the actions the caller may run as [{ name, allowed, roles, inputs, approval, event, scope }]. There is no MCP tool that runs an action.
Roles are keys from list_app_roles, plus "*" (any signed-in user) and "public". Column ids come from get_board_schema. An invalid document is refused with POLICY_INVALID and an errors list naming each problem. Example (agents see and edit only their own cases, the manager sees and edits all, bookkeeping reads all, commission is visible to the owner, the manager and to the agent on his own rows):
{ "schemaVersion": 1,
  "rows": {
    "read":  [ { "roles": ["owner","manager","bookkeeping"], "scope": "all" },
               { "roles": ["agent"], "scope": { "mine": "<agent column id>" } } ],
    "write": [ { "roles": ["owner","manager"], "scope": "all" },
               { "roles": ["agent"], "scope": { "mine": "<agent column id>" } } ],
    "create": ["owner","manager","agent"],
    "delete": ["owner"] },
  "columns": {
    "<commission column id>": { "read": { "roles": ["owner","manager"], "orMine": "<agent column id>" }, "write": ["owner"] },
    "<agent column id>": { "write": ["owner","manager"] },
    "assignedTo": { "write": [] } },
  "rules": [ { "id": "lock", "when": { "all": [ { "col": "<locked column id>", "op": "eq", "value": true } ] },
               "deny": { "write": "*", "except": ["owner","manager"] }, "message": "The case is locked to its agent" } ],
  "actions": {
    "transfer": { "roles": ["owner","manager"], "input": { "agent": { "col": "<agent column id>", "required": true }, "reason": { "required": true } },
                  "set": { "<locked column id>": false }, "event": "TRANSFER" },
    "unlock":   { "roles": ["owner","manager"], "input": { "reason": { "required": true } }, "set": { "<locked column id>": false }, "event": "UNLOCK" },
    "exception": { "roles": ["agent"], "input": { "reason": { "required": true } }, "set": { "<exception column id>": true }, "approval": "<workflow id, a role step>" } } }
(The Achituv shape: a locked case cannot be edited except by the owner and the manager; transfer and unlock are the only way to change the agent or the lock, with a recorded reason; an exception asks a role step for approval.) Test it with explain_access and simulate_request before telling the user it is done. Requires organization owner or admin.
- **delete_board_policy** — Remove a board's access policy. An endpoint of that board in rowLevelSecurity mode "policy" then has no policy to follow; check what it allows afterwards with explain_access before leaving it on a live app. Requires organization owner or admin.
- **explain_access** — Say what a user, or a list of roles, may do on a board under its policy: which rows they read and write, which columns, create and delete. Pass boardId and exactly one of userId (an app user from list_app_users; the answer includes the roles that person has) or roles (role keys, to try a role before anyone holds it). Changes nothing; use it after every set_board_policy. Requires organization owner or admin.
- **simulate_request** — Dry-run one app API request in the name of a user and get the verdict (allowed or refused, and why), changing nothing: the endpoint slug, the HTTP method (or the name of a policy action, with its itemId) and optionally the column keys the body would carry. Use it to prove that a forbidden thing is refused (an agent PATCHing assignedTo, reading another agent's row) and an allowed one passes. Requires organization owner or admin.
- **get_item_history** — Read the change history of one item (row), newest first: who changed which field, from what to what, when, through which channel, with the event and reason when a named action made the change. Returns { items: [{ field, fieldId, from, to, at, actor: { userId, name }, channel, event, reason }], nextBefore }. Page backwards by passing nextBefore as `before`. Needs access to the item's board.
- **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 (kind "data": only the columns you define, no task fields); set kind "tasks" on a board where people track work to do and want status, priority, assignee and due date built in. Every row still has a title. When the API has its own users, api.rowLevelSecurity: true gives every endpoint mode "owner"; a board may carry its own rowLevelSecurity instead (mode shared, phone or relation, with columns named as in this spec), e.g. Coaches { mode: "phone", phoneColumn: "Phone" } and Trainees { mode: "relation", relationColumn: "Coach", identityPhoneColumn: "Phone", allowInvites: true }.
- **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 filter with conditions. send_push sends a notification to the phones of app users through the app's own Firebase project (set up once per app: push_status; try it with send_test_push). Its config: { title, body, data, userIds, recipientsFromRelation, includeRowOwner, sound, badge, dataOnly }. title and body take {{column name}} placeholders, title defaults to the row title. Recipients are the union of: the row's owner under row-level security (includeRowOwner, default true; false leaves them out), userIds (fixed user ids, as in list_app_users), and recipientsFromRelation, a dotted path of column NAMES such as "Client.Coach.Coach user" that walks relation columns from this row and whose LAST segment must be a people column holding user ids (a single segment is a people column on this board); it does not resolve the user linked to a row by an invite or by phone, so without such a people column use userIds or the row owner. data is a flat object of strings the app reads to decide where to open (itemId and boardId are added). sound: "default" or the file name of a sound bundled in the app; badge: 0 to 99999, 0 clears; dataOnly: true shows nothing and delivers only data (no title, body, sound or badge; iOS may throttle or drop it). With no recipient the action is skipped, not failed. Two more things every action list can use: a { type: "delay", config: { minutes | hours | days } } action pauses the run and resumes the actions after it later (reminders, follow-ups); and any network action (http_request, send_webhook, send_email, send_whatsapp) may carry config.retry: { attempts (1-5), delaySeconds (1-60) }. send_webhook accepts config.secret for an HMAC signature. send_email sends mail from the organization to the people on a row. Its config: { to, subject, body, columnEmailField, fromName, replyTo, kind, attachments }. kind is "transactional" (the default: orders, receipts, notifications) or "marketing" (promotional mail: it needs the Pro plan or higher and a verified sender domain, and it gets an unsubscribe footer; people who unsubscribed are skipped). attachments is an array of FILE column ids on the triggering row (or {{column.<id>}}): the stored files in those cells are attached, up to 5MB in total, and a missing file is skipped instead of failing the action. Email is counted per month by plan: Free 300, Plus 3000, Pro 20000 (read the numbers with get_email_usage); a message held back by the quota is recorded as skipped in the communications log and can be resent from there. To send email from an app's own server instead of an automation, POST /apps/<slug>/api/_email/send with the app server key (X-API-Key, never a user token; the key needs the "email" or "write" scope, see create_app_api_key): { to: [up to 50 addresses], subject, html or text, replyTo, kind, attachmentIds: [stored file ids] }; each app may send 500 a day (429 APP_EMAIL_DAILY_LIMIT). create_cross_board_item copies a new row to another board: config { targetBoardId, title?: "{{item.title}}", columnValues: { "<column id on the TARGET board>": "{{<column NAME on this board>}}" } }; there is no mapping field, and a column left out is not copied. To act only on some rows pass conditions, e.g. [{ field: "<column id on this board>", operator: "equals", value: "New seller" }]. Change an automation later with update_automation; call list_automations first so you do not add a second one that does the same thing.
- **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. For send_email actions, config.kind is transactional (default) or marketing (Pro plan or higher, verified sender domain, unsubscribe footer) and config.attachments is an array of file column ids on the row; see create_automation.
- **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 keeps the same version history. In the frontend, call the app API via relative /api/{endpoint}, the hosting proxy injects the app identity, so no key ships to the browser.
- **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).

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "tasklite": {
    "command": "npx",
    "args": ["-y","@tasklite/mcp"]
  }
}
```

## Documentation

## What TaskLite does

TaskLite provides an MCP interface to tasklite.net, a hosted backend and administration system for applications built by AI agents. Its core model is hierarchical: organizations contain projects, projects contain boards, and boards contain typed columns and items. Boards can represent task workflows or general data such as customers, products, and orders.

The server can create the underlying data model, populate it, expose it through REST endpoints, and support administration after deployment. A single backend can also handle app users, invitations, roles, access policies, comments, file attachments, automations, frontend deployments, and email-usage inspection.

## How it works

A typical build starts by selecting an organization, creating a project, and adding one or more boards. Columns define the schema and can include validation rules, closed-choice options, relations, formulas, files, contact fields, dates, currencies, and other types. Items are created with values keyed by column ID, which makes `get_board_schema` useful before writing data.

For a published application, the tools can create an app, define endpoints, choose exposed columns, configure row-level security, and generate an API key. Access can be based on ownership, sharing, phone identity, relations, or policy documents and roles. External-user registration can be open, approval-based, invite-only, or closed, with a configurable login URL.

The data tools include ordinary reads and writes as well as conditional cell updates. `get_cells` followed by `set_cells_if_unchanged` supports compare-and-set behavior so an update can fail instead of overwriting a newer value. Project exports provide JSON containing boards, schemas, and items for backups or migrations.

## Setup and configuration

Install the package globally with Node.js and register the `tasklite-mcp` binary with an MCP client. Claude Code setup uses:

```bash
npm install -g @anthropic-ai/claude-code @tasklite/mcp
claude mcp add tasklite -- tasklite-mcp
```

An existing account can authenticate with `TASKLITE_API_KEY`. The optional `TASKLITE_API_URL` and `TASKLITE_APP_URL` variables change the API and application URLs; their defaults point to tasklite.net services.

A local installation can create an account and organization through the account tools. Alternatively, the hosted endpoint at `https://mcp.tasklite.net/mcp` can be added to an HTTP-capable MCP client. Hosted connections use an authorization bearer token or OAuth through supported connectors, so no local package installation is needed.

## Tools and capabilities

- Create, inspect, modify, reorder, export, and delete projects, boards, columns, and rows.
- Apply column types, validation rules, required or hidden states, and closed-choice settings.
- Add comments, mentions, uploaded files, signature requests, automations, and push-status operations.
- Publish app endpoints with API keys, exposed fields, user links, invitations, roles, and row-level policies.
- Deploy frontend files and inspect or roll back deployments.
- Read access decisions, simulate requests, and review item history.

The package declares safety metadata for its tools, including read-only, destructive, idempotent, and open-world hints.

## Limitations and notes

List operations can be paginated. Projects return 50 entries per page, and unpaged item queries use a 50-item API page size even though the MCP tool can concatenate pages. Destructive operations such as deleting projects, boards, columns, items, comments, or upload links should be confirmed before use.

Upload links are usable without an account or API key by anyone who receives the URL, so their expiry and file-count limits should be kept short. Uploaded files remain attached after a link is revoked. Conditional cell writes apply only to ordinary writable columns, not relation, file, lookup, rollup, formula, button, or system columns.

_Full upstream README: https://allmcps.com/mcp/tasklite-3/readme_