Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TASKLITE_API_KEYNoYour TaskLite API key (tl_xxx) for existing accounts. Not required if you plan to use the sign_up tool to create a new account.
TASKLITE_API_URLNoBase URL of the TaskLite API. Defaults to https://api.tasklite.nethttps://api.tasklite.net
TASKLITE_APP_URLNoBase URL of the TaskLite app. Defaults to https://app.tasklite.nethttps://app.tasklite.net

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
connection_statusA

Check whether this machine is connected to a TaskLite account. Call this first if any tool fails with an auth error.

sign_upA

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.

connectA

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.

loginA

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.

disconnectA

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_organizationsA

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

configure_external_accessA

Read or change how EXTERNAL users (people who sign up to your app through TaskLite auth: POST /auth/register-external with this organizationId, then POST /auth/login) get into an organization. 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); "closed" — invite only, self-signup refused. 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_projectsA

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_boardsA

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_projectB

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

create_boardA

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_columnA

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_schemaA

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

update_boardA

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

delete_boardA

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_projectA

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_columnA

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_columnA

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_columnsA

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

export_projectA

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_itemsA

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_itemA

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_itemC

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

set_cellA

Set a single cell value on an item by columnId.

delete_itemA

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

list_commentsA

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_commentA

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_commentA

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

delete_commentA

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

create_appA

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_statusA

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_pushA

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_appA

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

create_app_endpointA

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.

list_app_endpointsA

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_endpointA

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.

create_app_api_keyA

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_backendA

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: "", 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.

create_automationA

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, change_status, set_column_value, create_cross_board_item, send_webhook. 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.

list_automationsA

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

list_appsA

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_specA

Get the machine-readable spec of an app (base URL, endpoints, methods, fields) — use it to generate frontend API calls. 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_promptA

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.

searchA

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.

fetchA

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

deploy_frontendA

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). 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_deploymentsA

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

rollback_deploymentA

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

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 48 tools

Disambiguation4/5

Most tools target a distinct resource+action (projects, boards, columns, items, comments, apps, automations, deployments), and overlapping pairs like login/connect and query_items/search/fetch are separated by explicit credential/scope guidance. A few adjacent tools (build_backend vs the step-by-step creates, update_item vs set_cell) could be confused, but their descriptions call out when to use which.

Naming Consistency4/5

The set overwhelmingly follows verb_noun snake_case (list_projects, create_column, update_item, delete_board, rollback_deployment). Minor deviations exist — add_comment vs create_comment, query_items vs list_items, connection_status vs get_connection_status, and bare verbs like login/connect — but they are easy to predict and not chaotic.

Tool Count2/5

48 tools is a very large surface for one server, well beyond the 16-25 'heavy' range. Even with a broad scope spanning auth, schema design, apps, automations, and deployment, the count will force agents to browse and compare many similar CRUD tools.

Completeness3/5

Core workflows are well covered: projects/boards/columns have full CRUD, items and comments have full CRUD, and app endpoints plus deployment have create/list/update. But several lifecycle gaps stand out — automations can be created and listed but not updated/deleted, apps have no delete/unpublish/revoke-key operations, and projects cannot be renamed/updated.

Maintenance

ActivityMaintained
ResponsivenessNo issues