Skip to main content
Glama

tasks_create

Crea una tarea recurrente, en borrador (draft) salvo status active. El content debe tener la actuación a realizar y cómo comprobar que ha salido bien; sin content no se puede activar. Sin nextDueDate la primera vez toca hoy. Devuelve el chip $[task:id:título]. Con folderId la crea en esa carpeta (ver task_folders_list). 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. 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": {
      "title": "<title>",
      "content": "<content>"
    },
    "name": "tasks_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoEtiquetas
titleYesTítulo, p. ej. "Revisar vulnerabilidades de md-doc"
statusNodraft (por defecto) | active (ya definida)
contentYesMarkdown con "Qué hay que hacer" y "Cómo comprobar que está bien". Puede incluir chips.
folderIdNoCarpeta de tareas destino; null/omitir = raíz
priorityNolow | medium (por defecto) | high | critical
nextDueDateNoPróxima fecha, YYYY-MM-DD
intervalUnitNoday | week | month (por defecto) | year
scheduleModeNofrom_done (por defecto: la siguiente se cuenta desde que se hace) | fixed (calendario fijo)
intervalCountNoCada cuántas unidades se repite (por defecto 1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the draft-by-default behavior, that a task cannot be activated without content, that nextDueDate defaults to today on first occurrence, that the call returns a chip token, and that the reference graph is updated automatically on save. It also explains state semantics (draft/scheduled/due/in_progress) and what task_done does to the history.

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

Conciseness3/5

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

The opening sentence is well front-loaded and the core creation semantics come early, but a large share of the text is workflow instruction for other tools (task_start, task_done, task_release, tasks_list) plus a full chip-syntax catalogue and a concrete example. Useful context, but it bloats a create tool's definition and buries the essential parts.

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

Completeness5/5

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

For a 10-parameter mutation tool with no annotations and no output schema, nothing important is missing: defaults, required fields, side effects, return token, state transitions and cross-tool references are all covered.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds meaning the schema lacks: content must encode both the action and a verifiable success criterion, nextDueDate defaults to today, folderId is cross-referenced to task_folders_list, and scheduleMode/invervalCount semantics (from_done vs fixed calendars) are explained beyond the enum labels.

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?

Opens with a specific verb and resource: 'Crea una tarea recurrente', and immediately states the default state ('en borrador (draft) salvo status active'). This distinguishes creation from sibling operations such as tasks_update, task_start and task_done, which are explicitly named as separate steps.

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?

Gives explicit when-to guidance (search first with tasks_search/tasks_list to avoid duplicates, create in draft and promote with tasks_update when content is complete, or create directly with status active), plus the execution lifecycle that follows creation. It also defines the concept boundary between nota, bitácora, issue and tarea recurrente, so the agent knows this tool is only for recurring work.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources