How do I use TaskTrek MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TaskTrek MCP Server create a high priority task to fix the login bug" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

TaskTrek MCP Server

by CsKoushik9

Overview Schema Related Servers Score Discussions

JavaScript

Local

TaskTrek MCP Server

A Model Context Protocol (MCP) server for TaskTrek project management system that enables AI assistants to interact with TaskTrek programmatically.

TaskTrek Web App: https://github.com/CsKoushik9/TaskTrek
TaskTrek MCP Server: https://github.com/CsKoushik9/TaskTrekMCP

Related MCP server: Filesystem MCP Server

Architecture Flow

┌─────────────────────┐    ┌──────────────────────┐    ┌─────────────────────┐
│   AI Assistant      │◄──►│   TaskTrek MCP       │◄──►│   JSON Files        │
│   (Claude, Cline)   │    │   Server (stdio)     │    │   (Data Storage)    │
└─────────────────────┘    └──────────────────────┘    └─────────────────────┘
                                      ▲                           ▲
                                      │                           │
                                      ▼                           ▼
                           ┌──────────────────────┐    ┌─────────────────────┐
                           │   MCP Tools          │    │   TaskTrek Web App  │
                           │   • create_task      │    │   (React Frontend)  │
                           │   • update_task      │    │   • Visual Interface│
                           │   • list_tasks       │    │   • Manual Editing  │
                           │   • summarize_tasks  │    │   • Analytics       │
                           │   • create_project   │    │   • Project Mgmt    │
                           │   • list_projects    │    └─────────────────────┘
                           │   • get_task         │
                           └──────────────────────┘

Data Flow:

AI Assistant sends commands via MCP protocol
MCP Server processes requests and updates JSON files
Web App reads from same JSON files for visual interface
Bidirectional Sync - changes in either interface persist

Usage Patterns:

AI-First: Use MCP server for automated task management
Visual-First: Use web app for manual task management
Hybrid: Switch between both as needed - data stays synced

Features

The TaskTrek MCP server provides the following tools:

1. `create_task`

Create a new task in TaskTrek with the following parameters:

title (required): Task title
description: Task description
projectId: Project ID (defaults to "default")
type: Task type (bug, feature, enhancement)
priority: Task priority (low, medium, high, critical)
componentId: Component ID
assigneeId: Assignee ID
labels: Array of task labels

2. `create_project`

Create a new project with:

name (required): Project name
key (required): Project key (e.g., "PROJ")
description: Project description

3. `update_task`

Update an existing task:

taskId (required): Task ID to update
title: New task title
description: New task description
status: New task status (screen, in-progress, code-review, code-complete, qa-verify, resolved)
priority: New task priority
componentId: New component ID
assigneeId: New assignee ID
labels: New task labels

4. `list_projects`

Get list of all available projects.

5. `list_tasks`

Get list of all tasks with optional filtering:

projectId: Filter by project ID
status: Filter by status
assigneeId: Filter by assignee ID

6. `get_task`

Get detailed information about a specific task:

taskId (required): Task ID to retrieve

7. `summarize_tasks`

Get a summary of tasks with statistics:

projectId: Filter by project ID (optional)

Prerequisites

Node.js (v14 or higher)
npm or yarn
TaskTrek Web App (optional, for visual interface)

Installation

Clone the repository:

git clone https://github.com/CsKoushik9/TaskTrekMCP.git
cd TaskTrekMCP

Install dependencies:

npm install

Verify the server runs correctly:

npm start

VS Code Integration Setup

For detailed VS Code integration with Cline extension, see the vscode-genai-setup.md file which provides:

Step-by-step Cline extension installation
MCP server configuration for VS Code
Alternative Claude Desktop setup
Test commands and troubleshooting

Quick VS Code Setup

Install the Cline extension in VS Code
Configure MCP server in Cline settings:

{
  "mcpServers": {
    "tasktrek": {
      "command": "node",
      "args": ["index.js"],
      "cwd": "/path/to/TaskTrekMCP"
    }
  }
}

Start the MCP server: npm start
Test with: "List all projects" in Cline chat

Usage

Running the Server

npm start

Development Mode

npm run dev

Data Storage & Synchronization

The MCP server stores data in JSON files in the ../TaskTrek/data/ directory:

tasks.json: All tasks
projects.json: All projects
components.json: All components
assignees.json: All assignees

Sync Behavior:

MCP Server: Writes directly to JSON files
Web App: Reads from JSON files on startup
No Conflicts: Both interfaces can be used independently
Data Persistence: Changes made in either interface persist

Running Both Interfaces:

# Terminal 1: Start MCP Server (for AI assistant)
cd TaskTrekMCP
npm start

# Terminal 2: Start Web App (for visual interface) - OPTIONAL
cd TaskTrek
npm start

Note: You don't need to run both simultaneously. Choose based on your workflow:

AI-only: Just run MCP server
Visual-only: Just run web app
Hybrid: Run both and switch as needed

Integration with MCP Clients

This server can be integrated with any MCP-compatible client. The server communicates via stdio and provides structured responses for all operations.

Example Usage

Creating a Task

{
  "tool": "create_task",
  "arguments": {
    "title": "Fix login bug",
    "description": "Users cannot login with special characters in password",
    "type": "bug",
    "priority": "high",
    "projectId": "default"
  }
}

Updating a Task Status

{
  "tool": "update_task",
  "arguments": {
    "taskId": "1234567890",
    "status": "in-progress"
  }
}

Getting Task Summary

{
  "tool": "summarize_tasks",
  "arguments": {
    "projectId": "default"
  }
}

Error Handling

The server provides detailed error messages for:

Invalid task/project IDs
Missing required parameters
Validation errors
File system errors

License

MIT License

Available Tools

7 tools

create_projectB

Create a new project in TaskTrek

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Project key (e.g., PROJ)
`name`	Yes	Project name
`description`	No	Project description

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It only says 'Create a new project' without mentioning idempotency, authentication, side effects, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but lacks structure for additional context. For a simple tool this is acceptable, but more details would improve usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations. Description does not explain return values, prerequisites, or what happens on creation. Incomplete for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 3 parameters have descriptions). Description adds no extra meaning beyond the schema, so baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Create' and resource 'project' in TaskTrek, distinguishing it from sibling tools like create_task, get_task, and list_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. Usage is implied by the tool's name and description, but no alternatives or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_taskC

Create a new task in TaskTrek

ParametersJSON Schema

Name	Required	Description
`type`	No	Task type
`title`	Yes	Task title
`labels`	No	Task labels
`priority`	No	Task priority
`projectId`	No	Project ID (optional, defaults to "default")
`assigneeId`	No	Assignee ID (optional)
`componentId`	No	Component ID (optional)
`description`	No	Task description

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the full burden of behavioral disclosure. It only states 'create', implying a write operation, but omits any details about side effects (e.g., validation, default assignments, error handling, or idempotency). This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and contains no wasted words. However, it is overly terse and could include more valuable context without significant length increase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, no output schema, no annotations), the description is incomplete. It does not explain what happens upon creation, response structure, validation rules, or defaults for optional parameters, leaving agents with significant ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 8 parameters with individual descriptions (100% coverage). The tool description adds no additional meaning beyond the schema baseline, so the score remains at 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new task, distinguishing it from sibling tools like get_task, list_tasks, and create_project. The verb 'create' and resource 'task' are explicit, but it lacks additional context such as the expected task properties or return behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as prerequisites for creating a task, default behaviors, or scenarios where create_task is preferred over update_task or list_tasks. There is no mention of when-not-to-use or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_taskB

Get detailed information about a specific task

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	Task ID to retrieve

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only states the tool retrieves information, but does not mention any traits such as read-only nature, required permissions, or absence of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and to the point, with no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with one parameter, the description is adequate but lacks any mention of the return value or additional context. It would benefit from stating what 'detailed information' includes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for taskId. The tool description adds no extra meaning beyond the schema, which is acceptable but not enhancing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the resource ('detailed information about a specific task'). It implies differentiation from sibling tools like list_tasks, which likely return summaries. However, it does not explicitly distinguish from other task-level tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as list_tasks (for multiple tasks) or update_task (for modifications). An agent must infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsA

Get list of all projects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It states it returns all projects, but omits details like pagination, order, or potential size, which are relevant for a list without parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words, front-loaded with the essential action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description should elaborate on return structure. It does not mention what fields each project contains, leaving the agent underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters; the description adds meaning by specifying 'all projects', indicating no filtering. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get' and resource 'list of all projects', distinguishing it from sibling tools which focus on tasks or creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; does not mention when not to use or provide any context about selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksB

Get list of all tasks with optional filtering

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter by status
`projectId`	No	Filter by project ID
`assigneeId`	No	Filter by assignee ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description does not disclose behavioral traits like pagination, sorting, rate limits, or whether all tasks are returned. The agent lacks critical execution details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence. It is concise and front-loaded, but could be slightly more informative without losing conciseness (e.g., mentioning output format).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 optional parameters and no output schema, the minimal description leaves gaps: no mention of pagination, sorting, or response structure. More context is needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no new meaning beyond 'optional filtering', which is already implied by optional params. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'list of all tasks', distinguishing it from sibling tools like get_task (single task) and create_task (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., get_task for a single task) or when not to use it. The phrase 'optional filtering' hints at use cases but lacks explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

summarize_tasksC

Get a summary of tasks with statistics

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	No	Filter by project ID (optional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'summarize' and 'statistics', which implies a read operation, but does not explicitly confirm read-only behavior, potential side effects, or what exactly is returned. For a tool with no annotations, this transparency is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise and front-loaded. However, it is somewhat under-specified. Still, it wastes no words and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a single optional parameter and no output schema. The description does not describe the return value (what statistics are included, format), which is a critical gap. A simple summary tool should at least hint at the output structure. This is inadequate given the lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (the single parameter projectId is described in the input schema). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already clarifies the parameter's role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource combination: 'Get a summary of tasks with statistics'. It clearly indicates that this tool returns aggregated data rather than individual tasks, distinguishing it from siblings like list_tasks or get_task. However, it could be more precise about the type of statistics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to favor it over list_tasks, or when not to use it. Given siblings like list_tasks and get_task, explicit context would help the agent choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_taskB

Update an existing task

ParametersJSON Schema

Name	Required	Description
`title`	No	New task title
`labels`	No	New task labels
`status`	No	New task status
`taskId`	Yes	Task ID to update
`priority`	No	New task priority
`assigneeId`	No	New assignee ID
`componentId`	No	New component ID
`description`	No	New task description

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as partial update semantics, idempotency, error handling (e.g., if task doesn't exist), or permissions required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence. It is concise but could potentially include more useful context without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 optional parameters, two enums, and no output schema, yet the description does not mention return values, update behavior (partial vs full), or error conditions. It is not complete for an AI agent to use reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, so the tool description adds no further meaning beyond 'update'. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update an existing task' clearly states the action (update) and the resource (task). It distinguishes itself from sibling tools like create_task, get_task, and list_tasks, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as create_task. No prerequisites (e.g., task must exist) or conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct resource (project vs task) and action (create, list, get, update, summarize), with no overlap. Even list_tasks and summarize_tasks serve different purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., create_project, list_tasks). The verbs are clear and the naming is predictable.

Tool Count5/5

7 tools is appropriate for a task/project management server, covering basic operations without being overwhelming or sparse.

Completeness2/5

The toolset is missing essential operations: no project update or delete, no task delete, no get_project. This leaves significant gaps in lifecycle management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2
LTD MCP
io.github.Eshller
Project management MCP for AI agents with safe task reads and writes.
Project Management Agent Orchestration
12

Related MCP Servers

Tiny TODO MCP
Knowledge & Memory Autonomous Agents
tkc
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides persistent task management capabilities for AI assistants, allowing them to create, update, and track tasks beyond their usual context limitations.
Updated a year ago (2025-03-23 13:24 UTC)
5
Filesystem MCP Server
File Systems Developer Tools
QuantGeekDev
F
license
Not graded
quality
F
maintenance
A Model Context Protocol server that extends AI capabilities by providing file system access and management functionalities to Claude or other AI assistants.
Updated a year ago (2025-03-17 00:45 UTC)
242
5
MCP Task Manager Server
Project Management Databases Developer Tools
bsmi021
A
license
A
quality
D
maintenance
A local Model Context Protocol server providing backend tools for AI agents to manage projects and tasks with persistent storage in SQLite, enabling structured tracking of project tasks with dependencies, priorities, and statuses.
Updated a year ago (2025-06-11 14:37 UTC)
12
13
25
GPL 3.0
Agentic Tools MCP Server
Project Management Developer Tools Code Execution
Pimzino
A
license
B
quality
D
maintenance
A Model Context Protocol server providing AI assistants with comprehensive project, task, and subtask management capabilities with project-specific storage.
Updated a year ago (2025-06-20 14:42 UTC)
29
38
88
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CsKoushik9/TaskTrekMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

TaskTrek MCP Server

Related Projects

Architecture Flow

Data Flow:

Usage Patterns:

Features

1. create_task

2. create_project

3. update_task

4. list_projects

5. list_tasks

6. get_task

7. summarize_tasks

Prerequisites

Installation

VS Code Integration Setup

Quick VS Code Setup

Usage

Running the Server

Development Mode

Data Storage & Synchronization

Sync Behavior:

Running Both Interfaces:

Integration with MCP Clients

Example Usage

Creating a Task

Updating a Task Status

Getting Task Summary

Error Handling

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `create_task`

2. `create_project`

3. `update_task`

4. `list_projects`

5. `list_tasks`

6. `get_task`

7. `summarize_tasks`