Task Tracker MCP Server
Click on "Deploy 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 Tracker MCP ServerAdd a task to buy groceries"
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.
๐ Task Tracker MCP Server
A practical Model Context Protocol (MCP) server built in Python using FastMCP and managed with uv. This server provides AI assistants (like Claude Desktop, Cursor, Antigravity, etc.) with structured task management capabilities.
๐ Overview
The Model Context Protocol (MCP) is an open standard that allows LLMs and AI applications to interact safely and seamlessly with external tools and data sources.
This project implements the three core MCP primitives:
๐ ๏ธ Tools: Callable functions allowing the model to perform actions (
add_task,complete_task,delete_task).๐ฆ Resources: Read-only data URIs allowing the model to inspect state (
tasks://all,tasks://pending).๐ก Prompts: Predefined prompt templates that guide the AI to perform complex workflows (e.g., task analysis & prioritization).
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 --- ServerCapabilitiesRelated MCP server: MCP Task Management Server
๐ Features & MCP Primitives
1. Tools (Actions)
Tool | Arguments | Description |
|
| Adds a new task with a unique ID and ISO timestamp. |
|
| Marks a task status as |
|
| Removes a task by ID and returns the deleted object. |
2. Resources (Read-Only Data)
Resource URI | Description |
| Formats and returns all tasks with emojis ( |
| Filters and returns only active/pending tasks. |
3. Prompts (Guided Workflows)
Prompt | Description |
| Guides the AI assistant to analyze pending vs completed tasks, identify overdue items, and recommend next actions using |
๐ฆ Getting Started with uv
This project is built and managed with uv, an extremely fast Python package and project manager written in Rust by Astral.
1. Install uv
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Verify installation:
uv --version2. Clone and Setup Repository
git clone https://github.com/<your-username>/task-tracker-mcp.git
cd task-tracker-mcp3. Install Dependencies
uv will automatically create a virtual environment (.venv) and install all required dependencies:
uv sync๐งช Testing the Server
You can run the built-in async client (test_client.py) which exercises every tool, resource, and prompt:
uv run test_client.pyExpected Output:
๐ 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!๐ Connecting & Inspecting
1. FastMCP CLI Inspector & Dev Tools
FastMCP 3.x provides built-in CLI commands to inspect and debug your server:
Interactive Web Inspector:
uv run fastmcp dev inspector task_server.pyInspect Server Summary:
uv run fastmcp inspect task_server.pyList All Tools:
uv run fastmcp list task_server.pyRun Standalone Server:
uv run fastmcp run task_server.py
2. Claude Desktop Integration
Add the server configuration to your 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"
]
}
}
}๐ Project Structure
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๐ก Key uv Commands Cheat Sheet
Command | Description |
| Initialize a new Python project with |
| Add a dependency to |
| Remove a dependency |
| Run any Python script within the isolated project environment |
| Sync installed packages with |
| Create a virtual environment explicitly |
๐ ๏ธ Next Steps & Extensions
Persistent Storage: Replace in-memory list with SQLite via
aiosqliteorsqlite3.Priority & Due Dates: Add task priority flags (
low,medium,high) and due date filters.Search Tool: Add a
search_tasks(query: str)tool to search title and descriptions.Authentication: Secure endpoints with FastMCP auth providers.
๐ License
This project is licensed under the MIT License - see the LICENSE file for details.
Available Tools
3 toolsadd_taskC
Add a new task to the task list.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 updates
v0.1.0- First observed
add_task - First observed
complete_task - First observed
delete_task
TDQS
Scored across 3 tools
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.
All three tools follow the exact same verb_noun snake_case pattern (add_task, delete_task, complete_task). Naming is fully predictable.
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.
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
Related MCP Connectors
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
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.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to manage Google Tasks, including listing, creating, updating, deleting, and completing tasks via the Google Tasks API.31 npmMIT
- FlicenseAqualityDmaintenanceEnables comprehensive task management with groups, custom statuses, and task relationships, designed for AI assistants to manage tasks during conversations.17-
- AlicenseAqualityDmaintenanceEnables AI assistants to manage a todo list with add, list, complete, and delete tasks.412 npmMIT
- FlicenseNot gradedqualityCmaintenanceEnables to manage to-do items through natural language, with tools for creating, reading, updating, and deleting tasks.-