Skip to main content
Glama

create_task

Crea una tarea en el workspace. Nace pending, con source_type: 'mcp'.

RESPONSABLE — `assignee` es UNA persona del Atlas (nombre canónico o id) y
es lo que contesta "¿de quién es?". No es lo mismo que `people`, que son
las personas RELACIONADAS (aparecen en la nota, hay que avisarles), ni que
`owner` ('yo' | 'otro'), que dice si se delegó pero no a quién. Se valida
que la persona sea de ESTE workspace: un responsable de otro no se ve en
ningún tablero de éste y quedaría una tarea con dueño invisible.

FECHA vs HORA — `due_date` es el día en que vence. Si además pasás
`remind_time` ("HH:MM", en la zona del usuario), la tarea se vuelve un
RECORDATORIO: suena el teléfono a esa hora. Eso escribe tres cosas —la
línea en la nota del día, su segmento y la fila del cron—, porque guardar la
hora en la tarea NO la hace sonar: el cron mira la tabla `reminders` y nada
más, y la línea de la nota es la fuente de verdad (borrarla cancela el
aviso). Si la hora ya pasó, la tarea se crea igual y la respuesta avisa que
el aviso no se programó — prometer uno que no puede sonar es peor que no
prometerlo.

TRAMO — `start_date`/`end_date` es cuánto dura en la línea de tiempo.
Declararlo fija también `due_date` igual al fin, para que la barra y la
pastilla de la lista no digan cosas distintas. Sin tramo la tarea se dibuja
como un rombo en su vencimiento, que es lo correcto: "dura un día" no lo
dijo nadie.

BACKLOG — `backlog: true` la deja pendiente pero fuera del radar. No es un
estado: convive con `pending`.

PRIVADA — `private: true` la saca de todo listado compartido: no entra en
ningún tablero ni siquiera incluida a mano. Una privada tampoco sube a
ClickUp ni a Jira.

DÓNDE VIVE — por defecto la tarea nace en Secondbrain y, si el workspace
tiene una lista de ClickUp o un proyecto de Jira "por defecto", sube sola
ahí (la respuesta lo dice en `destino_externo`). Para decidirlo:
· `jira_project`  — "creala en Jira": clave, nombre o id del proyecto.
· `clickup_list`  — "en ClickUp / en la lista UBI": nombre o id de la lista.
· `solo_en_secondbrain: true` — que NO suba a ninguna herramienta.
Se pasa UNO. Si no se sabe cómo se llama el destino, get_task_destinations
los lista. La sube la sync en segundos con la conexión del workspace.

Input Schema

NameRequiredDescriptionDefault
ownerNo¿La hago yo o está delegada? No dice a quién — para eso está assignee
titleYesTítulo descriptivo de la tarea
peopleNoPersonas RELACIONADAS (nombres canónicos del Atlas). No es el responsable.
urgentNoMarcarla urgente a mano, más allá de lo que diga la fecha
backlogNoApartarla del radar sin dejar de estar pendiente
privateNoNo se comparte a ningún tablero, nunca
urgencyNoSólo se usa si no hay due_date: con fecha, la urgencia se deriva de ella
assigneeNoResponsable: nombre canónico de la persona en el Atlas, o su id numérico
due_dateNoVencimiento, YYYY-MM-DD
end_dateNoFin del tramo, YYYY-MM-DD (fija due_date al mismo día)
projectsNoNombres canónicos de proyectos del Atlas
start_dateNoInicio del tramo, YYYY-MM-DD
descriptionNoContexto, notas, o qué hay que hacer exactamente
remind_timeNoHora del aviso, 'HH:MM' en la zona del usuario. Requiere due_date. Convierte la tarea en recordatorio.
clickup_listNoCrearla también en ClickUp: nombre o id de la lista. Ver get_task_destinations
jira_projectNoCrearla también en Jira: clave («SB»), nombre o id del proyecto. Ver get_task_destinations
workspace_idNoUUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir si el token ya tiene workspace fijo
organizationsNoNombres canónicos de organizaciones del Atlas
deliverable_idNoEntregable al que pertenece (ver get_deliverables)
solo_en_secondbrainNoNo subirla a ClickUp ni a Jira, ni siquiera a la lista por defecto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations (which only say non-readonly, non-destructive, closed-world): remind_time writes three places, the cron only reads the `reminders` table, the daily-note line is the source of truth and deleting it cancels the alert, a past time still creates the task but reports the reminder was not scheduled, and private tasks never sync to ClickUp/Jira. This is exactly the side-effect and edge-case context annotations cannot carry.

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?

Long, but front-loaded and organized into labelled sections (RESPONSABLE, FECHA vs HORA, TRAMO, BACKLOG, PRIVADA, DÓNDE VIVE) so an agent can scan it. A few clauses are discursive (the justification for why storing the hour alone is not enough), though they carry genuine behavioral value rather than filler.

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 20-parameter mutation tool with no output schema, the description covers the failure modes an agent must know (validation of the assignee against the workspace, reminder not scheduled when the time has passed) and even names the response field that reports external sync (`destino_externo`), so nothing essential is left implicit.

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%, so the baseline would be 3, but the description adds real meaning: the assignee vs people vs owner distinction (owner says delegation but not to whom; the assignee must belong to this workspace or the task gets an invisible owner), and the due_date/remind_time and start_date/end_date/due_date interactions. It also states the one-of constraint among jira_project/clickup_list/solo_en_secondbrain.

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+resource ("Crea una tarea en el workspace") and immediately states the resulting initial state (`pending`, `source_type: 'mcp'`). It is clearly distinguishable from siblings like update_task, complete_task, and get_task_destinations, which are either named or implied.

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

Usage Guidelines4/5

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

Gives explicit conditional guidance for the trickiest choices: which destination parameter to pass ("Se pasa UNO") and where to look if the destination name is unknown ("get_task_destinations los lista"). It explains when remind_time converts a task into a reminder and when urgency vs due_date applies, but never states the general 'use this instead of update_task/get_tasks' framing.

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