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., "@MCP Project Manager Create a high priority task for reviewing deployment."
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.
A custom MCP server exposing project-management tools (create_task, list_tasks, update_task) backed by SQLite. Built as the Day 1 lab for the Chiron AI Engineering onboarding program.
Tool | Required Params | Optional Params |
|
|
|
| — |
|
|
| — |
Related MCP server: Personal Task Manager MCP
server.py — MCP server definition (tools, handlers) with stdio transport, for local use with Claude Code
server_sse.py — SSE transport wrapper around the same server, for remote/cloud deployment
db.py — async SQLite persistence layer
uv sync
uv run python server.py # stdio transport (for Claude Code)
uv run python server_sse.py # SSE transport on :8000 (for testing deployment locally)A .mcp.json is included pointing at the local stdio server. Restart Claude Code after cloning, then ask it to create/list/update tasks — it will call the MCP tools directly.
The repo includes a Procfile (web: uv run python server_sse.py) that both platforms understand.
Connect this GitHub repo in the Railway or Render dashboard.
Set the DB_PATH environment variable (e.g. /data/tasks.db if using a persistent volume).
Deploy. The server listens on $PORT (defaults to 8000) and exposes GET /sse + POST /messages/.
Point .mcp.json at the deployed URL:
{
"mcpServers": {
"project-manager": {
"type": "sse",
"url": "https://<your-app>.up.railway.app/sse"
}
}
}SQLite file at $DB_PATH (default tasks.db, gitignored). Schema:
CREATE TABLE tasks (
id INTEGER PRIMARY KEY AUTOINCREMENT,
title TEXT NOT NULL,
description TEXT DEFAULT '',
priority TEXT NOT NULL CHECK(priority IN ('low','medium','high','critical')),
status TEXT NOT NULL DEFAULT 'todo' CHECK(status IN ('todo','in_progress','done')),
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);Create a new task with a title, optional description, and priority level.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short task title | |
| description | No | Optional longer description | |
| priority | Yes | Task priority |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations and does not disclose behavioral traits such as side effects, required permissions, or constraints (e.g., duplicate title handling). The description is straightforward but insufficiently transparent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, immediately actionable. 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?
Given the tool's simplicity (3 parameters, no output schema), the description is mostly complete. However, it lacks context around return values or side effects.
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 parameters are well-documented in the schema. The description adds minimal extra meaning over the schema (e.g., 'optional' for description). 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?
Description clearly states action (create), resource (task), and key parameters (title, description, priority). It distinguishes from siblings list_tasks and update_task by focusing on creation.
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?
Implies use for creating tasks but provides no explicit guidance on when to choose this tool over update_task or list_tasks. No when-not-to-use or alternative instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks. Optionally filter by status and/or priority.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status | |
| priority | No | Filter by priority |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to disclose behavioral details like pagination, sorting, or whether it's read-only.
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?
Very concise two sentences, front-loaded with the action, no redundancy.
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?
Missing information on return format, pagination, or side effects, especially given no output schema or annotations.
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 both parameters have descriptions; description adds that filters are optional, but little else.
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 clearly states the tool lists tasks with optional filters, distinguishing it from sibling tools create_task and update_task.
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 guidance on when to use vs alternatives; however, the context of sibling tools implies listing vs creating/updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the status of an existing task by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID to update | |
| status | Yes | New status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states 'update' without noting side effects, required permissions, error handling (e.g., if task not found), or idempotency.
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, 11 words, front-loaded with verb and noun. No wasted words or redundant information.
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 simplicity (2 params, no nested objects, no output schema), the description is nearly complete. Could mention that the task must exist or the behavior if status is same, but otherwise adequate.
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% with clear descriptions for both parameters. The tool description adds no additional meaning beyond the schema, 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?
The description clearly states the action ('Update the status') and resource ('an existing task by its ID'), distinguishing it from sibling tools 'create_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 guidance on when to use or when not to use. It implies usage for changing status, but no exclusion criteria or prerequisites (e.g., task must exist) are mentioned.
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.
v0.1.0create_tasklist_tasksupdate_taskScored across 3 tools
Each tool has a clearly distinct purpose: creation, listing, and status update. No overlap or ambiguity.
All tool names follow the consistent verb_noun pattern with snake_case, making them predictable and easy to use.
Three tools is a minimal but reasonable set for a task manager. Each tool is essential, though the server could benefit from a few more operations.
The server covers create, list, and update status, but misses delete and get details. This is a notable gap for a task management domain.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Create, list, and complete todo items through MCP.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.