Skip to main content
Glama

Stop timer

stop_timer
Destructive

Ends the active timer and every running session, saves an optional summary and outcome, and returns the break length; resuming starts a new session.

Instructions

Stop the timer ("pause", "stop", "stand up") and every running session with it. There is no paused state: resuming starts a new session. Pass summary and outcome to save them on the sessions it closes, or call stop_session first. Returns the break length.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outcomeNodefault partial
summaryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing real side effects: there is no paused state, resuming creates a brand-new session, and all running sessions are closed by this call. That concretely explains the destructive/irreversible semantics the annotations only flag abstractly.

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 dense sentences, front-loaded with the core action and scope, then the state-model caveat, then the parameter/alternative guidance. No filler and nothing repeated from the schema or annotations.

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?

No output schema exists, yet the description states the return value (break length). Combined with the disclosed side effects, the alternative tool, and parameter persistence semantics, an agent has everything needed to invoke it correctly.

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 only 50% (summary is undocumented in the schema), and the description compensates by explaining that summary and outcome are persisted onto the sessions being closed. It also confirms the enum's default of partial indirectly via the schema, adding genuine meaning for the undocumented parameter.

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?

States a specific verb and resource (stop the timer) plus its scope: it also stops 'every running session with it'. It explicitly names the sibling stop_session, so an agent can distinguish the two without opening either schema.

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 a clear routing rule: pass summary/outcome here to save them on the closed sessions, or call stop_session first instead. That names the alternative and the condition that selects it, though it does not spell out the general when-not-to-use case (e.g. behavior when no timer is running).

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