TaskLogger MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TASKLOGGER_EMAIL | Yes | Email address for TaskLogger login | |
| TASKLOGGER_PASSWORD | Yes | Password for TaskLogger login (required, never passed as a tool parameter) | |
| TASKLOGGER_BRANCH_ID | No | Branch ID for TaskLogger (only needed if you have multiple branches) |
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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| mark_task_doneA | Shortcut: mark a task as completed (status=Completed) with 100% progress. |
| get_taskB | Get a single task by its numeric ID. |
| 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. |
| update_taskA | Update an existing task. Only send fields you want to change. |
| delete_taskB | Delete a task by its numeric ID. |
| get_statusesB | Get available task statuses. |
| get_prioritiesA | Get available priority levels. |
| get_problem_typesB | Get available problem types. |
| get_task_categoriesA | Get available task categories. |
| get_sub_typesB | Get available sub-types. |
| get_usersA | Get available users (for assignment). |
| get_departmentsA | Get available departments. |
| logoutA | Clear saved auth tokens. Next call will require login. |
| statusA | Check if authenticated and which user is logged in. |
| get_companiesA | Get available companies (for linking to tasks). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
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.
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.
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.
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.