de en es ja ko ru zh

Task Tracker MCP Server

Name: Task Tracker MCP Server
Author: azamafridi23

by azamafridi23

Overview Schema Source Related Servers Discussions Admin

Python

Remote

📋 Task Tracker MCP 서버

Python으로 FastMCP를 사용하고 uv로 관리되는 실용적인 Model Context Protocol (MCP) 서버입니다. 이 서버는 AI 어시스턴트(Claude Desktop, Cursor, Antigravity 등)에게 구조화된 작업 관리 기능을 제공합니다.

🌟 개요

Model Context Protocol (MCP) 는 LLM과 AI 애플리케이션이 외부 도구 및 데이터 소스와 안전하고 원활하게 상호작용할 수 있도록 하는 개방형 표준입니다.

이 프로젝트는 세 가지 핵심 MCP 프리미티브를 구현합니다:

🛠️ 도구(Tools): 모델이 작업을 수행할 수 있도록 호출 가능한 함수 (add_task, complete_task, delete_task).
📦 리소스(Resources): 모델이 상태를 검사할 수 있는 읽기 전용 데이터 URI (tasks://all, tasks://pending).
💡 프롬프트(Prompts): AI가 복잡한 워크플로(예: 작업 분석 및 우선순위 지정)를 수행하도록 안내하는 사전 정의된 프롬프트 템플릿.

flowchart LR
    Host["AI Host / Application<br/>(Claude Desktop / Cursor / Antigravity)"] 
    Client["MCP Client<br/>(Protocol Handler)"]
    Server["Task Tracker MCP Server<br/>(FastMCP)"]
    
    Host <--> Client
    Client <--> Server
    
    subgraph ServerCapabilities ["Server Capabilities"]
        Tools["🛠️ Tools<br/>add_task, complete_task, delete_task"]
        Resources["📦 Resources<br/>tasks://all, tasks://pending"]
        Prompts["💡 Prompts<br/>task_summary_prompt"]
    end
    
    Server --- ServerCapabilities

Related MCP server: MCP Task Management Server

🚀 기능 및 MCP 프리미티브

1. 도구 (Actions)

도구	인수	설명
`add_task`	`title: str`, `description: str = ""`	고유 ID와 ISO 타임스탬프를 사용하여 새 작업을 추가합니다.
`complete_task`	`task_id: int`	작업 상태를 `"completed"`로 표시하고 완료 타임스탬프를 추가합니다.
`delete_task`	`task_id: int`	ID로 작업을 제거하고 삭제된 객체를 반환합니다.

2. 리소스 (읽기 전용 데이터)

리소스 URI	설명
`tasks://all`	모든 작업을 이모지(`✅` 완료, `⏳` 대기 중)와 함께 포맷하여 반환합니다.
`tasks://pending`	활성/대기 중인 작업만 필터링하여 반환합니다.

3. 프롬프트 (안내 워크플로)

프롬프트	설명
`task_summary_prompt`	AI 어시스턴트가 대기 중인 작업과 완료된 작업을 분석하고, 지연된 항목을 식별하며, `tasks://all`을 사용하여 다음 조치를 추천하도록 안내합니다.

📦 `uv`로 시작하기

이 프로젝트는 Astral이 Rust로 작성한 초고속 Python 패키지 및 프로젝트 관리자인 uv 로 구축 및 관리됩니다.

1. `uv` 설치

macOS / Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

설치 확인:

uv --version

2. 저장소 복제 및 설정

git clone https://github.com/<your-username>/task-tracker-mcp.git
cd task-tracker-mcp

3. 의존성 설치

uv가 자동으로 가상 환경(.venv)을 생성하고 필요한 모든 의존성을 설치합니다:

uv sync

🧪 서버 테스트

모든 도구, 리소스 및 프롬프트를 실행하는 내장 비동기 클라이언트(test_client.py)를 실행할 수 있습니다:

uv run test_client.py

예상 출력:

🚀 Starting FastMCP Test Client...
==================================================

1. Listing Available Tools:
   Found 3 tools: ['add_task', 'complete_task', 'delete_task']

2. Calling 'add_task' Tool:
   Task 1 Response: {"id":1,"title":"Learn MCP", ...}
   Task 2 Response: {"id":2,"title":"Master uv", ...}

3. Listing Available Resources:
   Found 2 resources: [AnyUrl('tasks://all'), AnyUrl('tasks://pending')]

4. Reading 'tasks://all' Resource:
   Current Tasks:
   ⏳ [1] Learn MCP
   ⏳ [2] Master uv

5. Completing Task ID 1:
   Completed Result: {"id":1, "status":"completed", ...}

6. Reading 'tasks://pending' Resource:
   Pending Tasks:
   ⏳ [2] Master uv

7. Listing Available Prompts:
   Found 1 prompts: ['task_summary_prompt']

8. Deleting Task ID 2:
   Delete Result: {"success": true, "deleted": {"id": 2, ...}}

==================================================
✨ All MCP Server tests completed successfully!

🔌 연결 및 검사

1. FastMCP CLI 검사기 및 개발 도구

FastMCP 3.x는 서버를 검사하고 디버깅하기 위한 내장 CLI 명령을 제공합니다:

대화형 웹 검사기:

uv run fastmcp dev inspector task_server.py

서버 요약 검사:
```
uv run fastmcp inspect task_server.py
```
모든 도구 나열:
```
uv run fastmcp list task_server.py
```
독립 실행형 서버 실행:
```
uv run fastmcp run task_server.py
```

2. Claude Desktop 통합

claude_desktop_config.json에 서버 구성을 추가하세요:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "task-tracker": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/task-tracker-mcp",
        "run",
        "task_server.py"
      ]
    }
  }
}

📁 프로젝트 구조

Task Tracker MCP/
├── pyproject.toml         # Dependency & project metadata (managed by uv)
├── task_server.py         # MCP Server definitions (tools, resources, prompts)
├── test_client.py         # FastMCP async automated test client
├── src/
│   └── task_tracker_mcp/  # Python package entrypoint
│       └── __init__.py
├── .python-version        # Locked Python version
├── .gitignore             # Python & uv exclusions
└── README.md              # Documentation

💡 주요 `uv` 명령어 치트 시트

명령어	설명
`uv init`	`pyproject.toml`로 새 Python 프로젝트 초기화
`uv add <pkg>`	`pyproject.toml`에 의존성 추가 및 `.venv`에 설치
`uv remove <pkg>`	의존성 제거
`uv run <script.py>`	격리된 프로젝트 환경 내에서 Python 스크립트 실행
`uv sync`	`uv.lock`과 설치된 패키지 동기화
`uv venv`	가상 환경 명시적으로 생성

🛠️ 다음 단계 및 확장

영구 저장소: 인메모리 리스트를 aiosqlite 또는 sqlite3를 통한 SQLite로 대체.
우선순위 및 마감일: 작업 우선순위 플래그(low, medium, high) 및 마감일 필터 추가.
검색 도구: 제목과 설명을 검색하는 search_tasks(query: str) 도구 추가.
인증: FastMCP 인증 제공자로 엔드포인트 보호.

📄 라이선스

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 LICENSE 파일을 참조하세요.

Available Tools

3 tools

add_taskC

Add a new task to the task list.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/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 the full behavioral burden. 'Add' implies a mutation, but nothing is said about required permissions, duplicate handling, defaults for description, or state side effects — a significant gap for a write tool.

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?

A single front-loaded sentence with no wasted words, but it is under-specified rather than appropriately concise for a mutation tool with two undocumented parameters.

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?

An output schema exists, so return values need not be described. Still, with no annotations and 0% parameter coverage, the definition leaves an agent without enough behavioral or parameter context to reliably invoke a write operation.

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

Parameters1/5

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

Schema description coverage is 0% and the description never mentions any parameter. It does not clarify that 'title' is required or that 'description' defaults to an empty string, so it adds no parameter meaning beyond the raw schema.

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?

States a clear verb ('Add') and resource ('a new task to the task list'), so the agent can tell it apart from delete_task and complete_task by operation. However, it offers no differentiation language or scope detail beyond the obvious create/delete/complete split.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as complete_task for status changes. The agent gets a bare purpose statement and must infer all invocation context.

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

complete_taskC

Mark a task as completed.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

Annotations are absent, so the description carries the full behavioral burden. It conveys that this is a state mutation but omits whether the call is idempotent, what happens if the task is already completed, permission requirements, and whether the change is reversible.

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?

A single front-loaded sentence with zero filler, but so terse that it omits information an agent needs rather than being efficiently dense.

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?

The tool is simple, one required integer parameter, and an output schema exists so return values need not be described. Still, a mutation with no annotations and no parameter documentation leaves gaps around idempotency and error conditions.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the undocumented task_id. It only implies 'a task' without stating the identifier format, valid range, or behavior when the id does not exist.

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?

States a specific verb+resource: 'Mark a task as completed.' An agent immediately knows the operation. However, it offers no differentiation from siblings like delete_task or add_task, which are the plausible confusions for a task-status mutation.

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 when-to-use guidance, no mention of alternatives, and no note on the distinction between completing and deleting a task. Usage is only weakly implied by the verb.

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

delete_taskC

Delete a task from the list.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/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 the full burden of behavioral disclosure. "Delete" implies a destructive mutation but the description says nothing about irreversibility, required permissions, or what happens to the task afterward — significant gaps for a destructive tool.

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?

A single short sentence with no waste and the action front-loaded, which suits a one-parameter tool. However, the brevity comes at the cost of substance rather than being a model of economical communication.

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?

An output schema exists, so return values need not be explained. But for a destructive mutation with zero annotations and an undocumented parameter, the description omits the safety and side-effect context an agent needs before invoking it.

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

Parameters2/5

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

Schema description coverage is 0% and the description adds no meaning for task_id beyond what the name implies. The single required integer parameter is nearly self-evident, but nothing explains its origin or format, so the description fails to compensate for the schema gap.

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?

States a specific verb and resource ("Delete a task"), which is unambiguous against siblings add_task and complete_task, whose verbs already differ. It stops short of explicitly naming those siblings or the scope of deletion, but an agent can distinguish it readily.

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 when-to-use guidance, no prerequisites, and no alternatives named. The agent gets no signal about when deleting is appropriate versus completing or leaving a task alone.

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

Tool Schema Changelog

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

3 tool updatesv0.1.0Sep 11, 2026
- First observedadd_task
- First observedcomplete_task
- First observeddelete_task

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3/5.0

Scored 2026-09-11 09:05 across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct action on a task: add, delete, complete. There is no overlap or ambiguity between them, so an agent can easily select the right tool.

Naming Consistency5/5

All three tools follow the exact same verb_noun snake_case pattern (add_task, delete_task, complete_task). Naming is fully predictable.

Tool Count4/5

Three tools is a reasonable, well-scoped set for a minimal task tracker, and each earns its place. It is slightly thin, since a small surface like this leaves little room for the read/lifecycle operations expected of the domain.

Completeness3/5

The set covers create, delete, and a status update, but there is no way to list or retrieve tasks, which is arguably the most essential operation for a tracker. This is a notable gap that will leave agents unable to inspect the task list.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CalmLoop Task Manager
in.calmloop
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Project Management Note Taking
1
GetItDone AOAuth
com.nowgetitdone
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Autonomous Agents Project Management
21
Tack
io.github.Thefirstmannnn
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
1
Orbit BOAuth
io.github.Noveum
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
94130

Related MCP Servers

google-tasks-mcp
Project Management Workplace & Productivity
scottie-will
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Google Tasks, including listing, creating, updating, deleting, and completing tasks via the Google Tasks API.
Updated 6 months ago (2026-04-29 22:01 UTC)
27 npm
MIT
MCP Task Management Server
Project Management Developer Tools
jimfisher
F
license
A
quality
D
maintenance
Enables comprehensive task management with groups, custom statuses, and task relationships, designed for AI assistants to manage tasks during conversations.
Updated a year ago (2025-09-24 22:22 UTC)
17
-
Todo MCP Server
Project Management
X4MU-L
A
license
A
quality
D
maintenance
Enables AI assistants to manage a todo list with add, list, complete, and delete tasks.
Updated 10 months ago (2026-01-05 16:34 UTC)
4
4 npm
MIT
Node.js To-Do MCP Server
Workplace & Productivity Project Management
Alessandro-Massarotti-Jr
A
license
Not graded
quality
D
maintenance
Enables to manage to-do items through natural language, with tools for creating, reading, updating, and deleting tasks.
Updated 3 months ago (2026-07-14 00:14 UTC)
ISC

📋 Task Tracker MCP 서버

🌟 개요

🚀 기능 및 MCP 프리미티브

1. 도구 (Actions)

2. 리소스 (읽기 전용 데이터)

3. 프롬프트 (안내 워크플로)

📦 uv로 시작하기

1. uv 설치

2. 저장소 복제 및 설정

3. 의존성 설치

🧪 서버 테스트

예상 출력:

🔌 연결 및 검사

1. FastMCP CLI 검사기 및 개발 도구

2. Claude Desktop 통합

📁 프로젝트 구조

💡 주요 uv 명령어 치트 시트

🛠️ 다음 단계 및 확장

📄 라이선스

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

📦 `uv`로 시작하기

1. `uv` 설치

💡 주요 `uv` 명령어 치트 시트