Skip to main content
Glama

CountLink

by app.countlink

Create a shared countdown timer

create_timer
Read-only

Create a CountLink shared countdown timer and return its link. Everyone who opens the link sees the identical countdown, to the same second — no account, no sign-up, any number of viewers. Use this whenever someone wants a timer several people or several screens need to share: a classroom, an exam, a standup, a workshop, a webinar countdown, a stream overlay, or a countdown embedded on someone's own website or landing page (e.g. "10 days until launch"). By default it returns a setup link, which opens the board preloaded at the requested duration for the user to start themselves; pass start_now: true only if they want the countdown running from this moment. Whenever the result has a fixed end instant (start_now or embed_on_website), structuredContent.ics is an .ics calendar file for it — offer it if the person might want the deadline on their calendar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelNoOptional name shown on the board, e.g. "Exam" or "Break". Keep it short.
durationYesHow long the timer runs. Accepts "25m", "1h30m", "90s", "5:00", "1:30:00", or a plain number read as minutes ("45"). Maximum 99h59m59s.
start_nowNoFalse (default) returns a setup link the user starts themselves — correct for a timer that should begin later, and for anything being written down in advance. True returns a link for a countdown already running from now, fixed to one instant so every viewer is in sync; only use it when the timer should start immediately.
embed_styleNoBoard style for embed_on_website: "board" (default, dark split-flap), "minimal" (plain digits) or "light". Ignored otherwise.
embed_widthNoPixel width of the embedded iframe when embed_on_website is true. 160–1600, default 400. Ignored otherwise.
embed_heightNoPixel height of the embedded iframe when embed_on_website is true. 80–900, default 160. Ignored otherwise.
for_obs_overlayNoTrue returns a URL to paste into OBS (or any streaming tool) as a Browser Source: a transparent background with just the digits, which starts counting as soon as the scene loads. Use it when someone wants a countdown on their stream. Do not give an overlay URL to several people to open — it starts fresh for whoever loads it; for that, call this again without the flag and share that link instead. Mutually exclusive with embed_on_website.
embed_on_websiteNoTrue returns ready-to-paste <iframe> HTML for embedding a countdown on someone's OWN website or landing page — e.g. a launch-day countdown on a marketing page. Unlike for_obs_overlay, this is a fixed instant every visitor to that page sees identically (not a per-visitor restart), and free with no watermark option — the only requirement is a small attribution line under the widget linking back to CountLink, which the returned HTML already includes. Use this whenever someone asks for a countdown to put ON their own site/page, as opposed to a link to share with other people directly. Mutually exclusive with for_obs_overlay.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations provide only a minimal safety profile (readOnlyHint=true, destructiveHint=false), so the description carries the behavioral burden and exceeds it: no acccount/no sign-up, every viewer sees the identical countdown to the same second, setup-link-vs-running-link semantics, and the conditional .ics disclosure with an offer hint. It also surfaces two non-obvious gotchas — the OBS overlay starts fresh for whoever loads it, and embeds require an attribution line — which no annotation or schema could convey. The readOnlyHint sits awkwardly beside 'Create,' but the description never misrepresents side effects: this is non-destructive link generation, not mutation of existing data, so no contridiction is flagged.

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?

The core sentence is front-loaded ('Create a CountLink shared countdown timer and return its link'), followed by scope, then mode-by-mode guidance. The enumerate of settings (classroom, exam, standup, workshop, webinar, stream, landing page) is slightly redundant but fnctional for an agent judging applicability. At roughly 200 words for an 8-parameter, 4-mode tool, the length is earned rather than padded.

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 high-complexity tool with 8 parameters, four output modes, and no output schema, the description covers the setup-link default, start_now behavior, embed_on_website, for_obs_overlay, and the conditional .ics offer, including mutual exclusions. The only real gap is the exact return shape beyond 'its link' and structuredContent.ics — with no output schema, a fuller return description would help — but the sibling describe_timer_link covers downstream inspection, and the description is otherwise complete.

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%, so the baseline is 3; the description adds real meaning on top by tying parameters to outcomes — start_now: true yields a 'fixed end instant' that triggers the .ics offer, and embed_on_website gains its attribution requirement while for_obs_overlay gains its per-loader-restart warning. It does not restate the schema's format docs (duration syntax, pixel ranges), which are already thorough, so the extra value is conditional context rather than repetition.

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 opening sentence states a specific verb and resource: 'Create a CountLink shared countdown timer and return its link,' which immediately sets the deliverable (a shareable link). The sibling names (create_agenda, create_badge, describe_timer_link) are clearly different resources or a read operation, so the tool is easily distingushed without opening schemas. The rest of the description reinforces the core 'shared countdown' semantics that are the tool's reason for existing.

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

Usage Guidelines5/5

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

The description opens with an explicit when-to-use directive: 'Use this whenever someone wants a timer several people or several screens need to share,' backed by concrete settings (classroom, exam, standup, webinar, stream overlay, web embed). It also routes between internal variants — setup link vs start_now: true, embed_on_website vs for_obs_overlay — with explicit exclusions such as 'Do not give an overlay URL to several people to open' and the mutual-exclusivity note. This is guidance an agent can act on without inference.

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

All CountLink toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct artifact: agendas, timer links, badge images, and link inspection. The descriptions include explicit cross-references (e.g. "For a single countdown use create_timer instead"), so an agent can reliably pick the right tool.

Naming Consistency5/5

All tool names follow the same snake_case verb_noun pattern: create_agenda, create_badge, create_timer, and describe_timer_link. There are no mixed casing styles or inconsistent verb conventions.

Tool Count5/5

Four tools is a well-scoped set for this server: one creation tool per core artifact type plus a link inspector. Each tool has a clear purpose and none feel redundant.

Completeness4/5

The core workflows—creating shared countdowns, agendas, and badges, and inspecting CountLink URLs—are covered. Minor gaps exist: there is no explicit iframe-embed tool even though create_badge references embed_on_website's iframe, and describe_timer_link doesn't mention agenda links, but agents can often work around these with the returned links and snippets.

Resources