A
licenseNot graded
qualityD
maintenanceA hosted remote MCP server that lets your AI agent schedule tasks for later — reminders, delayed webhook callbacks, and recurring jobs. Read-only by design.
0
MIT
CountLink
Server Details
Shared countdown timers that stay in sync on every screen — no account, any number of viewers.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- mrbrunocode/countlink
- GitHub Stars
- 0
TDQS
A4.7/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: creating agendas, creating badges, creating timers, and describing existing timer links. There is no overlap in functionality or ambiguity about when to use each tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (create_agenda, create_badge, create_timer, describe_timer_link). The verb changes appropriately based on action type, and the naming is predictable and clear.
Tool Count5/5
With 4 tools, the server is well-scoped for its purpose of creating and describing countdown/agenda links. Each tool earns its place, and the count is appropriate for the domain without being too sparse or bloated.
Completeness5/5
The tool surface covers the full lifecycle: creating timers, creating agendas, creating embeddable badges, and interpreting existing links. There are no obvious gaps, as the stateless nature of the service means no update/delete operations are needed.
Available Tools
4 toolscreate_agendaCreate a chained agenda of timed segmentsARead-onlyInspect
Create a CountLink agenda: an ordered sequence of named, timed segments (intro, talk, break, Q&A) that starts now and advances from one to the next on its own, on every screen that opens the link, with no server involved. Use this when someone describes a meeting, workshop, lesson or event as a sequence of parts with lengths — including when they give you a total and a list of topics and expect you to split it ("an hour, four topics"): do the split yourself, then pass the resulting segments here. By default it starts immediately; pass start_at for something scheduled ahead ("our workshop starts at 9:15 tomorrow") — the link works right away, showing a live countdown to the start rather than the first segment, and switches over on its own at the scheduled instant, in sync on every screen that opened it. Returns the shared link plus a run sheet with the wall-clock start and end of each segment, and an .ics calendar file (one event per segment) in structuredContent.ics — offer it if the person might want the agenda on their calendar. For a single countdown use create_timer instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| segments | Yes | The segments in running order. Each has a duration (same grammar as create_timer: "10m", "1h", "90s", "5:00", or a plain number of minutes) and an optional short label. 1–24 segments; the whole agenda must fit in 99h59m59s. | |
| start_at | No | Optional ISO-8601 instant for a scheduled start, e.g. "2026-09-08T09:15:00Z" or with a local offset like "2026-09-08T09:15:00+01:00". Omit to start immediately. A start_at already in the past is just treated as already running from that instant. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds rich behavioral context: automatic advancement, no server involvement, countdown-to-start behavior with start_at, sync across screens, and return artifacts (link, run sheet, .ics). No contradiction with annotations.
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?
The description is long but every sentence earns its place: it front-loads the purpose, then explains usage, start_at behavior, returns, and the alternative. No fluff or redundancy.
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?
Given the tool's complexity (chained segments, scheduling, splitting), the description covers purpose, usage, behavior, return artifacts, and alternatives. It is complete enough for an agent to call correctly without additional guidance.
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% with detailed descriptions for both segments and start_at, so the schema already documents the parameters. The description adds usage context (e.g., splitting example) but does not introduce new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.
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 description clearly states the tool creates a CountLink agenda: an ordered sequence of named, timed segments that advances automatically. It names the verb and resource, and explicitly differentiates from create_timer at the end, so an agent can distinguish it from siblings.
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?
It explicitly says 'Use this when someone describes a meeting, workshop, lesson or event as a sequence of parts with lengths' and gives a splitting example. It also states 'For a single countdown use create_timer instead,' providing a clear exclusion and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_badgeCreate a countdown badge for a README, forum post or similarARead-onlyInspect
Create a countdown badge — a small image, not an — for places embed_on_website's iframe cannot go: a GitHub README, a forum signature, a Notion page, anywhere only plain Markdown or a bare is allowed. Shows coarse time remaining (e.g. "3d 04h left", not a live ticking clock — most places that embed images fetch and cache them server-side, so a promise of live ticking would be false) and links through to the real, precise, live countdown. Returns both a Markdown snippet and an HTML snippet; use whichever the destination accepts. Always returns the image wrapped in a link to the live countdown — never ask for or produce just the bare image, since the link is what makes this a genuine attribution rather than an untethered picture.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional short name shown on the badge, e.g. "Launch" or "CFP closes". | |
| duration | Yes | How long the timer runs. Accepts "25m", "1h30m", "90s", "5:00", "1:30:00", or a plain number read as minutes ("45"). A setup link or OBS overlay holds up to 99h59m59s. With start_now or embed_on_website, longer countdowns of up to 366 days are fine: "10d", "10 days", "10d 6h" or "240h". | |
| badge_style | No | Visual style: "board" (default, dark), "minimal" (no background — blends into any page) or "light". |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true already indicating a non-destructive read operation, the description adds substantial behavior: output is a coarse time-remaining image, not live; it links through to the precise countdown; both Markdown and HTML snippets are returned; and the image is always wrapped in a link. This goes well beyond the annotations.
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?
Each sentence carries a distinct, necessary constraint or behavior: the use case, the coarse-time limitation, the returned snippet types, and the mandatory link wrapping. The description is dense but front-loaded and free of filler.
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?
With no output schema, the description still tells the agent what to expect in return: a Markdown snippet, an HTML snippet, and an image wrapped in a link. It also covers the major edge-case behavior around caching and the prohibition against returning a bare image, making the tool fully callable.
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?
The input schema already provides full 100% descriptions for duration, label, and badge_style. The tool description adds useful output context, such as the example '3d 04h left', but it does not meaningfully expand on the parameter meanings themselves, so the baseline of 3 applies.
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 description states a specific verb and resource: create a countdown badge, and clarifies it is a small image, not an iframe. It also distinguishes this tool from embed_on_website by naming the exact contexts where each is appropriate.
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 explicitly says when to use this tool versus embed_on_website: wherever only Markdown or a bare <img> is allowed, such as GitHub READMEs, forum signatures, and Notion pages. It also gives a meaningful exclusion by explaining that most image embeds are cached server-side, so a live ticking clock would be false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_timerCreate a shared countdown timerARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional name shown on the board, e.g. "Exam" or "Break". Keep it short. | |
| duration | Yes | How long the timer runs. Accepts "25m", "1h30m", "90s", "5:00", "1:30:00", or a plain number read as minutes ("45"). A setup link or OBS overlay holds up to 99h59m59s. With start_now or embed_on_website, longer countdowns of up to 366 days are fine: "10d", "10 days", "10d 6h" or "240h". | |
| start_now | No | False (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_style | No | Board style for embed_on_website: "board" (default, dark split-flap), "minimal" (plain digits) or "light". Ignored otherwise. | |
| embed_width | No | Pixel width of the embedded iframe when embed_on_website is true. 160–1600, default 400. Ignored otherwise. | |
| embed_height | No | Pixel height of the embedded iframe when embed_on_website is true. 80–900, default 160. Ignored otherwise. | |
| for_obs_overlay | No | True 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_website | No | True 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description fully discloses behavior beyond annotations: default setup link vs running link, same-second sync across viewers, fixed end instant, and when structuredContent.ics appears. No contradiction with readOnlyHint since the action is generating/returning links rather than mutating persistent state.
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 description is front-loaded and every block serves a purpose, but it is long and partially restates start_now semantics already in the schema. The use-case list and mode guidance are earned, so only minor redundancy keeps it from a 5.
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 an 8-parameter tool with no output schema, it explains the full decision tree: setup link vs start_now, OBS overlay vs website embed, and calendar-file behavior. An agent has enough context to select parameters and interpret the returned link without needing the output schema.
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% and the schema already documents every parameter, including duration formats, enums, and mutual exclusions. The tool description reinforces start_now's default behavior and the .ics tie-in but adds little semantics beyond the schema, so baseline 3 is appropriate.
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?
Opens with a specific verb and resource: 'Create a CountLink shared countdown timer and return its link,' which also distinguishes it from sibling create_agenda/create_badge and describe_timer_link. The shared-time behavior and no-sign-up note make the tool's function unmistakable.
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?
Gives explicit scenarios ('classroom, exam, standup, workshop...') and clear conditional rules: use the setup link by default, start_now only for immediate starts, don't give overlay URLs to multiple people, and use embed_on_website only for someone's own site. Also tells the agent when to offer structuredContent.ics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_timer_linkExplain a CountLink linkARead-onlyInspect
Given a countlink.app URL, say what it encodes: whether it is a running countdown or a not-yet-started setup link, its label, and how much time is left. Use it when someone pastes a CountLink link and asks what it is or when it ends.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A countlink.app timer URL. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool reads a URL and returns a classification, label, and remaining time, which goes beyond the readOnlyHint/destructiveHint annotations. It also frames the tool as a pure explainer, reinforcing that it has no side effects.
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?
Two tightly packed sentences: the first states the resource, inputs, and outputs; the second gives the exact usage trigger. No filler, no repetition of schema fields.
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 one-parameter, read-only inspection tool with no output schema, the description is complete: it tells the agent what input to expect, what the tool will produce, and when to invoke it. The annotations cover the safety profile, so no additional behavioral disclosure is required.
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%, and the url parameter is already described as 'A countlink.app timer URL.' The description restates the URL expectation but adds little new parameter-specific meaning beyond confirming the URL identifies a CountLink link.
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 description uses a specific verb 'say what it encodes' tied to a concrete resource, countlink.app URLs, and details the exact output: running countdown vs. not-yet-started setup, label, and time left. It clearly distinguishes itself from the create_* siblings by focusing on inspection rather than creation.
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?
It explicitly states when to use the tool: 'when someone pastes a CountLink link and asks what it is or when it ends.' This gives a clear trigger condition, though it does not name alternative tools for contrast or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
create_agenda1 field changed- changed
Input schema / properties / segments / items / properties / duration / descriptionPrevious value: -"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). Maximum 99h59m59s."New value: +"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). A setup link or OBS overlay holds up to 99h59m59s. With start_now or embed_on_website, longer countdowns of up to 366 days are fine: \"10d\", \"10 days\", \"10d 6h\" or \"240h\"."
- Changed
create_badge1 field changed- changed
Input schema / properties / duration / descriptionPrevious value: -"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). Maximum 99h59m59s."New value: +"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). A setup link or OBS overlay holds up to 99h59m59s. With start_now or embed_on_website, longer countdowns of up to 366 days are fine: \"10d\", \"10 days\", \"10d 6h\" or \"240h\"."
- Changed
create_timer1 field changed- changed
Input schema / properties / duration / descriptionPrevious value: -"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). Maximum 99h59m59s."New value: +"How long the timer runs. Accepts \"25m\", \"1h30m\", \"90s\", \"5:00\", \"1:30:00\", or a plain number read as minutes (\"45\"). A setup link or OBS overlay holds up to 99h59m59s. With start_now or embed_on_website, longer countdowns of up to 366 days are fine: \"10d\", \"10 days\", \"10d 6h\" or \"240h\"."
4 tool updates
- First observed
create_agenda - First observed
create_badge - First observed
create_timer - First observed
describe_timer_link
Related MCP Connectors
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.
Free no-signup group scheduling (a modern When2meet): share one link, find a time for everyone.
Timen time tracking — timers, time entries, reports, projects, and clients.
Related MCP Servers
- -licenseNot gradedqualityCmaintenanceEnables local time tracking for Jira cards/subtasks with a stopwatch, breaks, corrections, manual logging, and reports, storing data in a local JSON file without depending on the Jira API.-
- AlicenseNot gradedqualityBmaintenanceEnables local-first time tracking with timers and time entries stored in a SQLite database that sync to Intervals in the background, with local-only reporting and queries.21 npmMIT
- AlicenseNot gradedqualityBmaintenanceProvides Unix timestamp conversion, current UTC time, and relative time tools. Works offline without API keys.4 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.