1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tasker Show me my open tasks" 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.

tasker

by greendwin

Overview Schema Related Servers Score Discussions

Python

Local

Tasker

tests

A Markdown task tracker designed to live in git alongside your code. Tasks are plain Markdown files inside a .tasker/ directory, with hierarchical stories and subtasks, a CLI for humans, and an MCP server so AI agents can manage the same task list.

Installation

Install with pipx (recommended — installs in an isolated environment):

pipx install mcp-tasker

Or with pip:

pip install mcp-tasker

For development (requires uv):

git clone https://github.com/greendwin/mcp-tasker.git
cd mcp-tasker
uv sync --group dev

Related MCP server: Memory MCP Server

Quick Start

# Initialize tasker (or let it auto-detect from any subdirectory)
tasker init

# Or initialize a user-level tasker in your home data directory
tasker init --user

# Create a story
tasker new "Build authentication"

# Add subtasks
tasker add s01 "Design login flow"
tasker add s01 "Implement JWT tokens" --details "Use RS256 signing"

# Work on a task
tasker start s01t01

# View what's on your plate
tasker list

# Mark tasks done
tasker done s01t01

# Edit a task in your editor
tasker edit s01t02

Tasks are stored as Markdown in .tasker/ and committed with your code:

.tasker/
  s01-build-authentication/
    README.md
    s01t01-design-login-flow.md
    s01t02-implement-jwt-tokens.md

Usage

Create tasks

tasker new <title>                          # new root story
tasker new <title> --details "..." --slug <slug>  # with description and slug
tasker new <title> --editor                 # create and open in editor
tasker add <parent-id> <title>              # inline subtask
tasker add <parent-id> <title> --details "..."    # subtask with description
tasker add <parent-id> <title> --editor     # create and open in editor
tasker add-many <parent-id>                 # add multiple subtasks interactively

Update status

tasker start <task-id>...     # mark in-progress
tasker review <task-id>...    # submit leaf task for review
tasker done <task-id>...      # mark done
tasker cancel <task-id>...    # cancel
tasker reset <task-id>...     # reset to pending
tasker reset <task-id> --force  # force reset non-pending subtasks

# Force-close a parent with open subtasks
tasker done <task-id> --force

# Close every in-review task along with any explicitly listed ones
tasker done --reviewed

View tasks

tasker list                   # all open root tasks
tasker list -a                # include closed tasks
tasker list --todo            # only tasks from the TODO list
tasker list --archived        # list archived tasks
tasker list --closed          # show 5 most recently closed tasks
tasker list <task-id>         # subtasks of a specific task
tasker view <task-id>         # full task details

TODO list

Pin tasks you're actively focused on. The list lives in .tasker/.todo (git-ignored), and archived tasks are removed automatically.

tasker todo <task-id>...      # pin task(s) to the TODO list
tasker untodo <task-id>...    # remove from the TODO list
tasker list --todo            # show only pinned tasks

Edit tasks

tasker edit <task-id>                    # open in $EDITOR
tasker edit <task-id> --title "New title"
tasker edit <task-id> --details "New description"
tasker edit <task-id> --slug new-slug

Organize

tasker move <task-id> --parent <new-parent>  # reparent
tasker move <task-id> --root                 # promote to story
tasker move <task-id> --delete               # delete a task
tasker move <task-id> --id <new-id>          # rename to an explicit free ID
tasker move <task-id> --parent <p> --editor  # reparent and open in editor
tasker archive <task-id>                     # archive completed story
tasker archive --closed                      # archive all closed stories
tasker unarchive <task-id>                   # restore from archive

Resolve merge conflicts

After a git merge that leaves conflicted task files, auto-resolve them:

tasker resolve

This performs a three-way merge on each conflicted task file in .tasker/ — scalar fields (title, status, slug) and subtask lists are merged individually. Cleanly resolved files are staged automatically; files with remaining conflicts are left with git-style conflict markers for manual editing.

Shortcuts

Reference recent tasks without typing full IDs:

Shortcut	Meaning
`q`	Last referenced task
`q01`	Subtask 01 of recent
`p`	Parent of recent
`p03`	Sibling 03 via parent

tasker view s01t02   # sets recent = s01t02
tasker start q       # starts s01t02
tasker view p        # views s01 (parent)
tasker done q01      # marks s01t0201 done

MCP Server

tasker can run as a Model Context Protocol server, allowing AI agents to manage your tasks directly.

Configure in Claude Code

claude mcp add tasker -- tasker mcp

Configure per-project (`.mcp.json`)

{
  "mcpServers": {
    "tasker": {
      "command": "tasker",
      "args": ["mcp"]
    }
  }
}

If running from a checkout:

{
  "mcpServers": {
    "tasker": {
      "command": "uv",
      "args": ["run", "tasker", "mcp"]
    }
  }
}

HTTP transport

For network-accessible clients, start with --port:

tasker mcp --port 8080

Available tools

Once connected, the MCP server exposes:

Tool	Description
`create_task`	Create a root task or subtask
`list_tasks`	List all root tasks (pass `todo=true` for only pinned tasks)
`view_tasks`	View detailed info for multiple tasks
`edit_task`	Update a task's title, description, or slug
`start_task`	Mark task in-progress
`review_task`	Mark task in-review (submit for review)
`reset_task`	Reset task to pending
`finish_task`	Mark task done
`cancel_task`	Cancel a task

Development

uv sync --group dev

# Run all checks (lint + tests)
uv run tox

# Run tests only
uv run tox -e test

# Lint (black, isort, flake8, mypy)
uv run tox -e lint

# Format code
uv run black src tests
uv run isort src tests

Requirements

Python >= 3.10

Release Notes

1.8.1

Bug fixes: flush aborts loudly instead of silently wiping a task's body when a render would drop title/status or prose; generate_slug keeps internal hyphens/underscores as word separators instead of deleting them

1.8.0

Task body unified into a single free-form description; editing a task no longer orphans or duplicates extra ## sections on write
MCP: read tools list_tasks and view_tasks now return plain text / trimmed markdown instead of structured JSON
MCP: mutating tools (create_task, edit_task, and the status changes) return a concise {id, status} ack instead of a full task preview
MCP: removed the task:// resources (task://index, task://{ref}) — use the list_tasks / view_tasks tools for reads

1.7.0

tasker resolve auto-merges conflicted task files after a git merge — three-way field-level merge with git-style conflict markers for unresolvable differences
Task references accept root-task slug names: exact match or unambiguous partial substring (≥ 3 chars)
Bug fixes: backslash directory paths normalised in conflict file detection, defensive parsing for malformed git ls-files output

1.6.0

move <task-id> --id <new-id> renames a task to any free, canonically-valid ID (shorthand like s1t5 is accepted); the task is re-homed under the parent the new ID implies and descendants are relabeled recursively
Bugfix: list --todo now expands children of every sibling todo task
Bugfix: MCP view_tasks description includes extra non-Subtasks ## sections

1.5.0

tasker init now creates .tasker/; legacy tasker/ directories are still recognised at discovery time
Direct task references accept single-digit segments: s1 → s01, s1t1 → s01t01, and trailing -slug works on the padded form
list --rev falls back to the active TODO list when nothing is in review (previously fell back to all active root tasks)
Ambiguous-digit error message reworded to mention direct references
Bug fixes: suppress spurious Error: <code> output from typer.Exit on normal CLI exits

1.4.2

Single-digit shortcuts pad to two: q3 → q03, p3 → p03, ta3 → ta03; odd-length runs > 1 are rejected as ambiguous

1.4.1

list --rev / list --in-review shows tasks awaiting review (with parent context); falls back to active root tasks when none are in review

1.4.0

t<letter> shortcuts (ta..tz) for active TODO tasks, usable wherever a <task-id> is accepted
list --todo hides finished tasks while active ones remain; prints All tasks finished! when none are active
TODO list preserves insertion order
MCP: task_ref arguments accept the full set of CLI shortcuts (q, p, t<letter>)
Build: cached Typer command tree in tests cuts full-suite runtime by ~30%
Bug fixes: edit --editor refreshes the in-memory task tree so follow-up displays reflect new title/slug

1.3.4

Warning shown when a task directory is missing its README.md
Exception callstacks hidden by default, shown only with --debug
Renamed tasks displayed as a single group in move output
Bug fixes: broken task files now report the offending filename in the error message

1.3.3

Task preview after done/cancel walks up to the first non-closed ancestor, showing the full picture of remaining work
When closing a task completes the entire story, nearby open stories are shown as a "what's next?" hint

1.3.2

Bug fixes: proper error handling for exceptions raised in dependency-injection callbacks (e.g. missing tasker/ directory)

1.3.1

list --closed flag to explicitly show recently closed tasks (previously shown implicitly at the end of list)
Bug fixes: list --todo no longer shows non-TODO tasks

1.3.0

in-review status and tasker review command for submitting leaf tasks
done --reviewed closes every currently in-review task in one call
todo / untodo commands to pin tasks, and list --todo / (todo) marker
Archived tasks are auto-removed from the TODO list
init --user creates a user-level tasker directory (respects XDG_DATA_HOME / LOCALAPPDATA)
move --editor to open the moved task after reparenting
new and add accept unquoted titles (extra words are joined automatically)
Recently closed tasks are shown at the end of list output
Last two digits of subtask IDs are highlighted in bullet lists
MCP: added cancel_task tool, todo parameter on list_tasks
MCP: status tools return smaller previews on start / cancel / review / done
Build: migrated from poetry to uv
Bug fixes: [text] escaping in task output, stale (q) reference to deleted tasks, tasker directory resolution, recently closed task suppressed on narrow terminals

1.2.0

init command and automatic tasker/ directory discovery (walks up to git root)
move --delete option to delete tasks
reset --force to force-reset non-pending subtasks
(q) / (p) recent-task markers shown in view and edit commands
Subtask count shown in view command
Tab autocompletion for task ID arguments
Slug validation
Bug fixes: recent task override, auto-unarchive logic

1.1.0

--editor (-e) option on new and add commands to open the task in an editor after creation
list --archived to browse archived tasks
list highlights the most recently referenced task
Editing an archived task auto-unarchives it
Task preview shown after start, reset, done, cancel, move, new, add, and edit commands
MCP: added edit_task tool for updating title, description, and slug
MCP: view_tasks accepts multiple task IDs in a single call
MCP: task subtasks grouped by status in response
--version flag
Bug fixes: editor slug path, directory cleanup on move, multi-task preview on start

1.0.0

pip release

Available Tools

9 tools

cancel_taskB

Cancel a task. Use force=True to cancel all open subtasks.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`task_ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states 'Cancel a task' implying a state change but does not describe reversibility, side effects (e.g., what happens to subtasks without force), permissions required, or response format. The mention of force=True hints at behavior with subtasks but is insufficient 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences. It is front-loaded and contains no extraneous information. Every word earns its place.

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?

Given the lack of annotations and output schema usage (not mentioned), the description is incomplete. It does not explain return values, prerequisites, or behavior under various conditions (e.g., cancelling a task with open subtasks without force). For a tool with siblings and parameters, more context is needed.

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

Parameters3/5

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

The input schema has 0% description coverage, so the description must compensate. It explains the force parameter ('use force=True to cancel all open subtasks'), which adds meaning beyond the schema (boolean with default). However, the required task_ref parameter is not explained, and the description does not elaborate on its format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (cancel) and the resource (task). It includes a specific parameter detail (force for subtasks) that adds clarity. Although it doesn't explicitly differentiate from siblings like finish_task or reset_task, the purpose is unambiguous.

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?

The only usage guidance is about the force parameter ('Use force=True to cancel all open subtasks'). There is no guidance on when to use cancel_task versus sibling tools (e.g., finish_task, reset_task), nor are there any exclusions or prerequisites mentioned.

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

create_taskA

Create a root task or subtask (when parent is given).

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

A3.5/5.0

Behavior3/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. It states the main behavior (creating root or subtask), but does not disclose additional behaviors such as side effects, required permissions, or what happens on success or failure. It is adequate but lacks depth.

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?

The description is concise, consisting of a single sentence that front-loads the purpose. It has no wasted words, but could include more relevant contextual details without becoming verbose.

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?

Given the presence of an output schema, the description does not need to explain return values. However, it does not cover input constraints (e.g., title length) or provide enough context for an agent to handle errors. It is partly complete but leaves gaps.

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. It adds meaning to the parent parameter by explaining its role in creating subtasks, but does not provide semantics for the required title parameter or the optional description parameter beyond what the schema already has.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Create', the resource 'task', and distinguishes between creating a root task or a subtask based on the parent parameter. This differentiates it from sibling tools like edit_task or finish_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating what the tool does, but it does not explicitly specify when to use it versus alternatives, nor does it provide any when-not-to-use guidance. Among siblings, it is the only creation tool, so usage is implied but not elaborated.

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

edit_taskC

Update a task's title, description, or slug.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'update' but does not mention idempotency, required permissions, side effects, or whether it can be safely retried. This is insufficient 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It could benefit from additional sentences or bullet points to elaborate on usage or behavior, but it is not verbose.

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?

Given the lack of annotations and schema descriptions, the description is too brief for a mutation tool with 4 parameters and an output schema. It does not clarify return value, prerequisites, or any constraints, leaving the agent with incomplete context.

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?

The schema has 0% description coverage, meaning the description must carry the burden. It lists the updatable fields (slug, title, description) but adds no extra meaning beyond the property names. The required 'task_ref' parameter is not explained at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'update' and the resource 'task', and specifies the exact fields that can be updated: title, description, or slug. This distinguishes it from sibling tools like create_task or finish_task, which serve different purposes.

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?

The description provides no guidance on when to use this tool versus alternatives like reset_task or review_task. There is no mention of prerequisites, when not to use, or scenarios where another sibling would be more appropriate.

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

finish_taskA

Mark a task as done. Use force=True to close all open subtasks.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`task_ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses force behavior but lacks details on side effects, permissions, or what happens with open subtasks when force=False.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with purpose, no wasted words.

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?

Has output schema so return values don't need explanation, but description misses constraints like whether task must be in progress or what happens to subtasks by default.

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

Parameters3/5

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

Schema has 0% coverage. Description adds meaning for the 'force' parameter but not for 'task_ref', which remains minimally explained beyond its name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Mark' and resource 'task as done', distinguishing it from siblings like cancel_task, start_task, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on force parameter usage but does not explicitly state when to use this tool versus alternatives like cancel_task or review_task.

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

list_tasksA

List root tasks as compact lines: ``<sign> <id>  <title> (...)``.

Status signs: ``.`` pending, ``~`` in-progress, ``?`` in-review,
``x`` done, ``-`` cancelled. A trailing ``(...)`` marks a task that has
a body -- view it for the full detail.

Args:
    todo: If True, list only tasks from the TODO list.

ParametersJSON Schema

Name	Required	Description	Default
`todo`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses the output format (status signs, id, title, body indicator) and the todo parameter effect. It does not explicitly state read-only behavior but strongly implies it through 'list' and lack of side-effect cues.

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?

The description is well-structured with clear sections for format, status signs, and argument. It is slightly verbose due to the full format spec, but every sentence adds value, making it appropriate for the task.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, read-only listing), the description covers all essential aspects: purpose, output structure, filter option, and visual indicators. An output schema exists, but the text provides complementary context about sign meanings and body indicator.

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

Parameters5/5

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

The single parameter 'todo' has 0% schema description coverage, yet the tool description fully explains its semantics: 'If True, list only tasks from the TODO list.' This adds necessary meaning beyond the schema's bare boolean type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List root tasks as compact lines' with specific format details, identifying the verb (list) and resource (root tasks). It distinguishes from siblings like create_task or edit_task by focusing on listing, not 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?

The description does not provide guidance on when to use this tool versus alternatives such as view_tasks (a sibling). It implies usage for compact listing but offers no exclusions or comparisons, leaving the agent without decision-making context.

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

reset_taskA

Reset a task back to pending.

Use force=True to reset all non-pending subtasks.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`task_ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It mentions the force parameter's effect on subtasks but does not disclose permissions, irreversibility, or other side effects. This is insufficient 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no unnecessary words. The first sentence states the core purpose, and the second adds the key parameter behavior.

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?

While the description covers the main action and force parameter, it lacks details on prerequisites, error conditions, and contextual usage instructions. The presence of an output schema reduces the need to explain returns, but more context would improve agent invocation.

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

Parameters4/5

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

With 0% schema description coverage, the description explains both parameters: task_ref is implicitly the task to reset, and force controls subtask resetting. This adds essential meaning beyond the schema, though format is not specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resets a task to the 'pending' state, using a specific verb and resource. It is distinct from sibling tools like cancel_task or finish_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for resetting tasks but provides no explicit guidance on when to use this tool versus alternatives. No when-not or exclusionary context is given.

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

review_taskC

Mark a task as in-review (submit for review).

ParametersJSON Schema

Name	Required	Description	Default
`task_ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only states the action but does not disclose behavioral details such as required current status, irreversibility, or permission needs.

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?

The description is a single sentence with no waste, but it is too brief to be effective; it sacrifices substance for brevity.

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?

Given the tool's simplicity (one parameter, output schema exists), the description fails to cover the state transition semantics and expected behavior, leaving gaps in understanding.

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?

With 0% schema description coverage, the description adds no value for the sole parameter 'task_ref'; it merely repeats the overarching purpose without clarifying what the parameter represents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Mark a task as in-review' with a specific verb and resource, and distinguishes it from sibling tools like 'finish_task' or 'start_task' which handle different state transitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates usage for submitting a task for review but does not explicitly state when to use it versus alternatives like 'finish_task' or 'cancel_task', nor does it mention prerequisites or context.

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

start_taskC

Mark a task as in-progress.

ParametersJSON Schema

Name	Required	Description	Default
`task_ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`affected`	No	Subtask ids whose status changed as a side effect of force; omitted when nothing cascaded.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the core action without mentioning prerequisites (e.g., task existence, state checks), side effects, or permissions. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no extraneous information. Every word serves a purpose, making it efficient and front-loaded.

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?

Despite having an output schema, the description does not mention return values or indicate success/failure. Combined with lack of annotations and poor parameter documentation, the description is incomplete for a state-mutation tool.

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?

The schema has 0% description coverage, and the description does not explain the single parameter 'task_ref'. The agent is left to infer what it refers to (e.g., ID, URL, name), providing no added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Mark a task as in-progress' uses a specific verb and resource, clearly indicating the action and state change. It effectively distinguishes from sibling tools like 'finish_task' (mark as done) and 'cancel_task'.

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 guidance is provided on when to use this tool versus alternatives like 'create_task', 'edit_task', or 'view_tasks'. The description does not specify context or exclusions.

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

view_tasksA

View tasks by IDs as trimmed markdown.

Each task renders as ``# <id>: <full title>`` followed by ``status:`` /
``parent:`` metadata lines (``parent:`` omitted for root tasks), the
verbatim task body, and a ``## Subtasks`` checklist reusing the compact
line format. A bad/deleted/unknown ref becomes a ``# <ref>: <error>`` stub
instead of failing the batch. Blocks are joined by ``\n\n---\n\n``.

Use this instead of reading task files from disk.

ParametersJSON Schema

Name	Required	Description	Default
`task_refs`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: the output format (markdown with IDs, titles, status, parent, body, subtasks), error handling for bad references (stubs instead of failures), and the separator between blocks. This exceeds the bare minimum.

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?

The description is well-structured, front-loading the core purpose in the first sentence. Subsequent sentences detail the output format without unnecessary verbosity. A slight improvement could be merging some redundant phrasing, but overall it is concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema (single parameter) and the presence of an output schema, the description thoroughly explains the output format, error handling, and usage context. It leaves no significant gaps for an AI agent to misinterpret how to invoke or interpret the tool.

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

Parameters4/5

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

The description adds meaning to the sole parameter 'task_refs' by stating 'by IDs', clarifying that the array elements are task identifiers. Since schema description coverage is 0%, the description compensates well, though more detail on ID format could be provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'View tasks by IDs as trimmed markdown', specifying both the verb and the resource. It distinguishes this read operation from siblings like create_task or edit_task by its focus on viewing, and further clarifies its use case by advising 'Use this instead of reading task files from disk'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool to view tasks by their IDs. It includes a directive to use it instead of reading from disk, but does not explicitly compare to list_tasks or other viewing alternatives, nor does it state when not to use it.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct operation on tasks: create, edit, list, view, and status transitions (start, review, finish, cancel, reset). No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., cancel_task, create_task). No mixing of styles or irregularities.

Tool Count5/5

With 9 tools covering core task lifecycle operations (create, read, update, delete-like via cancel/reset), the count is well-scoped for a task management server.

Completeness4/5

The tool set covers CRUD and status transitions comprehensively. Minor gaps include no explicit delete tool and limited filtering (only TODO flag for listing), but core workflows are fully supported.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MDflow
cz.mdflow
Markdown workspace for AI agents: read, write, organize, and share markdown documents.
Note Taking Knowledge & Memory
2
Done Bear A
com.donebear
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Project Management App Automation
351
LTD MCP
io.github.Eshller
Project management MCP for AI agents with safe task reads and writes.
Project Management Agent Orchestration
12
Dazbench
app.dazbench
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Autonomous Agents Project Management Agent Orchestration
1

Related MCP Servers

Tasks.md MCP Server
Project Management Developer Tools File Systems
context-you-keep
F
license
Not graded
quality
Not graded
maintenance
Enables AI-native task management using plain markdown files to create, update, query, and organize Epics, Stories, Tasks, and Milestones without requiring a database.
Updated 10 months ago (2025-11-19 04:44 UTC)
Memory MCP Server
Knowledge & Memory Note Taking File Systems
orkuhh
A
license
Not graded
quality
C
maintenance
Provides tools for AI agents to manage long-term memories, daily notes, and TODO lists through a structured markdown file system. It enables context awareness by allowing agents to read, write, and search entries for persistent information storage.
Updated 7 months ago (2026-02-16 02:00 UTC)
12
MIT
ClickUp MCP Server
Project Management Workplace & Productivity
mcpflow
F
license
Not graded
quality
D
maintenance
Enables AI agents to interact with ClickUp tasks, spaces, lists, and folders through the Model Context Protocol, supporting task creation, updates, moves, duplicates, and workspace organization.
Updated 2 years ago (2025-02-16 19:30 UTC)
24,921
Agent Communication MCP
Autonomous Agents Agent Orchestration
mattes337
A
license
Not graded
quality
D
maintenance
Facilitates autonomous AI agent collaboration on software projects through file-based task management and inter-agent communication via the Model Context Protocol.
Updated a year ago (2025-07-08 08:29 UTC)
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/greendwin/mcp-tasker'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Tasker

Installation

Quick Start

Usage

Create tasks

Update status

View tasks

TODO list

Edit tasks

Organize

Resolve merge conflicts

Shortcuts

MCP Server

Configure in Claude Code

Configure per-project (.mcp.json)

HTTP transport

Available tools

Development

Requirements

Release Notes

1.8.1

1.8.0

1.7.0

1.6.0

1.5.0

1.4.2

1.4.1

1.4.0

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.0

1.1.0

1.0.0

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Configure per-project (`.mcp.json`)