Skip to main content
Glama

tasks_search

Busca tareas recurrentes por texto (título/contenido). 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": {
      "query": "<query>"
    },
    "name": "tasks_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesTexto a buscar

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it never states that the operation is read-only, whether it searches across all states (draft, due, in_progress) or only active ones, whether matching is substring/fuzzy/case-insensitive, or any result limits. The bulk of the text instead documents the recurring-task domain model and the task_start/task_done workflow, which belongs to sibling tools rather than to this search call.

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?

Only the first sentence and the final duplicate-check note are about this tool; the intervening paragraphs explain statuses, calendar modes, priorities, and the task_start/task_done/task_release execution protocol — instructions for other tools that inflate and bury the search-specific content.

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

Completeness3/5

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

The tool is simple (one required string parameter, 100% schema coverage), so the domain exposition is far more than needed, yet the description still omits result shape and ordering (no output schema exists to compensate) and does not clarify which task states are searchable.

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

Parameters3/5

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

Schema coverage is 100% (single required 'query' with 'Texto a buscar'), so the baseline is 3. The description adds real value by narrowing the match scope to 'título/contenido', but stops short of specifying match semantics such as substring vs exact, accent handling, or case sensitivity.

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

Purpose4/5

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

The opening sentence is a precise verb+resource+scope: 'Busca tareas recurrentes por texto (título/contenido)'. It partially distinguishes itself from tasks_list, which the description ties to state-filtered listing ('¿Qué toca hacer?': tasks_list con state ['due']), but it never explicitly says search-by-text vs list-by-state is the dividing line.

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

Usage Guidelines3/5

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

There is one concrete usage rule: 'Busca antes con tasks_search/tasks_list para no duplicar', i.e. use it to check for duplicates before creating. However, there is no explicit guidance on when to pick tasks_search over tasks_list, whether it should be used for non-recurring lookups, or what happens when the query matches nothing.

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