GeeksHacking MCP
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., "@GeeksHacking MCPShow all TODOs in src/main.py"
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.
GeeksHacking MCP - TODO Management Server
A Model Context Protocol (MCP) server for managing and tracking #TODO comments from source code files.
Overview
GeeksHacking MCP is an MCP server that provides tools and resources for tracking TODO comments scattered across your codebase. It stores TODO items with their source file location and line numbers, making it easy to manage and query pending tasks directly from your development environment.
Related MCP server: todo-tree MCP Server
Features
Add TODOs: Register TODO comments from any source file with line number tracking
Query TODOs: Retrieve all TODO items for a specific file
Persistent Storage: Stores TODO items in a JSON database
MCP Integration: Works seamlessly with MCP-compatible clients (like Claude Desktop, Cline, etc.)
Installation
Prerequisites
Python 3.13 or higher
uvpackage manager (recommended) orpip
Install via uv
uvx --from git+https://github.com/JiaweiLin/geekshacking-mcp.git todo_mcpInstall from source
# Clone the repository
git clone https://github.com/JiaweiLin/geekshacking-mcp.git
cd geekshacking-mcp
# Install dependencies
uv sync
# Run the server
uv run todo_mcpUsage
As an MCP Server
Add the following configuration to your MCP client configuration file (e.g., Claude Desktop's config):
{
"mcpServers": {
"todo_mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/JiaweiLin/geekshacking-mcp.git",
"todo_mcp"
]
}
}
}Or if installed locally:
{
"mcpServers": {
"todo_mcp": {
"command": "uv",
"args": ["run", "todo_mcp"],
"cwd": "/path/to/geekshacking-mcp"
}
}
}Available Tools
tool_add_todo
Add a single #TODO text from a source file.
Parameters:
filename(string): Source file containing the #TODOline_num(integer): Line number of the #TODOtext(string): #TODO text to add
Example:
{
"filename": "src/main.py",
"line_num": 42,
"text": "Refactor this function for better performance"
}Available Resources
resource_get_todos_for_file
Get all #TODO texts for a source file.
URI Pattern: todo://{filename}/todos
Parameters:
filename(string): Source file containing the #TODO
Returns: Array of TODO text strings (empty array if no TODOs exist for the file)
Example URI: todo://src/main.py/todos
Database
TODO items are stored in a JSON file at:
src/todo_mcp/todo_db.jsonThe database structure:
{
"filename.ext": {
"_10": "TODO text at line 10",
"_20": "TODO text at line 20"
}
}Development
Project Structure
geekshacking-mcp/
├── src/
│ └── todo_mcp/
│ ├── __init__.py
│ ├── todo_mcp.py # MCP server implementation
│ └── todo_db.py # Database management
├── pyproject.toml # Project configuration
├── uv.lock # Dependency lock file
└── README.mdSetting up for Development
# Install development dependencies
uv sync
# Run the server locally
uv run todo_mcp
# Run tests (if available)
uv run pytestDependencies
fastmcp>=2.13.0.2- FastMCP framework for building MCP servers
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
License
MIT License
Links
Support
For issues, questions, or contributions, please visit the GitHub repository.
Available Tools
1 tooltool_add_todoA
Add a single #TODO text from a source file
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Source file containing the #ToDO | |
| line_num | Yes | Line number of the #TODO | |
| text | Yes | #ToDO text to add |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the basic mutation action but omits details on side effects, duplicate handling, file modification behavior, or authorization needs.
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?
Single sentence, no wasted words. Appropriate length for a simple tool with well-documented 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?
Tool is simple but description could mention what happens on duplicate, file existence, or return state. Without output schema, lack of return info is acceptable but edge cases are unaddressed.
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 baseline is 3. The description adds no additional meaning beyond what is already in the input 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?
Description clearly states the action (add), object (#TODO text), and source (from a source file). It is specific and unambiguous, with no sibling tools to differentiate.
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?
Description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The sentence only states the function.
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.
1 tool update
v0.1.0- First observed
tool_add_todo
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity. The single tool has a clear and distinct purpose.
Since there is only one tool, there are no inconsistencies in naming patterns. The name itself follows snake_case convention.
A single tool is extremely limited for a server, especially when the domain is not explicitly narrow. This feels like an extreme mismatch between scope and tool count.
The server only offers a tool to add a TODO, with no tools for listing, updating, or deleting TODOs. This is a significant gap for basic task management functionality.
Maintenance
Related MCP Connectors
Create, list, and complete todo items through MCP.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Manage feature requests, votes, roadmaps, and changelogs from any MCP client.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools and resources for managing a coding project's todo list, allowing users to view, add, update, and delete todo items with details like priority, status, and tags.1-
- FlicenseNot gradedqualityDmaintenanceExposes your todo-tree task list as MCP tools for reading and managing tasks via MCP-compatible AI clients like Claude Desktop.-
- AlicenseAqualityBmaintenanceExposes technical debt management to AI coding assistants, enabling them to find, prioritize, and resolve TODO/FIXME/BUG comments across codebases via MCP tools.652 npm1MIT
- AlicenseNot gradedqualityCmaintenanceEnables managing tasks in a structured TODO.md file through MCP tools for listing, adding, updating, setting status, logging notes, searching, and removing tasks while preserving hand-authored formatting.6 npmMIT