Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@task-manager-mcp show active tasks in project 'my-project'"
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.
MCP (Model Context Protocol) сервер для управления задачами в проектах с AI ассистентами, такими как Claude Code или Gemini CLI.
Поддержка нескольких проектов: Управление задачами для множества проектов из единой корневой директории
Структурированное управление: Задачи организованы в папки активных и завершенных
Автоматическая нумерация: Задачи автоматически нумеруются последовательно
Богатые метаданные: Отслеживание статуса, приоритета, дат и зависимостей
Формат Markdown: Все задачи хранятся в читаемом формате markdown
Git-friendly: Идеально подходит для контроля версий
Оптимизация для AI: Специально разработано для работы с AI ассистентами
Related MCP server: Task Manager MCP Server
Node.js >= 16.0.0
npm или yarn
Клонируйте или скачайте этот репозиторий
Установите зависимости:
npm installСоберите проект:
npm run buildДобавьте это в конфигурационный файл Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"task-manager": {
"command": "node",
"args": ["/абсолютный/путь/к/task-manager-mcp/dist/index.js"],
"env": {
"TASK_MANAGER_ROOT": "/путь/к/вашей/корневой/папке/задач"
}
}
}
}Важно: Замените /абсолютный/путь/к/task-manager-mcp на фактический путь к этому проекту, а /путь/к/вашей/корневой/папке/задач на директорию, где вы хотите хранить задачи.
Если TASK_MANAGER_ROOT не указан, по умолчанию используется ~/task-manager.
Для локальной настройки можно использовать шаблон .env.example как референс.
После обновления конфигурации перезапустите Claude Desktop, чтобы изменения вступили в силу.
init_projectИнициализирует новый проект со структурой управления задачами.
Параметры:
projectName (string, обязательный): Название проекта
Пример:
Пожалуйста, инициализируй проект "my-website"create_taskСоздает новую задачу в проекте.
Параметры:
projectName (string, обязательный): Название проекта
title (string, обязательный): Название задачи
description (string, опциональный): Подробное описание
priority (enum, опциональный): LOW, MEDIUM (по умолчанию), или HIGH
dependencies (array, опциональный): Список номеров задач, от которых зависит эта
Пример:
Создай задачу в проекте "my-website":
Название: Реализовать аутентификацию пользователей
Описание: Добавить JWT-аутентификацию с логином и регистрацией
Приоритет: HIGHlist_tasksПоказывает список задач в проекте.
Параметры:
projectName (string, обязательный): Название проекта
status (enum, опциональный): ACTIVE (по умолчанию), COMPLETED, или ALL
priority (enum, опциональный): Фильтр по LOW, MEDIUM, или HIGH
Пример:
Покажи все активные задачи в проекте "my-website"get_taskПолучает полную информацию о конкретной задаче.
Параметры:
projectName (string, обязательный): Название проекта
taskNumber (string, обязательный): Номер задачи (например, "001", "042")
Пример:
Покажи задачу 001 из проекта "my-website"update_taskОбновляет существующую задачу.
Параметры:
projectName (string, обязательный): Название проекта
taskNumber (string, обязательный): Номер задачи
status (enum, опциональный): TODO, IN_PROGRESS, или COMPLETED
priority (enum, опциональный): LOW, MEDIUM, или HIGH
technicalSolution (string, опциональный): Техническое решение
implementation (string, опциональный): Детали реализации
testResults (string, опциональный): Результаты тестирования
Пример:
Обнови задачу 001 в "my-website":
- Статус: IN_PROGRESS
- Техническое решение: Использование Passport.js с JWT стратегиейcomplete_taskОтмечает задачу как завершенную и перемещает в папку завершенных.
Параметры:
projectName (string, обязательный): Название проекта
taskNumber (string, обязательный): Номер задачи
commitMessage (string, опциональный): Кастомное сообщение коммита (генерируется автоматически, если не указано)
Пример:
Отметь задачу 001 как завершенную в проекте "my-website"list_projectsПоказывает список всех доступных проектов.
Пример:
Покажи все проектыПосле инициализации каждый проект имеет следующую структуру:
task-manager-root/
└── название-проекта/
├── active/
│ └── task-NNN.md
├── completed/
│ ├── task-NNN.md
│ └── INDEX.md
└── PLAN.mdactive/: Задачи в работе или запланированные
completed/: Завершенные задачи с полной историей
PLAN.md: Обзор всех задач
INDEX.md: Индекс завершенных задач
Каждая задача - это markdown файл со следующей структурой:
# Task-001: Название задачи
## Метаданные
- **Статус**: 📋 TODO / 🔄 IN_PROGRESS / ✅ COMPLETED
- **Приоритет**: LOW / MEDIUM / HIGH
- **Создано**: 2025-01-15
- **Начато**: -
- **Завершено**: -
- **Зависимости**: -
---
## Описание проблемы
[Подробное описание проблемы или функциональности]
## Техническое решение
[Технический подход и архитектура]
## Реализация
[Детали реализации и прогресс]
## Тестирование
### Тест-кейсы
- [ ] Тест-кейс 1
- [ ] Тест-кейс 2
### Результаты
[Результаты тестирования]
## Результат
**Коммит**: -
**Деплой**: -Создать задачу используя create_task
Посмотреть список задач чтобы увидеть что нужно сделать
Получить детали задачи при начале работы
Обновить задачу с техническим решением и пометить как IN_PROGRESS
Обновлять задачу с деталями реализации в процессе работы
Обновить задачу с результатами тестирования
Завершить задачу когда закончите - она переместится в completed
Закоммитить изменения используя предложенное сообщение коммита
Система генерирует сообщения коммитов в следующем формате:
[prefix] task-NNN: описаниеПрефиксы:
feat - Новая функциональность
fix - Исправление бага
tune - Оптимизация или улучшение
docs - Документация
refactor - Рефакторинг кода
task-manager-mcp/
├── src/
│ ├── index.ts # Точка входа
│ ├── server.ts # Реализация MCP сервера
│ ├── types/
│ │ └── index.ts # TypeScript типы
│ ├── services/
│ │ ├── file-system.ts # Операции с файлами
│ │ ├── project-manager.ts # Управление проектами
│ │ └── task-manager.ts # Операции с задачами
│ └── templates/
│ └── task-template.ts # Шаблоны файлов задач
├── dist/ # Скомпилированный JavaScript
├── package.json
├── tsconfig.json
└── README.mdnpm run build - Сборка TypeScript в JavaScript
npm run watch - Режим наблюдения для разработки
npm start - Запуск сервера напрямую
Вы можете протестировать сервер вручную:
# Установите корневую директорию
export TASK_MANAGER_ROOT=/путь/к/вашим/задачам
# Запустите сервер
npm startСервер запустится и будет слушать MCP команды через stdio.
Проверьте что путь к конфигурационному файлу корректный
Убедитесь что абсолютные пути в конфиге правильные
Перезапустите Claude Desktop
Проверьте логи Claude Desktop на наличие ошибок
Убедитесь что путь TASK_MANAGER_ROOT существует и доступен для записи
Проверьте что вы инициализировали проект с помощью init_project
Проверьте что у вас есть права на запись в директорию
Убедитесь что используете Node.js >= 16.0.0
Удалите директории node_modules и dist
Запустите npm install снова
Запустите npm run build
Это персональный проект-шаблон. Не стесняйтесь форкать и адаптировать под свои нужды.
MIT License - свободно используйте в любых проектах.
Создано для рабочего процесса AI-assisted разработки с Claude Code и Gemini CLI.
Версия: 1.0.0 Последнее обновление: 2025-11-12
Mark a task as completed and move it to completed directory
| Name | Required | Description | Default |
|---|---|---|---|
| taskNumber | Yes | Task number to complete | |
| projectName | Yes | Name of the project | |
| commitMessage | No | Custom commit message (optional, will be auto-generated if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a meaningful behavioral trait (relocation to a completed directory) but omits whether the action is reversible, what side effects occur, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean sentence with no filler; the core action and the directory side effect are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Reasonable for a simple mutation: required parameters and the optional auto-generated commitMessage are documented in the schema, and the description covers the key side effect. Missing return-value and reversibility details would matter for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all three parameters (projectName, taskNumber, commitMessage) are already described in the schema. The description adds no parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Mark a task as completed') and adds the salient side effect ('move it to completed directory'). This clearly differentiates it from siblings like create_task, get_task, and list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 only implied by the action verb; an agent can infer this completes an existing task, but the description never points to alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in a project
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Task title | |
| priority | No | Task priority (default: MEDIUM) | |
| description | No | Task description (optional) | |
| projectName | Yes | Name of the project | |
| dependencies | No | List of task dependencies (task numbers) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description reveals only that a task is created, but does not state what happens on success, whether a task number is assigned, whether duplicates are permitted, whether the referenced project must exist, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste, front-loading the action verb. It is appropriately concise, though slightly under-specified; it earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 2 required, an enum, no output schema, and no annotations, the single-sentence description does not provide enough context for correct invocation. It omits details like the meaning of dependencies ('task numbers'), project existence requirements, and return behavior. The description is adequate for identifying the operation but incomplete for reliable execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented structurally. The description adds no additional parameter meaning beyond the schema, which is acceptable at baseline 3 given the high coverage. The phrase 'in a project' hints at projectName's role, but that is already stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a new task in a project'. The verb 'create' clearly distinguishes it from read operations (get_task, list_tasks) and other mutations (update_task, complete_task) among siblings. However, it is minimal and does not add scope details beyond what the tool name already implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., whether the project must already exist via init_project) or exclusions (e.g., use update_task for modifying existing tasks). The agent must infer usage context solely from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific task
| Name | Required | Description | Default |
|---|---|---|---|
| taskNumber | Yes | Task number (e.g., "001", "042") | |
| projectName | Yes | Name of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get full details.' It does not state that this is a read-only operation, what happens when the task is not found, or any error/authorization behavior. The minimal wording provides little beyond the tool's basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. The core action is front-loaded and easy to parse, though the brevity also contributes to the lack of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify what 'full details' includes or at least suggest the response shape. It does not, and it also omits guidance on required identifier combinations or failure behavior, leaving an agent to guess at the return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both taskNumber and projectName with examples. The description adds no extra parameter context, so the baseline of 3 applies—it does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: get full details of a specific task. This distinguishes it from list_tasks (which lists tasks) and create/update/complete (which mutate tasks), though it doesn't explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_tasks or other siblings. The usage context is only implied by the verb 'get' and the word 'specific', but no explicit conditions, exclusions, or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new project with task management structure
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Name of the project to initialize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'initialize' and 'task management structure' but does not disclose side effects, idempotency, whether an existing project is overwritten, or what happens on failure. For a mutating tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The core verb and resource appear first, and 'with task management structure' adds useful context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations and no output schema, the description should at least indicate return behavior or post-conditions. It does not explain what 'initialized' means operationally, whether a project ID is returned, or how success is communicated. An agent is left guessing at the result of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and projectName is self-describing in the schema. The description adds no new constraints, format expectations, or naming rules, but the schema already documents the sole parameter sufficiently, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Initialize') and resource ('a new project') and adds scope ('with task management structure'), making its purpose clear. It distinguishes itself from the task-focused siblings (create_task, update_task, etc.) by targeting project bootstrap rather than task operations, though it does not explicitly contrast with list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description implies it should be used before task operations, but it never states prerequisites, whether projects should already exist, or when list_projects would be the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available projects
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. 'List all available projects' clearly implies a read-only enumeration and scopes the result set to 'all available,' but it does not mention response format, ordering, pagination, or whether 'available' excludes archived projects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four words, front-loaded with the action, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is minimally sufficient: an agent can invoke it without ambiguity. However, with no output schema and no annotations, it would be stronger if it noted what fields are returned or clarified the meaning of 'available.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description's 'all available' reinforces the lack of filtering or required arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all available projects.' It clearly distinguishes this tool from siblings like list_tasks and create_task, so an agent can immediately tell what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives, such as using it to fetch project IDs before create_task or get_task. The intended context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks in a project
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status (default: ACTIVE) | |
| priority | No | Filter by priority (optional) | |
| projectName | Yes | Name of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not mention default filtering behavior, pagination, result format, or authentication requirements. The phrase 'all tasks' also conflicts with the schema's implicit ACTIVE default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler words. It is front-loaded with the main action and resource, though the word 'all' could be more precise given the ACTIVE default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple list operation with all parameters fully documented in the schema. Still, there is no output schema and no mention of default behavior or result shape, so an agent must infer what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds no additional meaning about status, priority, or projectName beyond what the schema provides, which is acceptable at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List all tasks in a project.' It is distinguishable from siblings like get_task and list_projects by naming the project scope. However, 'all tasks' is slightly imprecise because the default status filter is ACTIVE, not ALL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as get_task or list_projects. There are no exclusions, alternatives, or contextual hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Update task status | |
| priority | No | Update task priority | |
| taskNumber | Yes | Task number to update | |
| projectName | Yes | Name of the project | |
| testResults | No | Test results | |
| implementation | No | Implementation details | |
| technicalSolution | No | Technical solution description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Update an existing task' only conveys basic mutation semantics. It does not state what happens when the task does not exist, whether partial updates are supported, whether updates are reversible, what the response looks like, or any validation behavior — significant gaps for a write operation with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with the core action. However, for a tool with 7 parameters, no annotations, and no output schema, this brevity crosses into under-specification rather than genuine conciseness — it is short but leaves too much unsaid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 2 enums, sibling overlap with complete_task) and the absence of both annotations and an output schema, the description is far from complete. It fails to clarify partial-update semantics, failure behavior on missing tasks, return value, or the relationship to sibling tools, all of which an agent would need for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies even though the description itself adds no parameter-level detail. The description does not compensate with syntax, ordering, or constraint hints, but the schema already documents each of the 7 parameters adequately, including enums for status and priority.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Update an existing task') and is clearly distinguishable from create_task, get_task, list_tasks, and init_project. However, it does not differentiate from the sibling complete_task, which is plausibly a specialized form of updating (marking a task as completed), so the agent cannot tell when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, notably no explicit distinction from complete_task or any statement about whether update_task is the generic status-update path. There is no mention of prerequisites, such as the task needing to exist first, so an agent must infer usage entirely from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0complete_taskcreate_taskget_taskinit_projectlist_projectslist_tasksupdate_taskEach tool maps to a distinct resource/action pair: project setup, task CRUD, and task completion. complete_task is a specific state transition rather than a duplicate of update_task, so there is no real ambiguity.
All tools follow a consistent verb_noun snake_case pattern, such as create_task, get_task, list_tasks, and init_project. The list_* prefix consistently indicates collection queries, making the set predictable.
Seven tools is a well-scoped size for a task manager. Each tool serves a clear purpose without redundancy or bloat.
The core task lifecycle is covered: create, read, list, update, and complete, plus project initialization and listing. Missing delete operations and deeper project management are gaps, but agents can still complete typical task management workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aderevyankin/task-manager-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
