Skip to main content
Glama

Create timer

timers_create

Create a bot timer that posts a message every N minutes, optionally only after enough chat activity or while the stream is live/offline.

Instructions

Create a bot timer that posts a message every N minutes, optionally only after enough chat activity.

Input Schema

NameRequiredDescriptionDefault
nameYesTimer name
onlineNoSchedule while the stream is live
channelNoStreamElements channel id (24-char hex). Defaults to SE_CHANNEL_ID or the channel that owns the token.
enabledNoWhether the timer is enabled
messageYesMessage the bot posts
offlineNoSchedule while the stream is offline
chatLinesNoMinimum chat lines since the last run before it fires again

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the mutation/safety profile is covered. The description adds useful behavior context — recurring posting cadence and the chat-activity gating condition — but omits things like duplicate-timer behavior, auth requirements, or what the created entity returns, so it is only moderately additive.

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?

A single front-loaded sentence that states the action and its two key behavioral qualifiers with zero waste. Nothing is padded or redundant.

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?

For a 7-parameter create tool with full schema coverage, nested objects, and informative annotations, the description covers purpose and core recurrence behavior adequately. The main shortfall is usage guidance and edge-case behavior, but the schema carries most of the field-level detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in the schema; baseline is therefore 3. The description echoes the interval and chat-activity concepts (mapping loosely to interval/chatLines and message) but adds no syntax or format detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Create a bot timer') and elaborates on what the timer does ('posts a message every N minutes', optionally gated on chat activity). It clearly distinguishes the create action from timers_list/get/update/delete via the verb, though it does not name those siblings explicitly.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives (e.g., timers_update for existing timers). The purpose implies a use case, but nothing tells the agent under what conditions this is the right tool versus its siblings.

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

Deploy Server

Other Tools