Skip to main content
Glama

Detener/pausar registro de tiempo en una tarea

stop_task_timer

Stops the active timer for a specified task, recording the end time. Optionally includes a reason and creates a follow-up task for another person.

Instructions

Cierra el registro de tiempo activo de la tarea indicada con la fecha/hora de fin. Opcionalmente acepta una razón y puede crear una tarea de seguimiento para otra persona (por ejemplo, si se pausa porque se está esperando una respuesta suya). Solo puede hacerlo el usuario asignado o un admin.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesToken de sesión
reasonNoMotivo de la pausa, ej: 'esperando respuesta de Juan'
taskIdYes
followUpTaskNoSi se indica, crea una tarea asignada a esa persona con este contenido
Behavior3/5

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

With no annotations, the description carries full burden. It reveals that it closes time registration with end time, can create a follow-up task, and has access control. However, it doesn't mention side effects (e.g., notifications, record immutability) or return behavior.

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

Conciseness5/5

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

Three sentences, front-loaded with main action, no redundant phrasing. Efficiently covers primary function, optional behavior with example, and access restriction.

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?

Despite no output schema or annotations, the description adequately covers main action, optional parameters, a use case, and access control. Lacks return value hints but is otherwise complete for a relatively simple tool.

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 coverage is 75% (taskId lacks description). The description adds context for taskId ('de la tarea indicada') and explains the purpose of followUpTask beyond schema, including a concrete example. This compensates for the missing schema description.

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 description clearly states the tool stops active time tracking for a task ('Cierra el registro de tiempo activo'), specifies optional reason and follow-up task creation, and distinguishes from sibling 'start_task_timer'.

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?

The description gives clear context for use (stopping a timer) and mentions a specific scenario (waiting for a response) and access restriction (only assigned user or admin), but lacks explicit when-not-to-use or comparison with alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cizar/tasks-mcp-poc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server