Skip to main content
Glama
Sign In

md-doc

by com.md-doc.app
OverviewDiscussionsAdmin

task_done

Registra que una tarea recurrente se ha hecho, con su resultado: success (hecha y comprobada según el criterio del content) o warning (hecha con problemas o sin poder comprobarla del todo; explica cuáles en el comment). Añade una entrada al historial (fecha, autor = esta API key, agent, resultado y comment; no se puede editar ni borrar), la libera si estaba en ejecución y programa la siguiente fecha. Hazlo solo cuando la hayas hecho de verdad (o el usuario te diga que la ha hecho). No incluyas secretos. TAREAS RECURRENTES: algo que hay que hacer una y otra vez (revisar vulnerabilidades, actualizar un paquete, renovar un certificado…). Su content DEBE definir con claridad (1) la actuación a realizar y (2) cómo comprobar que ha salido bien (criterio de éxito verificable), porque cada vez que se hace se registra un resultado y se juzga contra ese criterio. Tiene un calendario: cada intervalCount intervalUnit (day, week, month, year), la próxima fecha (nextDueDate, día del calendario del usuario) y el modo: from_done (la siguiente se cuenta desde el día en que se hizo, por defecto) o fixed (mantiene su calendario aunque se haga tarde). Prioridad como las issues: low, medium (por defecto), high o critical. ESTADOS (state): draft (borrador: en preparación, no está activa, no vence ni avisa), scheduled (programada: activa pero aún no es el momento), due (para realizar: activa y vencida, ya se puede hacer) e in_progress (en ejecución: alguien la está haciendo). Se crea en draft; pásala a active con tasks_update status active cuando el content tenga la actuación y cómo comprobarla (o créala ya con status active si los tiene). CÓMO EJECUTAR UNA: lo PRIMERO, antes de hacer nada, llama a task_start: la marca en ejecución para que otras IAs no la cojan. Si task_start falla porque ya está en ejecución, NO la hagas: la tiene otro. Coge solo las due salvo que el usuario te pida otra. Al terminar, registra el resultado con task_done: result success si se hizo y se comprobó según el criterio del content, o warning si se hizo pero hubo problemas o no se pudo comprobar del todo (explica cuáles en el comment). El comment debe ser autosuficiente: qué revisaste, qué encontraste y qué hiciste (versiones, CVEs, chips a issues creadas). task_done añade una entrada al historial (no se edita ni se borra), libera la tarea y programa la siguiente fecha. Si la abandonas sin hacerla, llama a task_release. Si de la revisión sale trabajo por hacer, crea una issue y enlázala en el comment con su chip. "¿Qué toca hacer?": tasks_list con state ["due"]. Nota = cómo funciona algo; bitácora = qué pasó; issue = qué falta por hacer una vez; tarea recurrente = lo que toca hacer periódicamente. Busca antes con tasks_search/tasks_list para no duplicar.

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>",
      "result": "<result>",
      "comment": "<comment>",
      "agent": "<agent>"
    },
    "name": "task_done"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesID de la tarea
agentYesIdentifícate: modelo y herramienta desde la que trabajas, p. ej. "Claude Opus 5.5 · Claude Code" o "GPT-5 · ChatGPT". Se guarda en la línea junto al nombre de la API key.
doneOnNoDía en que se hizo, YYYY-MM-DD; por defecto hoy. No futuro
resultYessuccess (correcta) | warning (con avisos)
commentYesResultado (markdown); puede incluir chips $[...]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses that a history entry is appended with date, author (= this API key) and agent, that this entry "no se puede editar ni borrar", that an in-progress lock is released, and that the next due date is scheduled. It also states a data-hygiene constraint ("No incluyas secretos") and explains when to prefer warning over success, which is exactly the kind of behavioral context the schema cannot express.

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

Conciseness2/5

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

The operative content is front-loaded and well labelled, but the text balloons to roughly 450 words, with long sections that describe the recurring-task domain rather than this tool: the taxonomy of states (draft/scheduled/due/in_progress), the calendar/intervalCount/priority model, and the closing glossary of nota vs bitácora vs issue vs tarea recurrente. Those passages belong to the task family documentation and dilute the call-relevant instructions for a 5-parameter tool.

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 a mutation tool with no annotations and no output schema, the description is nearly complete: it covers preconditions, the two result values and their evidence requirements, immutable history logging, lock release and rescheduling. The one gap is that it never says what the call returns (e.g. the newly scheduled date or the history entry), and without an output schema an agent cannot know whether the next due date comes back in the response.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it defines the judging standard for result (success = done and verified against the content's criterion; warning = done with problems or unverifiable, with the reasons in the comment) and specifies what the comment must contain (what was reviewed, found, done, versions, CVEs, chips to created issues). Only doneOn and agent receive no additional narrative treatment, which keeps it below 5.

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

Purpose5/5

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

The opening sentence states a specific verb and resource plus side effects: "Registra que una tarea recurrente se ha hecho, con su resultado... Añade una entrada al historial... la libera si estaba en ejecución y programa la siguiente fecha." It also distinguishes itself from siblings by naming task_start (must be called first) and task_release (for abandonment), so an agent can tell which tool records completion versus which starts or releases a task.

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?

Explicit when-to-use and when-not: "Hazlo solo cuando la hayas hecho de verdad (o el usuario te diga que la ha hecho)", plus the pre-condition that task_start must succeed and that if task_start fails the work must not be done at all. It also routes the abandonment case to task_release and points to "tasks_list con state [due]" for the what-is-due question, so alternatives are named with their selecting conditions.

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

All md-doc toolsInspect
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