Skip to main content
Glama

TaskLogger MCP

A Model Context Protocol server that gives AI agents programmatic access to TaskLogger.io tasks — create, update, search, assign, and complete tasks directly from an agent's toolset, no browser automation.

The server talks to the TaskLogger REST API (https://api.tasklogger.io/api/v1) over stdio. Tasks are TaskLogger logs with logTypeId = 2.

Features

  • Full task lifecycle — create, update, delete, mark done

  • Rich filtering — by status, priority, assignee, creator, problem type, category, company, vendor, date ranges, free-text search, and pagination

  • Reference lookups — statuses, priorities, problem types, categories, sub-types, users, departments, companies

  • Secure auth — password is read only from a local env file, never passed as a tool parameter

  • Token persistence — access/refresh tokens cached to disk and auto-refreshed across restarts

Related MCP server: pith

Tools

Tool

Purpose

login

Authenticate with credentials from env vars

logout

Clear saved tokens

status

Check the authenticated user

list_tasks

List/filter/search tasks

get_task

Get one task by ID

create_task

Create a task (defaults sub-type to Report Bug)

update_task

Update fields on a task

mark_task_done

Shortcut → Completed + 100%

delete_task

Delete a task

get_statuses / get_priorities / get_problem_types / get_task_categories / get_sub_types / get_users / get_departments / get_companies

Look up valid IDs

Tasks are identified by their numeric DB id in tool calls. TaskLogger also exposes a human-friendly transaction number (TN / trans_num) in responses, which is what humans usually quote — report TN to the user, pass the numeric id to the tools.

Requirements

  • Node.js 18+ (uses global fetch, FormData, crypto.randomUUID)

  • An account on a TaskLogger.io branch

Setup

# 1. Clone and install
git clone https://github.com/khodorrrhajjj/TaskLogger-Mcp.git
cd TaskLogger-Mcp
npm install

# 2. Build
npm run build          # outputs dist/index.js

3. Credentials

Create a local credential file (the server reads it on startup). It is created in your home directory, deliberately outside the repo, so it is never committed.

Create ~/.tasklogger-mcp/env:

TASKLOGGER_EMAIL=you@example.com
TASKLOGGER_PASSWORD=yourpassword
TASKLOGGER_BRANCH_ID=74
  • TASKLOGGER_PASSWORD is required and never passed as a tool parameter.

  • TASKLOGGER_BRANCH_ID selects the branch (only needed if you have multiple).

Alternatively, set the same keys as regular environment variables in your shell.

Connecting to an agent

OpenCode

Add to opencode.json (or your project/global config):

{
  "mcp": {
    "tasklogger": {
      "type": "stdio",
      "command": "node",
      "args": ["C:/Users/<you>/projects/TaskLogger-Mcp/dist/index.js"],
      "env": {}
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "tasklogger": {
      "command": "node",
      "args": ["C:/Users/<you>/projects/TaskLogger-Mcp/dist/index.js"]
    }
  }
}

Any other MCP client

Point it at node /absolute/path/to/tasklogger-mcp/dist/index.js over the stdio transport.

Usage examples

# List tasks pending, created by users 214/215
list_tasks  status_id="8" created_by="214,215"

# Search
list_tasks  search="product setup"

# Create a Task Logger bug report
create_task  problem_description="...bug..." problem_type_id="96" category_id="22" assigned_to_id="80"

# Update a task's status (TN 152 → Pending)
get_task  id=24077          # ← confirm the numeric id
update_task  id=24077 status_id="8"

Common status IDs: Pending = 8, To be tested = 10, Completed = 1, On Hold = 16. Sub-type Report Bug = 27. Always get_statuses / get_users to confirm current IDs.

How login works

  1. On startup the server reads ~/.tasklogger-mcp/env into the process environment (existing env vars win).

  2. On the first authenticated call it POSTs to /users/login with email, password, rememberMe: true, and branchId. It holds the two HttpOnly cookies the API returns:

    • accessToken — short-lived (~15 min) bearer

    • refreshToken — longer-lived (~7 days)

  3. Tokens are persisted to ~/.tasklogger-mcp/auth.json (chmod 0600) so a restart doesn't force a re-login.

  4. Before every request, if the accessToken is expired the server tries to refresh it (POST /users/refresh, fallback GET /users/authenticate), then falls back to a fresh env-file login.

  5. The dedicated login tool re-authenticates on demand; logout clears tokens from disk.

The password itself never appears in any tool parameter, MCP log, or conversation — only inside env.

Available Tools

17 tools
create_taskA

Create a new task. Only problem_description, problem_type_id, category_id, and assigned_to_id are required. sub_type_id defaults to 'Report Bug' (27). Any field not specified gets the TaskLogger default.

Inputs: category_id (required), assigned_to_id (required), problem_type_id (required), problem_description (required), +11 more.

delete_taskB

Delete a task by its numeric ID.

Inputs: id (required).

get_companiesA

Get available companies (for linking to tasks).

Inputs: no named parameters.

get_departmentsA

Get available departments.

Inputs: no named parameters.

get_prioritiesA

Get available priority levels.

Inputs: no named parameters.

get_problem_typesB

Get available problem types.

Inputs: no named parameters.

get_statusesB

Get available task statuses.

Inputs: no named parameters.

get_sub_typesB

Get available sub-types.

Inputs: no named parameters.

get_taskB

Get a single task by its numeric ID.

Inputs: id (required).

get_task_categoriesA

Get available task categories.

Inputs: no named parameters.

get_usersA

Get available users (for assignment).

Inputs: no named parameters.

list_tasksB

List tasks with pagination, search, and filters. Use get_users/get_statuses/get_priorities/get_problem_types first to find IDs. To mark done: set status_id to the Completed status ID and percentage to 100.

Inputs: page, due_to, search, sort_by, +16 more.

loginA

Authenticate to TaskLogger using credentials from environment variables (TASKLOGGER_EMAIL, TASKLOGGER_PASSWORD). No password is ever passed as a parameter — it stays in env vars only. Call after setting env vars or when tokens expire.

Inputs: email.

logoutA

Clear saved auth tokens. Next call will require login.

Inputs: no named parameters.

mark_task_doneA

Shortcut: mark a task as completed (status=Completed) with 100% progress.

Inputs: id (required).

statusA

Check if authenticated and which user is logged in.

Inputs: no named parameters.

update_taskA

Update an existing task. Only send fields you want to change.

Inputs: id (required), hint, notes, status_id, +11 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 17 tools

    Disambiguation5/5

    Each tool targets a distinct resource/action. The mark_task_done shortcut is clearly a convenience wrapper for update_task, not a competing operation, and all reference data getters are uniquely named.

    Naming Consistency4/5

    Most tools follow a consistent verb_noun pattern (create_task, update_task, delete_task, get_statuses). Minor deviations include list_tasks vs get_task and mark_task_done, but they remain intuitive.

    Tool Count4/5

    At 17 tools, the set is slightly above the ideal range, but the combination of CRUD, reference data lookups, and auth tools is appropriate for a task management system and each tool serves a clear purpose.

    Completeness5/5

    CRUD operations are fully covered, along with pagination, search, filtering, and necessary reference data for valid IDs. Auth lifecycle is complete with login/logout/status. No obvious gaps exist for task management workflows.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers