This server lets an MCP client manage tasks on Obsidian Kanban boards and their linked notes through the Obsidian Local REST API.
List all boards with lanes and card counts.
List and filter tasks by board, lane, assignee, tag, overdue status, or include closed lanes.
Fetch a single task's details: lane, frontmatter, sections, and numbered subtasks.
Create task notes from a template and add their cards to a lane (top by default, bottom with low priority).
Move cards between lanes, automatically ticking/unticking checkboxes and stamping completion when moved to Done.
Update and add subtasks, with optional blocking state that can move tasks to Blocked or In Progress.
Append dated entries to a task's Running Log.
Set task fields: Due By, Assigned to, Planned by, Tags, and Completed On.
Delete tasks (card and optionally note), with safeguards against breaking links.
Audit boards for drift: missing templates, orphan notes/cards, duplicates, checkbox/lane mismatches, and non-template notes.
Concurrency-safe writes using version tokens; board edits preserve untouched lanes and settings.
Manages tasks on Obsidian Kanban boards and their linked task notes, providing tools to list boards and tasks, create and move cards, update subtasks, set task fields, append running logs, and audit board consistency through the Obsidian Local REST API.
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., "@obsidian-tasks-mcp Create a task for 'Review PR' on the Roadmap board."
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.
An MCP server that manages tasks on Obsidian Kanban boards and the task notes behind their cards. It talks to your vault through the Local REST API plugin, so it needs no Obsidian plugin of its own and works against any vault that plugin can reach, including a headless Obsidian instance.
A generic vault MCP server can read and patch files, but keeping a board tidy takes several careful edits: create the note from the template, add the card in the right lane, tick the checkbox, stamp the completion date, avoid clobbering a concurrent edit. This server does each of those in one tool call.
Obsidian with the Local REST API plugin, version 5.0 or newer (needed for conditional writes).
The Kanban plugin, with each board a markdown file whose frontmatter has kanban-plugin: board.
Python 3.12 or newer.
Related MCP server: Obsidian Kanban MCP Server
Variable | Required | Meaning |
| yes | Base URL of the Local REST API, for example |
| yes | The plugin's API key. |
| no | Board (file name without |
Boards are discovered by their kanban-plugin: board frontmatter. Each board's own Kanban settings supply the note folder (new-note-folder) and the note template (new-note-template); without a template a built-in one is used. A board with no new-note-folder cannot create tasks, so notes never land in the vault root by accident.
claude mcp add obsidian-tasks \
--env OBSIDIAN_API_URL=http://localhost:27123 \
--env OBSIDIAN_API_KEY=... \
-- uvx --from git+https://github.com/rarosalion/obsidian-tasks-mcp obsidian-tasks-mcpTool | What it does |
| Boards with their lanes and card counts. |
| Cards with lane, checkbox, due date, assignee, tags and subtask progress. Filter by board, lane, |
| One task's lane, frontmatter, sections and numbered subtasks. |
| Writes a task note from the template and adds its card, on top of the lane by default or at the bottom with |
| Moves a card between lanes. Moving to Done ticks it and stamps |
| Ticks or unticks a subtask by number or text, appending a dated note. |
| Adds a subtask to a note. |
| Adds a dated entry to the note's Running Log. |
| Sets |
| Permanently removes a task's card and, by default, its note. Refuses when other notes link to the note (that would leave broken links) unless |
| Read-only drift report: boards with no |
Recording work on a task that sits in a To Do lane (a ticked subtask or a log entry) moves it to In Progress, or to Blocked when the caller passes blocked=true. Cards in any other lane are never moved automatically.
Lanes are recognised by name, case-insensitively: To Do, In Progress, Blocked or Waiting (or Blocked, Waiting), Done (or Complete), and Cancelled or Archive (which never carry a ticked checkbox). Other lanes are left alone. Cards link to their note with a wikilink, - [ ] [[Task title]].
A task note has flat frontmatter (Due By, Assigned to, Planned by, Tags, Completed On) and top-level sections # Summary, # Subtasks, # Detailed Plan, # Questions to Consider and # Running Log. %% ... %% comments in the template are dropped from new notes. Tags is written as a YAML block list (one - tag line each), because Obsidian only treats that form as a list; a comma-separated string is read for compatibility but reported by audit_boards as tags_not_list.
Every write reads the file's version token first and sends it back with the change. If the file changed in between (for instance you edited the board in Obsidian), the write is refused and retried against the fresh content, so concurrent edits are never overwritten. Board edits are line-based: lanes, cards and the Kanban settings block that a call does not touch are left exactly as they were. The REST API adds a trailing newline to a file that lacked one when it is rewritten.
uv sync
uv run pytest
uv run ruff check . && uv run ruff format --check .The tests use an in-memory vault and synthetic boards, so they need no running Obsidian.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| after | No | ||
| board | No | ||
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | ||
| entry | Yes | ||
| title | Yes | ||
| blocked | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| include_closed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | No | To Do | |
| tags | No | ||
| board | No | ||
| title | Yes | ||
| due_by | No | ||
| summary | No | ||
| priority | No | normal | |
| subtasks | No | ||
| questions | No | ||
| planned_by | No | Claude | |
| assigned_to | No | ||
| detailed_plan | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | ||
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| lane | No | ||
| board | No | ||
| overdue | No | ||
| assigned_to | No | ||
| include_closed | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | ||
| title | Yes | ||
| to_lane | Yes | ||
| priority | No | normal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| board | No | ||
| title | Yes | ||
| due_by | No | ||
| planned_by | No | ||
| assigned_to | No | ||
| completed_on | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| board | No | ||
| title | Yes | ||
| blocked | No | ||
| checked | No | ||
| subtask | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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 has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.0add_subtaskappend_logaudit_boardscreate_taskget_tasklist_boardslist_tasksmove_taskset_task_fieldsupdate_subtaskScored across 10 tools
Most tools are distinct (create, list, get, move, audit), but update_subtask, add_subtask, and set_task_fields overlap in scope—all modify task structure or fields, and their boundaries are unclear without descriptions. append_log is also ambiguous: it could be a task update or a separate logging feature.
Tool names mostly follow a verb_noun pattern (create_task, list_tasks, get_task, move_task, audit_boards). However, set_task_fields and append_log break the pattern slightly, and update_subtask vs add_subtask are consistent but less specific than the main task verbs.
10 tools is a reasonable size for a task management server, covering core operations without bloat. The count feels appropriate, though a few tools could potentially be consolidated.
The surface covers task creation, retrieval, listing, moving, subtask management, and board auditing, but lacks obvious operations like update_task, delete_task, or complete_task. The presence of set_task_fields and append_log suggests some update capability, but the absence of a clear delete/archive operation is a notable gap.
Read and manage your EasyKanban kanban boards: to-do summaries, create, update, and move cards.
Create and drive KanbanThing kanban boards. No account, no API key, board link required.
Manage Kanera workspaces, boards, cards, checklists, comments, notes, automations, and reports.
A todo and task board in kanban form, driven from chat with full CRUD.
