Una potente aplicación de gestión de tareas alojada localmente con integración con Obsidian y un servidor de Protocolo de Contexto de Modelo (MCP).
Gestión inteligente de tareas : crea tareas con niveles de urgencia y estimaciones de esfuerzo
Motor de priorización : clasifica automáticamente las tareas por urgencia y esfuerzo
Descomposición de tareas : divida las tareas más grandes en subtareas manejables
Sistema de etiquetado : organice tareas con etiquetas personalizadas
Almacenamiento local : todos los datos se almacenan localmente en la base de datos SQLite
Integración con Obsidian : sincronización bidireccional con archivos Markdown de Obsidian
Servidor MCP : acceso completo a la API a través del Protocolo de contexto de modelo
Related MCP server: Deferno MCP Server
Tareas : Entidad de tarea principal con propiedades:
Título y descripción
Urgencia (escala del 1 al 5, siendo 5 la más alta)
Esfuerzo (escala 1-21, siguiendo la secuencia de Fibonacci)
Estado de finalización
Relaciones padre-hijo para subtareas
Etiquetas para categorización
La aplicación utiliza SQLite con las siguientes tablas:
todos : almacena todos los elementos de la tarea y sus propiedades
tags : almacena nombres de etiquetas únicos
todo_tags : Tabla de unión para la relación de muchos a muchos entre tareas y etiquetas
DeltaTask crea y mantiene una bóveda de Obsidian estructurada:
Archivos de tareas con metadatos de portada
Vistas basadas en etiquetas para filtrar tareas
Panel de estadísticas
Sincronización bidireccional entre Markdown de Obsidian y la base de datos SQLite
El servidor MCP expone las siguientes operaciones:
get_task_by_id : Obtener una tarea específica por ID
search_tasks : busca tareas por título, descripción o etiquetas
create_task : Crea una nueva tarea
update_task : Actualizar las propiedades de una tarea
delete_task : Eliminar una tarea
sync_tasks : Sincroniza tareas desde Obsidian Markdown a SQLite
list_tasks : Listar todas las tareas
get_statistics : recupera métricas sobre las tareas
create_subtasks : Divide una tarea en múltiples subtareas
get_all_tags : Obtener todos los nombres de etiquetas únicos
get_subtasks : Obtener subtareas para una tarea principal determinada
finish_task : Marcar una tarea como completada
Python 3.10+
SQLite3
Obsidian (opcional, para integración de rebajas)
Clonar este repositorio
Configurar el entorno de Python usando uv :
# Create and activate the virtual environment
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install dependencies
uv pip install -r requirements.txtEl servidor DeltaTask MCP se puede utilizar con Claude for Desktop:
Configurar Claude para escritorio:
Abra o cree ~/Library/Application Support/Claude/claude_desktop_config.json
Agregue la configuración del servidor DeltaTask:
{
"mcpServers": {
"deltatask": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/DeltaTask",
"run",
"server.py"
]
}
}
}Reiniciar Claude para escritorio
Si tiene problemas o desea más detalles, consulte la documentación del MCP .
Por ejemplo, de los documentos:
Es posible que necesites introducir la ruta completa del ejecutable uv en el campo command . Puedes obtenerla ejecutando which uv en macOS/Linux o where uv en Windows.
Utilice las herramientas DeltaTask en Claude for Desktop haciendo clic en el ícono del martillo
Esta aplicación implementa un enfoque de Protocolo de Contexto de Modelo para la gestión de tareas:
Modelo de datos estructurado : esquema claramente definido para tareas con relaciones
Cálculo de prioridad : clasificación inteligente basada en múltiples factores
Organización jerárquica : relaciones padre-hijo para la descomposición de tareas
Sistema de etiquetado : categorización flexible para un mejor contexto
Estadísticas y perspectivas : agregación de datos para comprender patrones de tareas
Integración con Obsidian : visualización y edición basadas en Markdown
Licencia 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.