secondbrain

update_task

Destructive

Cambia una tarea: título, descripción, fecha, urgencia, estado, tramo, responsable, backlog, entregable.

Sólo se toca lo que mandás: un campo omitido queda como estaba. Para vaciar
uno, mandá `null` explícito donde el campo lo admita.

ESTADO — pasar a `completed` escribe `completed_at`; volver a `pending`
o `wip` lo limpia. Para reabrir algo cerrado es mejor rollback_task, que
además valida que estuviera cerrado.

TRAMO — mover `end_date` mueve también `due_date`: son la misma fecha
vista de dos maneras y separarlas deja las vistas contradiciéndose.

BACKLOG no es un estado: `backlog: true` con `status: 'pending'` es una
tarea pendiente apartada del radar, y es la combinación normal.

DÓNDE VIVE — `jira_project` / `clickup_list` la mandan a ese proyecto o
lista (si todavía no estaba en ninguna herramienta, la crea allá; si ya
estaba en otra, la MUEVE), y `solo_en_secondbrain: true` evita que suba.
Se pasa UNO; get_task_destinations lista los destinos. No se puede sacar
de ClickUp/Jira una tarea que ya vive allá: eso se borra con delete_task.

Input Schema

Name	Required	Description
`owner`	No	Si está delegada o no
`title`	No
`status`	No
`urgent`	No	Marca de urgente a mano
`backlog`	No	Apartar del radar / traer de vuelta
`private`	No	Sacarla o devolverla a lo compartible
`task_id`	Yes	ID numérico de la tarea
`urgency`	No
`assignee`	No	Responsable: nombre canónico o id del Atlas; null lo quita
`due_date`	No	YYYY-MM-DD, o null para quitar
`end_date`	No	Fin del tramo, YYYY-MM-DD o null (arrastra due_date)
`start_date`	No	Inicio del tramo, YYYY-MM-DD o null
`description`	No
`clickup_list`	No	Mandarla a esta lista de ClickUp: nombre o id. Ver get_task_destinations
`jira_project`	No	Mandarla a este proyecto de Jira: clave («SB»), nombre o id. Ver get_task_destinations
`workspace_id`	No	UUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir si el token ya tiene workspace fijo
`deliverable_id`	No	Entregable al que pertenece, o null
`solo_en_secondbrain`	No	Que no suba a ClickUp ni a Jira (sólo si todavía no está en ninguna)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: status transitions write/clear completed_at, moving end_date also moves due_date, destination fields move the task between tools or create it there, and solo_en_secondbrain prevents sync. These are exactly the side effects an agent needs before a destructive mutation.

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?

Organized into labeled blocks (ESTADO, TRAMO, BACKLOG, DÓNDE VIVE) with the core mutation rule front-loaded. Dense but every section carries distinct behavioral information; minor length cost from repetition of field lists already in the schema.

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 an 18-parameter destructive mutation tool with no output schema, the description covers the tricky interactions (status/date coupling, cross-tool moves, exclusivity of destination params) and points to sibling tools for adjacent operations, leaving nothing critical unaddressed.

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 78%, and the description still adds substantial semantics the schema lacks: backlog is not a status but a pending-plus-backlog combination, tramo ties start/end/due together, only ONE destination field should be passed, and null semantics for clearing.

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?

Starts with a specific verb ('Cambia') and resource ('una tarea') and enumerates exactly which fields it touches. It also distinguishes itself from siblings by naming rollback_task for reopening and delete_task for removal from ClickUp/Jira.

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 routing rules: reopening closed tasks should use rollback_task, destinations are listed via get_task_destinations, and removing a task from ClickUp/Jira requires delete_task instead. It also states that only explicit fields are changed and null clears them.

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

All secondbrain tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?