一个功能强大的、本地托管的任务管理应用程序，具有 Obsidian 集成和模型上下文协议 (MCP) 服务器。
智能任务管理：创建具有紧急程度和工作量估算的任务
优先级引擎：根据紧急程度和努力程度自动对任务进行排序
任务分解：将较大的任务拆分为可管理的子任务
标记系统：使用自定义标记组织任务
本地存储：所有数据都本地存储在 SQLite 数据库中
Obsidian 集成：与 Obsidian markdown 文件双向同步
MCP 服务器：通过模型上下文协议实现完整的 API 访问
Related MCP server: Deferno MCP Server
任务：核心任务实体，具有以下属性：
标题和描述
紧急程度（1-5 级，5 为最高）
努力程度（1-21 等级，遵循斐波那契数列）
完成状态
子任务的父子关系
分类标签
该应用程序使用带有下表的 SQLite：
todos ：存储所有任务项及其属性
tags ：存储唯一标签名称
todo_tags ：任务和标签之间的多对多关系连接表
DeltaTask 创建并维护一个结构化的 Obsidian 保险库：
带有前置元数据的任务文件
基于标签的视图用于过滤任务
统计信息仪表板
Obsidian markdown 与 SQLite 数据库之间的双向同步
MCP 服务器公开以下操作：
get_task_by_id ：通过 ID 获取特定任务
search_tasks ：按标题、描述或标签查找任务
create_task ：创建新任务
update_task ：更新任务的属性
delete_task ：删除任务
sync_tasks ：将 Obsidian markdown 中的任务同步到 SQLite
list_tasks ：列出所有任务
get_statistics ：检索有关任务的指标
create_subtasks ：将任务拆分为多个子任务
get_all_tags ：获取所有唯一标签名称
get_subtasks ：获取给定父任务的子任务
finish_task ：将任务标记为已完成
Python 3.10+
SQLite3
Obsidian（可选，用于 markdown 集成）
克隆此存储库
使用uv设置 Python 环境：
# Create and activate the virtual environment
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install dependencies
uv pip install -r requirements.txtDeltaTask MCP 服务器可与 Claude for Desktop 一起使用：
配置 Claude 桌面版：
打开或创建~/Library/Application Support/Claude/claude_desktop_config.json
添加 DeltaTask 服务器配置：
{
"mcpServers": {
"deltatask": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/DeltaTask",
"run",
"server.py"
]
}
}
}重启 Claude 桌面版
如果您遇到问题或想要了解更多详细信息，请查看MCP 的文档。
例如来自文档：
您可能需要在command字段中输入uv可执行文件的完整路径。您可以在 MacOS/Linux 上运行which uv或在 Windows 上运行where uv来获取此路径。
单击锤子图标即可使用 Claude for Desktop 中的 DeltaTask 工具
该应用程序实现了用于任务管理的模型上下文协议方法：
结构化数据模型：具有关系的任务的明确定义的模式
优先级计算：基于多种因素的智能排序
层级组织：任务分解的父子关系
标记系统：灵活分类，提供更好的上下文
统计和洞察：用于理解任务模式的数据聚合
Obsidian Integration ：基于 Markdown 的可视化和编辑
MIT 许可证
Create multiple subtasks for a parent task with categories.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| subtasks | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify permissions required, whether changes are reversible, rate limits, or what happens if the parent task doesn't exist. The mention of 'categories' hints at additional behavior but is vague, leaving significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It's front-loaded with the core action, though the trailing phrase 'with categories' feels slightly tacked on. Overall, it's concise and well-structured for its length.
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 has an output schema (which reduces the need to describe return values) but no annotations and 0% schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on usage, parameters, and behavioral traits, making it incomplete for a mutation tool with undocumented parameters.
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 0%, so the schema provides no parameter details. The description mentions 'categories' but doesn't explain how this relates to the 'subtasks' array parameter or what 'task_id' should be. It adds minimal meaning beyond the bare parameter names, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple subtasks') and the target resource ('for a parent task'), which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'create_task' or 'update_task', which prevents a perfect score. The mention of 'categories' adds some specificity but isn't fully explained.
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 no guidance on when to use this tool versus alternatives like 'create_task' or 'update_task'. It doesn't mention prerequisites (e.g., needing an existing parent task) or exclusions (e.g., not for single subtasks). Without such context, an AI agent might struggle to select this tool appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | No | ||
| urgency | No | ||
| effort | No | ||
| tags | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 'Create a new task' which implies a write operation, but doesn't disclose behavioral traits such as required permissions, whether creation is idempotent, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
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 extremely concise with a single sentence 'Create a new task.', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, but based on the dimension criteria, it scores high for being appropriately sized.
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 complexity (5 parameters, 1 required, mutation operation) and the presence of an output schema, the description is incomplete. It doesn't provide enough context for an AI agent to understand usage, parameters, or behavior, especially with no annotations and low schema coverage. The output schema helps but doesn't compensate for the lack of descriptive context.
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 0%, so the schema provides no descriptions for parameters. The tool description adds no information about parameters, failing to compensate for the coverage gap. It doesn't explain what 'title', 'urgency', 'effort', etc., mean or how they affect task creation.
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 'Create a new task' clearly states the action (create) and resource (task), but it's generic and doesn't differentiate from sibling tools like 'create_subtasks' or 'update_task'. It's not tautological but lacks specificity about what kind of task or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_subtasks', 'update_task', or 'list_tasks'. The description implies usage for creating tasks but doesn't specify prerequisites, exclusions, or contextual cues for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete a task' implies a destructive mutation but reveals nothing about permissions required, whether deletion is permanent or soft, confirmation prompts, cascading effects on subtasks, or error conditions. This is inadequate for a destructive operation with zero annotation coverage.
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 extremely concise at three words with no wasted language. It's front-loaded with the core action and resource. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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 this is a destructive tool with no annotations, 0% schema coverage, but with an output schema present, the description is incomplete. It fails to address critical context like safety implications, permissions, or what the output might indicate (success/failure details). The output schema may help, but the description doesn't bridge the gap for a high-stakes operation.
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 0%, so the description must compensate for undocumented parameters. The single parameter 'task_id' receives no explanation in the description—no format examples, sourcing guidance, or validation rules. While only one parameter exists, the description adds zero semantic value beyond what the bare schema provides.
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 'Delete a task' clearly states the action (delete) and target resource (task), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'finish_task' or 'update_task' that also modify task states, leaving some ambiguity about when deletion is appropriate versus other modifications.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'finish_task', 'update_task', and 'sync_tasks' available, there's no indication whether deletion is permanent, reversible, or preferred over other state changes. The agent receives no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a task as completed.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Mark as completed' implies a mutation operation, but it doesn't specify whether this is reversible, if it triggers notifications, what permissions are required, or how it affects related data (e.g., subtasks). The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's perfectly front-loaded and appropriately sized for a simple operation, making it easy to parse quickly.
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 that there's an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a mutation tool with no annotations and multiple sibling alternatives, it should provide more context about behavior and usage to be truly complete. It meets minimum viability but has clear 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 description doesn't mention parameters, but with only one parameter (task_id) and 0% schema description coverage, the baseline would be lower. However, the tool name and description strongly imply that 'task_id' identifies which task to complete, providing sufficient semantic context for this simple case. The description effectively compensates for the schema gap through implication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark as completed') and resource ('a task'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_task' which might also handle task completion, so it falls short of a perfect score.
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 no guidance on when to use this tool versus alternatives like 'update_task' or 'delete_task'. There's no mention of prerequisites (e.g., task must exist), constraints, or typical scenarios for completion versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all unique tag names used in tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. The description is too minimal to adequately inform the agent about behavioral traits beyond the basic action.
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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get all unique tag names'), making it immediately understandable. Every word earns its place, and there's no redundancy or unnecessary elaboration.
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 (zero parameters, read-only operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about scope (e.g., all tasks vs. filtered), behavioral details (e.g., performance, auth), and usage guidance, leaving gaps that could hinder optimal tool selection.
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 input schema has 100% description coverage (though empty). The description appropriately doesn't discuss parameters since none exist, which is correct. A baseline of 4 is applied for zero-parameter tools, as there's no need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all unique tag names used in tasks'), making the purpose immediately understandable. It distinguishes from siblings like 'list_tasks' or 'get_task_by_id' by focusing specifically on tags rather than tasks themselves. However, it doesn't specify the scope (e.g., across all tasks or within a filter) which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'search_tasks' (which might filter by tags) or 'get_statistics' (which might include tag analytics). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get task statistics including completion rates and urgency distribution.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), but doesn't address important behavioral aspects like whether this aggregates data across all tasks, requires specific permissions, has rate limits, or provides real-time versus cached statistics.
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 a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a zero-parameter tool and front-loads the core functionality.
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 has zero parameters, 100% schema coverage, and an output schema exists, the description is reasonably complete for its core purpose. However, as a statistical aggregation tool with no annotations, it should ideally provide more context about scope (e.g., 'across all tasks' or 'for current user') and behavioral characteristics.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on what statistics are returned rather than how to filter them.
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 purpose as retrieving task statistics with specific metrics (completion rates and urgency distribution). It uses a specific verb ('Get') and resource ('task statistics'), but doesn't explicitly distinguish this from sibling tools like 'list_tasks' or 'search_tasks' which might also provide statistical insights.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when this statistical view is preferable to listing or searching tasks, nor does it specify any prerequisites or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get subtasks for a given parent task ID.
| Name | Required | Description | Default |
|---|---|---|---|
| parent_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe traits like whether it's read-only (implied but not explicit), requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple retrieval tool, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks context on behavioral traits and usage scenarios, making it incomplete for optimal agent understanding.
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 description adds minimal meaning beyond the input schema, which has 0% description coverage. It clarifies that 'parent_id' is for a 'parent task ID', but doesn't explain format, validation, or examples. With one parameter and low schema coverage, the description partially compensates but lacks depth, aligning with the baseline for moderate schema support.
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 verb ('Get') and resource ('subtasks'), specifying it retrieves subtasks for a given parent task ID. It distinguishes from siblings like 'get_task_by_id' (single task) and 'list_tasks' (all tasks), though it doesn't explicitly contrast them. The purpose is specific but could be more precise about scope (e.g., all subtasks vs. filtered).
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid parent task ID), exclusions, or comparisons to siblings like 'get_task_by_id' (for parent details) or 'list_tasks' (for broader queries). Usage is implied only by the tool name and parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific task by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets details' which implies a read operation, but doesn't disclose whether this requires authentication, has rate limits, returns partial vs complete data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information. Every word earns its place in this minimal but complete statement.
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 low complexity (single parameter, simple lookup) and the presence of an output schema (which handles return values), the description is adequate but minimal. It covers the basic purpose but lacks behavioral context that would be helpful since there are no annotations. For a read operation with output schema, this is the minimum viable.
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 description adds meaningful context about the 'task_id' parameter by specifying it's used 'by ID' to get details for 'a specific task'. With 0% schema description coverage (the schema only has titles, no descriptions), this compensates well. However, it doesn't specify the ID format or constraints, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('for a specific task by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'list_tasks' (which returns multiple tasks) and 'get_subtasks' (which focuses on subtasks). However, it doesn't specify what details are returned, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'list_tasks' or 'search_tasks'. It mentions 'by ID' which implies you need the ID, but doesn't explicitly state prerequisites or compare to sibling tools. There's no discussion of when-not-to-use scenarios or alternatives for similar needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks with optional tags, if you user asks for a tag, please provide it in the request.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that tags are optional and how to handle user requests for tags, but fails to describe key behaviors such as pagination, sorting, rate limits, authentication needs, or what the output looks like. This leaves significant gaps for a tool that likely returns a list of tasks.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It front-loads the core purpose and includes the key detail about tags. However, the phrasing 'if you user asks' contains a minor grammatical error ('you user' instead of 'the user'), slightly detracting from clarity.
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 that there is an output schema (which should document return values), the description doesn't need to explain outputs. However, for a list tool with no annotations and low schema coverage, it should provide more context on behavior (e.g., pagination, limits) and parameter usage. The description is minimally adequate but has clear gaps in completeness.
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 0% description coverage, so the description must compensate. It explains that 'tags' is an optional parameter for filtering, which adds some meaning beyond the schema's type definition. However, it doesn't clarify the semantics of the tags (e.g., how they match tasks, if multiple tags are AND/OR logic), leaving the parameter only partially documented.
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 verb ('List') and resource ('all tasks'), making the purpose understandable. It also mentions optional filtering by tags, which adds specificity. However, it doesn't explicitly differentiate this tool from sibling tools like 'search_tasks' or 'get_all_tags', which prevents a perfect score.
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 implied usage by mentioning that tags are optional and should be included if the user asks for them. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_tasks' or 'get_all_tags', and doesn't specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search tasks by title, description, or tags.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the search functionality but omits critical details such as pagination behavior, rate limits, authentication requirements, or whether it's read-only. The description is too sparse for a tool with potential complexity.
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 extremely concise with a single sentence that directly states the tool's function. It is front-loaded with no wasted words, making it efficient for quick understanding.
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 has an output schema (which handles return values) and no annotations, the description is minimally adequate but lacks depth. It covers the basic purpose but misses behavioral context and detailed parameter guidance, making it incomplete for effective agent use without additional inference.
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 0%, so the description must compensate. It mentions searchable fields ('title, description, or tags'), which adds some meaning beyond the schema's generic 'query' parameter, but does not explain how the query parameter interacts with these fields (e.g., syntax, matching rules). This partial compensation is insufficient for full clarity.
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 purpose with a specific verb ('Search') and resource ('tasks'), and specifies searchable fields ('title, description, or tags'). It distinguishes from siblings like 'list_tasks' by indicating filtering capability, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_tasks' or 'get_task_by_id' is provided. The description implies usage for filtered searches but lacks context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync tasks from Obsidian markdown into SQLite.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions syncing but doesn't disclose behavioral traits like whether this is a read-only or destructive operation, how conflicts are handled, authentication needs, or rate limits. This is inadequate for a sync tool with potential data mutation implications.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a sync operation with no annotations, it lacks details on behavior, error handling, or integration context, which could be important for an AI agent to use it correctly.
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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it implies the sync operation might have implicit inputs (e.g., source files), though not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('sync') and resources involved ('tasks from Obsidian markdown into SQLite'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings (like create_task, update_task, list_tasks) in terms of when sync operations are needed versus direct CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like create_task, update_task, and list_tasks, the description doesn't specify scenarios for syncing from Obsidian versus direct database operations, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| updates | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Update' implies a mutation, but doesn't specify required permissions, whether updates are reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a basic tool and front-loads the core action ('Update'). Every word earns its place, making it easy to parse quickly.
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 complexity (mutation with nested parameters) and lack of annotations, the description is incomplete—it doesn't cover behavioral risks or parameter details. However, an output schema exists, so return values needn't be explained. This partially mitigates gaps, but overall guidance remains minimal for safe use.
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 0%, so the description must compensate for undocumented parameters. It mentions 'an existing task' which hints at 'task_id', but doesn't explain 'updates' (a nested object with additionalProperties). Without details on valid update fields or formats, the description adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Update') and resource ('an existing task'), making the basic purpose clear. However, it's vague about what aspects of a task can be updated and doesn't differentiate from sibling tools like 'finish_task' or 'sync_tasks' that might also modify tasks. It's a minimal but functional statement of 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid task_id), exclusions, or comparisons to siblings like 'finish_task' (which might mark completion) or 'sync_tasks' (which might batch updates). Without this context, agents must infer usage from tool names alone.
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.
create_subtaskscreate_taskdelete_taskfinish_taskget_all_tagsget_statisticsget_subtasksget_task_by_idlist_taskssearch_taskssync_tasksupdate_taskScored across 12 tools
Every tool has a clearly distinct purpose with no ambiguity. For example, create_task and create_subtasks handle different operations, while list_tasks and search_tasks offer complementary but non-overlapping ways to retrieve tasks. The descriptions clearly differentiate each tool's function.
All tool names follow a consistent verb_noun pattern using snake_case, such as create_task, delete_task, and get_subtasks. This predictability makes it easy for an agent to understand and select the appropriate tool without confusion.
With 12 tools, the server is well-scoped for task management, covering CRUD operations, subtasks, tags, statistics, and syncing. Each tool earns its place by addressing a specific need in the domain without being excessive or insufficient.
The tool surface provides complete CRUD and lifecycle coverage for task management, including creation, retrieval, updating, deletion, completion, subtasks, tags, search, statistics, and syncing. There are no obvious gaps that would hinder an agent's workflow.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Notes, kanban tasks, and a capture inbox: read and create Flow data with a personal token.