Skip to main content
Glama

Set timer alert

set_timer_alert
Destructive

Sets after how many hours a running timer sends the user a notification (and a push to their devices), once per timer: 0 turns it off; otherwise between 0.5 and 24 hours (the Time page offers 4, 8, 10 and 12). It only tells the user: the timer keeps running. Available on every plan.

Input Schema

NameRequiredDescriptionDefault
hoursYesHours before the alert; 0 = off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, and the description usefully narrows that: the alert 'only tells the user' and 'the timer keeps running', so the agent knows this does not stop or reset the timer — only overwrites the alert threshold. It also discloses frequency ('once per timer') and plan availability. It stops short of saying the previous alert value is replaced or what the response contains, but that is minor given annotations.

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?

Front-loads the core behavior, then constraints, then the caveat that it's notification-only. The parenthetical about the Time page presets is the only near-dispensable clause and is short enough to justify itself as value guidance.

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 single-parameter configuration tool with annotations present and no output schema, the description covers range, the off-switch, side effects (none on the timer), frequency, and plan availability. An agent has everything needed to call 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 100% and already says '0 = off', but the description adds the valid numeric range (0.5–24) and realistic presets (4, 8, 10, 12), which the schema does not state. That is genuine meaning beyond the schema, though it doesn't say what happens if an out-of-range value is passed.

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 (sets) and a precisely scoped resource (the notification threshold of a *running* timer), including the unit (hours). It is unmistakable against siblings like get_timer_alert (read) and add_reminder (separate reminder entity).

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 concrete usage rules: 0 disables the alert, otherwise 0.5–24 hours, and cites the values the Time page exposes. It does not explicitly name the read counterpart (get_timer_alert) or an alternative tool, so selection guidance is implied rather than spelled out.

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