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., "@TaskTracker MCP Server Add tasks to investigate a database timeout bug, with dependencies on log checks first."
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 DAG-based task tracking server for bug analysis and investigation workflows, built as a Model Context Protocol (MCP) server.
DAG-based task dependencies — declare dependencies for structured investigation workflows
Circular dependency detection — automatic validation prevents invalid chains
Priority-based execution — tasks sorted by high/medium/low priority
Atomic bulk operations — add entire investigation plans in one call
Rich status tracking — pending → in_progress → completed / skipped / blocked
Evidence-based resolution — every resolved task requires a finding
Analysis gate — conclude_analysis() blocks until all tasks are resolved
Related MCP server: task-manager-mcp
npx tasktracker-mcpnpm install -g tasktracker-mcp
tasktracker-mcpgit clone https://github.com/letscodekrkumar/tasktracker-mcp.git
cd tasktracker-mcp
npm install
npm run build
npm startEdit claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Using npx (recommended):
{
"mcpServers": {
"tasktracker": {
"command": "npx",
"args": ["tasktracker-mcp"]
}
}
}Using global install:
{
"mcpServers": {
"tasktracker": {
"command": "tasktracker-mcp"
}
}
}Using local source build:
{
"mcpServers": {
"tasktracker": {
"command": "node",
"args": ["/absolute/path/to/tasktracker-mcp/dist/index.js"]
}
}
}claude mcp add tasktracker npx tasktracker-mcpOr with a local build:
claude mcp add tasktracker node /absolute/path/to/tasktracker-mcp/dist/index.jsVerify it connected:
claude mcp list
# tasktracker: npx tasktracker-mcp - ✓ ConnectedAny client that supports the MCP stdio transport can use:
{
"command": "npx",
"args": ["tasktracker-mcp"]
}Tool | Purpose |
| Register a single task with optional dependencies |
| Register an entire investigation DAG atomically |
| Resolve task with evidence, update status, or rewire deps |
| Get all executable tasks (deps resolved), priority-sorted |
| Full DAG snapshot with statuses, findings, and dependency state |
| Gate that blocks until all tasks resolved; returns summary |
| Reopen a blocked task when its blocker is resolved |
| Clear all tasks and start fresh |
# 1. Define your investigation DAG
add_tasks_bulk([
{"title": "Fetch bug fields", "category": "log_check", "priority": "high"},
{"title": "Extract machine ID", "category": "log_check", "priority": "high"},
{"title": "Fetch run.log — search for TIMEOUT errors", "category": "log_check", "priority": "high", "depends_on": ["T2"]},
{"title": "Identify root cause", "category": "root_cause", "priority": "high", "depends_on": ["T1", "T2", "T3"]}
])
# 2. Execute ready tasks
tasks = get_ready_tasks() # returns T1, T2
# 3. Resolve tasks as you go
update_task("T1", status="completed", finding="Bug filed 2026-03-28. Build: 4.2.1-rc3.")
update_task("T2", status="completed", finding="Machine ID: X200-lot-7.")
# 4. T3 is now unblocked
update_task("T3", status="completed", finding="3 TIMEOUT errors at 14:22:01")
# 5. Conclude when all done
conclude_analysis()Transition | Allowed | Notes |
pending → in_progress | Yes | No dependency check |
pending/in_progress → completed | Yes | All deps must be resolved; finding required |
pending/in_progress → skipped | Yes | Finding required |
pending/in_progress → blocked | Yes | Finding required |
completed / skipped → any | No | Permanently resolved |
blocked → any | No | Use |
npm test # run tests
npm run test:coverage # with coverage report
npm run build # compile TypeScript
npm run dev # build + run
npm run benchmark # performance benchmarkssrc/
index.ts # MCP server entry point
tracker.ts # DAG engine (task state, dependency resolution)
types.ts # TypeScript interfaces and validators
monitor.ts # Progress monitoring
examples.ts # Usage examples
benchmark.ts # Performance benchmarks
__tests__/ # Test suite
docs/ # Design docs, deployment guide, specsMIT — see LICENSE
Register a single follow-up task discovered mid-investigation. Use add_tasks_bulk() instead if defining the full plan upfront.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Task description (max 200 chars) | |
| category | No | Task grouping for expertise routing | |
| priority | No | Execution priority | |
| depends_on | No | Task IDs that must resolve before this task is ready |
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 only states that the tool registers a task but does not disclose side effects, permissions, return values, or validation of depends_on. For a mutating operation, 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 two sentences, front-loaded with purpose, and the second sentence is a useful alternative pointer. No redundant content and 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?
The tool is simple and the schema covers all parameters, but the description lacks behavioral details such as return value or task state after registration. There is no output schema or annotations to compensate, so while the usage context is helpful, the description is minimally 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 description coverage is 100%, so all parameters are already documented in the schema. The description does not add any parameter-specific semantics beyond what the schema provides, so the baseline 3 applies.
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 the specific verb 'Register' with resource 'a single follow-up task' and adds context 'discovered mid-investigation'. It also distinguishes from sibling tool by naming add_tasks_bulk(), making the purpose unambiguous.
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?
It explicitly states when to use this tool ('discovered mid-investigation') and when to use the alternative ('Use add_tasks_bulk() instead if defining the full plan upfront'). This clearly routes the agent to the correct tool based on the planning stage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FIRST CALL: Register your entire investigation plan as a DAG in one atomic call. All tasks are validated before any are inserted. Returns a prioritised execution plan showing which tasks to start with.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | List of task definitions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses atomicity ('one atomic call'), validation ('All tasks are validated before any are inserted'), and return behavior ('Returns a prioritised execution plan'). These are valuable behavioral traits beyond basic write semantics, though it does not cover error handling 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?
Two sentences, no filler. The opening 'FIRST CALL' is a strong front-loaded signal. Every word adds value: atomicity, validation, DAG, prioritised plan. Exemplary conciseness.
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 one parameter with nested structure and no output schema. The description explains the core behavior (bulk DAG registration) and return value (execution plan), which is sufficient for an AI agent to invoke it correctly. It could mention idempotency or response format, but overall it is complete for the described use case.
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%, so parameters are structurally documented. The description adds semantic meaning by explaining that tasks form a DAG (clarifying depends_on) and that a prioritised execution plan is returned (relating to priority). It turns the schema's raw field list into a coherent concept of a task graph.
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 tool's function: 'Register your entire investigation plan as a DAG in one atomic call.' This distinguishes it from the singular 'add_task' sibling by emphasizing bulk registration of the whole plan. The phrase 'FIRST CALL' further reinforces its specific role.
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 conveys when to use it ('FIRST CALL') and implies it is the entry point for registering a full plan. It does not explicitly name alternatives or exclusions, but the 'FIRST CALL' directive and mention of the entire investigation plan provide clear usage context compared to siblings like add_task or get_ready_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FINAL CALL: Close out the investigation. Blocks and returns actionable instructions if any tasks are still pending or in_progress. Returns a full grouped summary (by status and category) once everything is resolved. Call this when you believe all tasks are done.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. It discloses that the tool blocks and returns instructions if tasks are pending, and returns a full grouped summary when resolved. However, it does not detail side effects like whether the investigation is permanently closed or tasks become locked, leaving some ambiguity about mutating behavior.
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 very concise at three sentences, front-loaded with 'FINAL CALL' to signal importance. Every sentence provides necessary context: purpose, blocking behavior, return value, and usage condition. No wasted words.
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 tool without an output schema, the description covers the essential aspects: what it does, when to call it, and what it returns (with grouping details). It omits specifics about the summary structure or irreversible consequences, but given the tool's simplicity and no schema, this is largely sufficient.
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 and the schema is an empty object, making schema coverage 100%. The baseline for 0 params is 4, and no additional parameter description is needed since there is nothing to describe.
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 identifies a specific verb and resource: 'Close out the investigation.' It distinguishes itself from sibling task-management tools by being the finalization step, with additional detail about blocking on pending tasks and returning a summary. This makes its unique purpose unambiguous.
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 explicitly states when to use it: 'Call this when you believe all tasks are done.' It also implies the when-not by explaining that it blocks and returns actionable instructions if tasks are pending, effectively warning against premature invocation. This is clear usage guidance with implied exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full snapshot of the entire DAG — all tasks, their current status, findings, dependencies, and overall progress. Use when you need to review the full picture or check what is blocked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the full scope of the snapshot and implies read-only nature, but does not explicitly state safety traits or performance characteristics.
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?
Two sentences, front-loaded with the main action and immediately followed by useful details and usage context—no wasted words.
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?
Adequately covers what the tool does and when to use it for a simple read-only operation, though it omits any explicit mention of return format or scale limitations.
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?
No parameters exist, so schema coverage is trivially 100%; baseline of 4 applies without needing description compensation.
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?
Clearly states it retrieves a full snapshot of the entire DAG with specific attributes (tasks, status, findings, dependencies, progress), distinguishing it from filtered siblings like get_ready_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?
Provides explicit context for when to use ('review the full picture or check what is blocked'), but does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CALL AFTER EVERY update_task: Returns all tasks whose dependencies are fully resolved, sorted by priority (high → medium → low). These are the tasks you should work on next. Empty list means either all done or everything is blocked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains the filtering condition (dependencies fully resolved), sort order (by priority), and the meaning of an empty result (all done or blocked). This exceeds basic expectations, though it doesn't mention potential errors or side effects (likely 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?
The description is three sentences, each adding value: the trigger and core function, the practical use, and the interpretation of empty results. No redundant information is present, making it highly efficient.
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 (no params, no output schema), the description is fully complete. It covers when to call it, what it returns, how results are sorted, and what an empty list means. There are no gaps for a user to guess.
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 input schema has zero parameters, so schema coverage is trivially 100%. For 0-parameter tools, the baseline is 4, and the description adds meaning by explaining what the tool returns and how to interpret the result. No parameter documentation is needed.
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's function: 'Returns all tasks whose dependencies are fully resolved, sorted by priority'. It uses a specific verb and resource, and distinguishes itself from get_all_tasks by focusing only on ready tasks. The added context about working on these tasks next reinforces its purpose.
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 explicitly instructs to 'CALL AFTER EVERY update_task', providing a clear trigger for usage. It also explains what to do with the output ('tasks you should work on next'). However, it does not explicitly mention when not to use it or name alternative tools, so it lacks full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reopen a blocked task after its blocker has been resolved. Resets the task to pending, preserves the original finding in history, and recalculates its dependency state. Provide a reason explaining what changed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Explanation of what changed | |
| task_id | Yes | ID of the blocked task to reopen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: resetting to pending, preserving history, recalculating dependency state, and requiring a reason. This is substantive, though it could mention error cases 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?
Three sentences, each earning its place. The opening sentence states the main action and condition, the second details side effects, and the third instructs on the required reason. No filler.
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 a simple two-parameter tool with no output schema and no annotations, the description covers the core use case, behavioral side effects, and parameter expectations. It could mention return value or failure behavior, but for this complexity it is sufficiently complete.
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 schema already covers both parameters with helpful descriptions. The description reinforces the purpose of 'reason' but does not add new semantic detail beyond the schema. Baseline 3 is appropriate given full schema coverage.
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 opens with a specific verb ('Reopen') and resource ('blocked task'), clearly distinguishing this from siblings like update_task or reset. It also states the key operations: resets to pending, preserves finding, recalculates dependency state.
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 phrase 'after its blocker has been resolved' provides explicit timing context for when to use the tool. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all tasks and start a new investigation session. Irreversible — all tasks and findings are permanently deleted. Only use when starting a completely new investigation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for disclosing behavior. It clearly states the irreversible and destructive nature: 'Irreversible — all tasks and findings are permanently deleted.' This is critical safety information for an agent.
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 composed of three short, information-dense sentences covering the action, irreversibility, and usage context. Every word earns its place with no 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?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description fully covers what the tool does, its consequences, and when to use it. There are no significant information gaps.
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 no parameters, and the schema is empty. Per the rules, a baseline of 4 applies for zero parameters. The description adds no parameter information, which is acceptable since there are none.
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 ('Clear all tasks') and the resource ('all tasks and findings'), and establishes the context ('start a new investigation session'). This distinguishes it from sibling task-management tools like add_task or 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?
The description explicitly states when to use the tool: 'Only use when starting a completely new investigation.' This provides a clear condition and implies it should not be used for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a task after completing work on it. Always provide a finding for completed/skipped/blocked. Completing a task automatically unblocks any dependents. Can also rewire dependencies (pending tasks only) or update a finding without changing status.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | New status for the task | |
| finding | No | Evidence, reason, or intent (required for completed/skipped/blocked) | |
| task_id | Yes | ID of the task to update | |
| depends_on | No | Replace dependency list (pending tasks only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It discloses that completing a task automatically unblocks dependents and that dependency rewiring only applies to pending tasks. This goes beyond a generic 'update' description, though it could mention potential status transition restrictions 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?
Two sentences, front-loaded with the primary purpose, followed by critical constraints and side effects. Every clause earns its place; no redundant wording.
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 description covers the main use cases: resolving, updating finding alone, and rewiring dependencies. It doesn't explicitly explain status transition behavior (e.g., moving back to in_progress), but given the rich input schema, it is sufficiently complete 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 coverage is 100%, so the schema already documents each parameter's purpose, including the pending-only constraint for depends_on and the required finding. The description adds behavioral context (auto-unblock) but adds little new parameter-specific semantics. 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 begins with 'Resolve a task after completing work on it,' which clearly identifies the verb (resolve) and resource (task). It also outlines multiple distinct capabilities (updating finding, rewiring dependencies) that distinguish it from sibling tools like add_task or get_all_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?
The description provides clear context for when to use the tool: after completing work, and it specifies when a finding is required (completed/skipped/blocked). It does not explicitly name alternative tools, but the context is strong enough that an agent would know when to select this over siblings.
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.2add_taskadd_tasks_bulkconclude_analysisget_all_tasksget_ready_tasksreopen_taskresetupdate_taskEach tool has a distinct purpose: adding single vs bulk tasks, updating vs reopening, getting ready vs all tasks, plus reset and conclude. No overlap or ambiguity.
Most tools follow verb_noun pattern (add_task, update_task, reopen_task, get_ready_tasks), but 'reset' is a bare verb and 'conclude_analysis' breaks the pattern slightly. The inconsistency is minor and doesn't hinder readability.
8 tools is well-scoped for a task tracking server, covering creation, updates, queries, and lifecycle management without being overly heavy or sparse.
The tool surface covers the full investigation lifecycle: plan creation (bulk), incremental additions, status updates, dependency rewiring, reopening, readiness queries, full snapshot, reset, and final conclusion. No obvious gaps that would block typical workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for an Agent Task Marketplace
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Work management where AI agents are first-class members: tasks, projects, memory over hosted MCP
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/letscodekrkumar/tasktracker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
