Shareable timer links for countdowns, clock times, Pomodoro, Tabata and step recipes. No account.
Scored across 7 tools
Each tool targets a distinct resource and action: create_clock_link (next clock time), create_timer (duration), create_recipe (multi-step recipe), with explicit guidance distinguishing get_preset vs list_presets and get_capabilities vs get_integrations. Descriptions proactively cross-reference siblings to steer correct selection.
All seven tools follow a strict verb_noun snake_case pattern (create_clock_link, create_recipe, create_timer, get_capabilities, get_integrations, get_preset, list_presets). No mixed conventions or vague verbs.
Seven tools is well-scoped for a link-generation service, covering creation, discovery, and reference without redundancy. Every tool earns its place with a clear role.
The surface covers creation (timer, clock link, recipe), discovery (list/get presets), and reference (capabilities, integrations). The only conceivable gap is preset creation/modification, though built-in presets may be intentionally out of scope.
Return a validated link to the next local clock time, e.g. 9pm or 17:30. Each opener uses their own timezone. This does not schedule a server timer.
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | ||
| label | No |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| time | Yes | |
| timezone | Yes | |
| alarm_note | Yes | |
| start_behavior | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), but the description adds genuinely useful context that the annotations cannot: that links resolve in each opener's own timezone and that no server-side timer is created. That resolves the main confusion the 'create_' name would otherwise cause.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, correctly front-loaded with the core behavior, followed by the timezone nuance and the negative constraint. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format explanation is unnecessary, and the low-complexity, two-parameter surface is nearly fully described. The only gap is the undocumented 'label' parameter, which is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load. It compensates for 'time' with format examples ('9pm or 17:30'), which is real value, but the optional 'label' parameter is never explained in either the schema or the description, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (a validated link to the next local clock time) with concrete examples of the accepted value, and implicitly carves out the sibling create_timer with 'does not schedule a server timer.' It never names the alternative explicitly and the verb 'return a validated link' leaves slight ambiguity about whether anything is persisted, so it falls short of the top tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the tool applies (per-opener timezone, clock-time links rather than server timers) and effectively excludes the create_timer use case. No siblings are named and no prerequisites or exclusions beyond the timer contrast are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a data-only recipe and return its portable preview link. The person opens it and presses Start. No code runs and no webhook is armed.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | Yes | Recipe v1: 1–12 whole-second steps, no repeats. v2: 1–32 steps, fractional seconds and repeats. At most 512 expanded intervals and 10 years; defaults may be omitted. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| recipe | Yes | |
| intervals | Yes | |
| start_behavior | Yes | |
| duration_seconds | Yes | |
| integration_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by clarifying that the output is a shareable link the user must activate manually and that no code executes and no webhook is armed — a non-obvious trait given the schema's completion.webhook flag. It does not disclose validation-failure behavior or link persistence/lifetime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loading the action and return value, then the user flow, then the negative constraint. Zero filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return details need not be explained, and the description covers validation and the no-code/no-webhook constraint for a single-object parameter. Minor gaps remain around what a validation failure returns, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the nested recipe schema is extensively self-documenting (version rules, step/intervals limits, theme colors), so the schema carries the parameter burden. The description adds only the 'data-only recipe' framing and nothing about step or version semantics, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific action (validate a recipe and return its portable preview link) on a specific resource, and the phrase 'data-only recipe' plus 'preview link' distinguishes it from the timer/clock-link siblings. It stops short of explicitly naming an alternative, so sibling differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the intended flow ('The person opens it and presses Start') and implicitly rules out webhook/automation use ('no webhook is armed'), which is useful context. However, there is no explicit when-to-use vs. when-not guidance nor any reference to the sibling tools an agent might pick instead, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a duration and return a link. The countdown starts when the person opens it, not when this tool runs. No background alarm or automation is scheduled.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Omit unless requested. | |
| muted | No | Omit to use defaults. | |
| theme | No | Omit to use defaults. | |
| display | No | Omit to use defaults. | |
| duration | Yes | Relative duration, e.g. 12m or 1h20m. Bare numbers mean minutes. Use recipes for sequences. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| alarm_note | Yes | |
| start_behavior | Yes | |
| duration_seconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/ non-destructive / idempotent, so the safety profile is covered. The description adds genuinely new behavioral facts the schema cannot express: the countdown starts on link open rather than at tool execution, and no background alarm or automation is scheduled. It does not cover link expiry or response shape, but the added scheduling semantics are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler, and the key non-obvious fact (countdown starts on open, not on execution) is stated early. The opening 'Validate a duration and return a link' is slightly misleading as a lead, costing a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and annotations cover safety. However, nothing addresses selection against the six sibling tools or lifecycle details such as whether the generated link expires, leaving a real gap for a tool whose whole output is a link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including duration format examples and enum values, so the structured fields already carry the parameter meaning. The description only adds 'validate a duration,' which implies invalid formats are rejected but adds no syntax or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description frames the tool as 'Validate a duration and return a link,' which describes an implementation step rather than the user-facing outcome (creating a shareable countdown timer). The resource is implied only via the name and title, and nothing distinguishes it from the sibling create_clock_link, which an agent must choose between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to pick this over create_clock_link (target time vs. relative duration) or create_recipe (sequences), even though the duration description hints that 'recipes' exist for sequences. The agent is left to infer selection from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a short feature and limits summary. Request detail=full only for the complete reference. Does not start a timer.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| limits | Yes | |
| families | Yes | |
| decision_rules | Yes | |
| canonical_origin | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the negative clarification 'Does not start a timer,' which is useful context. It does not describe the return content beyond 'short feature and limits summary,' but with annotations and an output schema, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and immediately followed by the key parameter guidance and a negative clarification. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description covers purpose, the detail parameter usage, and a key behavioral boundary. Minor gap: it doesn't explicitly differentiate from sibling info tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It mentions the 'detail=full' value and identifies summary as the default, which adds some meaning over the enum in the schema. However, it doesn't explain what 'full' contains versus 'summary' beyond 'complete reference.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get a short feature and limits summary') and clarifies what it is not ('Does not start a timer'). It is distinguishable from siblings like get_integrations and get_preset, but the description doesn't explicitly position itself against those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the default is summary and that detail=full should only be used for the complete reference. This gives some usage context, but there is no explicit when-to-use vs alternatives among siblings like get_integrations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain optional Zapier completion hooks, setup, authorization, and browser-lifetime limitations. Does not connect or send anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| setup | Yes | |
| events | Yes | |
| provider | Yes | |
| setup_url | Yes | |
| limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering read-only, idempotent, and non-destructive behavior, the description adds useful context beyond structured fields: it discloses 'browser-lifetime limitations' and reinforces that the tool does not connect or send anything. This extra behavioral detail is helpful, though it remains brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two tightly worded sentences with no wasted words. The core purpose is front-loaded, and the clarifying boundary follows immediately. It is appropriately sized for an informational tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and comprehensive annotations, the description is nearly complete. It explains what is covered and includes a key limitation. The only minor gap is the lack of explicit routing guidance relative to sibling tools like get_capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4, as the description cannot add value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: explaining optional Zapier completion hooks, setup, authorization, and browser-lifetime limitations. It clearly identifies the resource (Zapier integration for timer completions) and distinguishes itself from action-oriented siblings by noting it does not connect or send anything. However, it does not explicitly differentiate itself from get_capabilities or other informational siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs information about Zapier completion hooks, and it provides a negative boundary with 'Does not connect or send anything.' It does not, however, state when to use this tool versus alternatives like get_capabilities or get_preset, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one preset with its full validated recipe. Use list_presets for quick recommendations; request details only to inspect or customize steps.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| preset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the notion that the returned recipe is 'full' and 'validated' (implying no further validation by the caller); it says nothing about lookup failure behavior or payload size. Adequate but thin given the low bar set by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the core action front-loaded and the sibling routing second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the enum-constrained id plus annotations cover the safety story. The description is nearly complete, though it is silent on what happens for an id that currently has no preset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the 'id' parameter. The seven enum values (egg, pomodoro, tabata, stopwatch, etc.) are largely self-documenting, and 'one preset' implies the id selects the preset, so the gap is partially mitigated, but the description contributes nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one preset') plus the payload it returns ('its full validated recipe'). It explicitly contrasts itself with list_presets, so an agent can distinguish the two without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance: use list_presets for quick recommendations, use this tool only to inspect or customize steps. The alternative and the condition that selects it are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List preset names, schedules and links without recipe bodies. Use get_preset(id) only when full steps or customization are needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| details | Yes | |
| presets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real value by disclosing that output omits recipe bodies, which prevents an agent from expecting full definitions from this call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste: the first states the deliverable and its boundary, the second routes to the detail tool. Front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and annotations cover safety. The description supplies the one missing piece — the list/detail split — though it says nothing about result ordering or size limits, a minor gap for a no-param lister.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description adds nothing parameter-related, which is appropriate since there is nothing to document beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) plus resource (presets), and it enumerates the returned fields (names, schedules, links) while explicitly excluding recipe bodies. This scope statement cleanly separates it from the sibling get_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternative explicitly — get_preset(id) — and states the condition that selects it: only when full steps or customization are needed. Nothing about the list-vs-detail choice is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_clock_linkcreate_recipecreate_timerget_capabilitiesget_integrationsget_presetlist_presetsShared countdown timers that stay in sync on every screen — no account, any number of viewers.
Real-time multi-track schedules for cooking, lab protocols, events and workouts. Validate and share.
Meeting agenda timer for AI assistants: build agendas in chat, share a live synced countdown.
Timen time tracking — timers, time entries, reports, projects, and clients.
Add one secure layer between your agents and this server.
