md-doc

tasks_update

Actualiza una tarea recurrente (parcial): título, contenido, carpeta, etiquetas, prioridad, calendario (intervalo, modo, próxima fecha) y status draft | active (activarla exige content). Para ejecutarla usa task_start / task_done / task_release, no status. Para registrar que se ha hecho usa task_done, no cambies nextDueDate a mano. Con folderId la mueve; a una carpeta que otro te ha compartido con rol full solo puedes mover tareas tuyas, y pasan a ser de su dueño. Para asociar/enlazar recursos, incrusta chips en el content con el patrón $[note::] (o $[expedient::], $[log::<título>] para una bitácora, $[issue::<título>] para una issue, $[task::<título>] para una tarea recurrente, $[environment::] para un entorno). Al guardar, el grafo de referencias se actualiza automáticamente. Ejemplo: para enlazar con la nota 42 titulada "Contrato", incluye el texto $[note:42:Contrato] en el content.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "tasks_update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	ID de la tarea
`tags`	No
`title`	No
`status`	No	draft (en preparación) \| active
`content`	No
`folderId`	No
`priority`	No	low \| medium (por defecto) \| high \| critical
`nextDueDate`	No	Próxima fecha, YYYY-MM-DD
`intervalUnit`	No	day \| week \| month (por defecto) \| year
`scheduleMode`	No	from_done (por defecto: la siguiente se cuenta desde que se hace) \| fixed (calendario fijo)
`intervalCount`	No	Cada cuántas unidades se repite (por defecto 1)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden and it does add real context: ownership transfer when moving into a full-role shared folder, automatic reference-graph rebuild on save, and the content precondition for activation. It does not cover what a partial update does to unspecified fields not listed, error behavior, or what the response contains, so gaps remain 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.

Conciseness4/5

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

Front-loaded with the core verb and resource, and every clause carries a constraint or an alternative that an agent needs. It is one dense run-on paragraph with long subclauses, which makes it slower to scan than a bulleted structure would be.

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

Completeness4/5

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

For an 11-parameter mutation tool with no annotations and no output schema, it covers the highest-risk semantics: execution path, activation precondition, folder ownership, and reference linking. It leaves unstated whether omitted array fields like tags replace or merge, and what the call returns.

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

Parameters4/5

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

Schema coverage is 64%, and the description compensates by explaining status semantics, the folderId side effect, the nextDueDate warning, and the chip syntax for content ($[note:<id>:<etiqueta>] and five other resource types) with a worked example. The interval/schedule parameters are left entirely to the schema, so it stops short of full coverage.

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

Purpose5/5

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

"Actualiza una tarea recurrente (parcial)" is a specific verb plus resource with scope (partial update), followed by an enumeration of the mutable fields. It also distinguishes the update path from execution siblings (task_start/task_done/task_release), so an agent can place it without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes execution to task_start/task_done/task_release rather than the status field, and warns not to hand-edit nextDueDate but to use task_done to record completion. It also states the precondition that setting status=active requires content, plus the shared-folder ownership rule for folderId moves.

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

All md-doc tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?