Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@timermcp start a 25-minute pomodoro"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A millisecond-precision MCP timer server. Say "start the timer" to Claude โ the clock starts on the server's monotonic nanosecond clock, a live wall display lights up in your browser, and when you say "stop," Claude announces the official time like a track announcer.
๐ STOP THE CLOCK! 'ship the landing page' finishes in 4:07.312!
๐ NEW PERSONAL BEST โ 18.455 faster than the old record!With the free cloud connector (timermcp.com), countdowns render as a live ticking card right in the chat โ desktop and mobile:
You say "start" at tโ; the command reaches the server after delay dโ (typing + model + transport). Server stamps Sโ = tโ + dโ. You say "stop" at tโ, stamped Sโ = tโ + dโ.
reported = Sโ โ Sโ = (tโ โ tโ) + (dโ โ dโ)Both timestamps are taken server-side, so the constant part of the pipeline delay cancels. Only the difference between start-side and stop-side latency can leak in โ and for symmetric calls that's small. All math runs on process.hrtime.bigint() (monotonic nanoseconds), immune to NTP jumps and DST.
If you believe your pipeline is asymmetric, bias it out: timer_config accepts start_offset_ms / stop_offset_ms, subtracted from every result. raw_elapsed_ms (pure monotonic) is always returned alongside the adjusted elapsed_ms.
Related MCP server: productive-mcp
Prerequisite: Node.js โฅ 18 (node --version).
TimerMCP is on npm โ no clone or build needed.
Claude Code (one command):
claude mcp add timermcp -- npx -y timermcp
claude mcp list # should show timermcp โ connectedClaude Desktop โ edit claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"timermcp": {
"command": "npx",
"args": ["-y", "timermcp"]
}
}
}git clone https://github.com/julanbasnet/timermcp.git
cd timermcp
npm install && npm run build
node dist/index.js --version # prints banner and exits
npm run smoke # full 18-assertion suite
claude mcp add timermcp -- node /absolute/path/to/timermcp/dist/index.jsOn Windows use forward slashes or escaped backslashes in config paths: "C:/tools/timermcp/dist/index.js".
After adding, fully quit and reopen the client (Desktop: quit from the menu/tray, not just close the window). Say "start the timer" and open http://localhost:5717 โ the wall display.
Inspector (optional): npx @modelcontextprotocol/inspector npx -y timermcp for an interactive tool console.
You say | Tool | What happens |
"start the timer" |
| Monotonic start stamp + announcer call |
"start a 25-minute pomodoro" |
| Countdown mode; stop reports over/under |
"race me vs the build: start alice and bob" |
| Both start on the same nanosecond |
"split โ hero section done" |
| LiveSplit-style lap, delta vs PB pace ๐ข๐ด |
"how long so far?" |
| Live server-side reading |
"stop the clock" |
| Official ms, PB check, SVG result card |
"false start, cancel it" |
| Discards without touching history |
"what's my record?" |
| PBs, recent runs, lifetime totals |
"switch announcer to drill sergeant" |
| hype ยท zen ยท sergeant ยท sports ยท minimal |
Live wall display โ electric-cyan timing console at localhost:5717, streams every millisecond over SSE. Put it on a second monitor or your phone; it reacts the instant Claude acts. Buttons + keyboard (space = split, enter = start/stop) work from the browser too, including a countdown-target field for browser-started pomodoros.
Countdown chime โ flip the ๐ Sound toggle on the wall and every countdown rings out loud the moment it hits zero. (Off by default; browsers require one click before a page may play audio.)
XP, levels & achievements โ every finished run and tracked minute earns XP. Ten ranks from ROOKIE to TIME LORD, a day-streak counter, and a 12-medal achievement shelf (PHOTO FINISH, RECORD BREAKER, BULLSEYE, MIDNIGHT OIL, RACE DAYโฆ), all derived from your local history. Level-ups and unlocks fire toasts + confetti on the wall.
Personal bests & speedrun splits โ every named timer keeps a PB. Splits compare against the same checkpoint on your PB run, LiveSplit-style: "1.204 AHEAD of PB pace ๐ข". Confetti on new records.
Race mode โ comma-separated names start on one shared nanosecond stamp (measured ฮ in tests: 0.003ms).
Result cards โ every stop writes a 1200ร630 SVG finish card (~/.timermcp/cards/, also served at /card/{id}). Screenshot-ready for X/LinkedIn.
Announcer personalities โ hype race-caller by default; zen, drill sergeant, broadcast, or minimal.
Crash-safe โ state persists to ~/.timermcp/state.json; timers running across a restart recover on wall-clock precision (flagged as recovered).
Var | Default | |
|
| Dashboard port |
|
| Set |
|
| State + cards directory |
| unset |
|
Tools don't appear in Claude โ the config path must be absolute; fully quit and relaunch the client. Server logs (stderr) land in the client's MCP logs โ macOS: ~/Library/Logs/Claude/mcp-server-timermcp.log, Windows: %APPDATA%\Claude\logs\.
Dashboard won't load / "port taken" in logs โ another TimerMCP instance owns 5717. Claude Desktop and Claude Code each spawn their own server process; timers still work in both, but give the second one TIMERMCP_PORT=5718 (and its own TIMERMCP_HOME if you want separate PBs โ otherwise state.json is last-write-wins between them).
node dist/index.js seems to hang โ normal; stdio servers wait for a client. Use --version to sanity-check.
Times look ~equal but off by a constant โ that's differential latency; set start_offset_ms / stop_offset_ms via timer_config (see latency math above).
npm run smoke # 19 assertions: protocol, timing accuracy, offsets, race ฮ, dashboard, cardsMIT.
Discard a running timer WITHOUT recording a session, PB, or history entry. Use for false starts ("wait, I wasn't ready"). The would-be elapsed is returned for reference only.
Args:
name (string, default "main"): Timer to discard.
Returns: { name, discarded_elapsed_ms }
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Timer to discard | main |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| discarded_elapsed_ms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, which aligns with discarding. The description adds valuable context: 'without recording a session, PB, or history entry' and 'the would-be elapsed is returned for reference only,' going beyond what annotations provide.
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 is concise, with two sentences plus structured Args/Returns sections. Key information is front-loaded and every sentence adds value.
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?
For a simple tool with 1 parameter and complete annotations, the description fully covers purpose, usage, behavior, and output. Nothing 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 coverage is 100%, so baseline is 3. The description merely repeats the parameter's purpose ('Timer to discard') and default value ('main'), without adding new meaning 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 clearly states 'Discard a running timer WITHOUT recording a session, PB, or history entry,' using a specific verb and resource. It distinguishes this tool from siblings like timer_stop and timer_start by indicating it discards rather than stops/records.
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 explicitly says 'Use for false starts' and implies this tool is not for intentional stopping. This provides clear guidance on when to use this tool vs. alternatives like timer_stop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read or update TimerMCP settings. Call with no args to read.
Settings:
announcer ('hype'|'zen'|'sergeant'|'sports'|'minimal'): Default announcement personality. Styles: hype, zen, sergeant, sports, minimal.
start_offset_ms / stop_offset_ms (number โฅ 0): Latency handicaps subtracted from every elapsed. Leave at 0 for most uses โ symmetric pipeline latency already cancels because both timestamps are taken server-side on a monotonic clock. Set these only to bias out a known asymmetry (e.g. user reckons their "stop" reaches the server ~300ms slower than their "start").
max_hours (number): A running timer older than this is flagged runaway (default 4).
sync_token (string): Enables cloud auto-sync. The user gets this token from their dashboard at https://timermcp.vercel.app/app ("set my timer sync token to โฆ"). Every finished run then syncs automatically. Pass an empty string to disable sync.
sync_url (string): Override the cloud endpoint (default https://timermcp.vercel.app).
Returns: { config: {announcer, start_offset_ms, stop_offset_ms, max_hours, sync_enabled, sync_token_tail?, sync_url?}, dashboard_url, data_dir }
| Name | Required | Description | Default |
|---|---|---|---|
| sync_url | No | Cloud sync endpoint override | |
| announcer | No | Default announcement personality | |
| max_hours | No | Hours before a running timer is flagged runaway | |
| sync_token | No | Cloud sync token from the TimerMCP dashboard; empty string disables sync | |
| stop_offset_ms | No | Default stop-side handicap in ms | |
| start_offset_ms | No | Default start-side handicap in ms |
| Name | Required | Description |
|---|---|---|
| config | Yes | |
| data_dir | Yes | |
| dashboard_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. Description adds detailed behavior: sync token enables sync, max_hours flags runaways, pipeline latency cancellation explained. No hidden effects mentioned.
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?
Well-structured with bullet points, front-loaded purpose. Slightly lengthy but every sentence adds value; no unnecessary repetition.
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?
Complete coverage of all 6 parameters with examples and defaults. Output schema described. No gaps given the tool's complexity.
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 100%, but descriptions add extensive context beyond schema: e.g., why leave offsets at 0, how to get sync token, default values. Adds significant meaning.
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 clearly states the tool's purpose: 'Read or update TimerMCP settings.' It distinguishes from sibling timing tools by focusing on configuration, not timer operations.
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?
Explicit guidance to 'Call with no args to read.' Explains when to use each parameter (e.g., leave offsets at 0). No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Personal bests, recent finished runs, and lifetime totals. Read-only.
Args:
name (string, optional): Filter to one timer name; omit for everything.
limit (number, default 10): Max recent sessions returned (1โ50).
Returns: { bests: [{name, best_ms?, count, total_ms}], recent: [{id, name, elapsed_ms, formatted, pb, splits, stopped_wall, target_ms?, over_under_ms?}], lifetime_ms, lifetime_sessions }
Great for "what's my record?", "how much have I tracked today?", or building a leaderboard recap for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter to one timer name | |
| limit | No | Max recent sessions |
| Name | Required | Description |
|---|---|---|
| bests | Yes | |
| recent | Yes | |
| lifetime_ms | Yes | |
| lifetime_sessions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotent and read-only. Description adds return structure and states read-only explicitly. No contradictions.
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?
Single sentence then structured args and return type. No fluff. Usage examples at end. Perfectly 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 full annotations, output schema, and clear parameter docs, description closes all gaps. Complete for a history query tool.
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 covers parameters fully (100%). Description adds usage context: omit name for everything, limit range. Baseline 3, adds value.
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?
Clearly states it returns personal bests, recent runs, and lifetime totals. Directly distinguishes from timer_start/timer_stop by focusing on history.
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?
Provides concrete use cases (record, daily totals, leaderboard) and explains parameter usage. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a split (lap) on a running timer without stopping it โ speedrun style.
If a personal-best run exists for this timer name, the split is compared against the SAME split index on the PB run and delta_vs_best_ms is returned (negative = ahead of PB pace, like LiveSplit green).
Args:
name (string, default "main"): Running timer to split.
label (string, optional): Name the checkpoint, e.g. "deploy done", "lap 2". Defaults to "Split N".
Returns: { name, index, label, at_ms, formatted, delta_vs_best_ms?, announcement }
Relay the announcement; if delta_vs_best_ms is present, call out ahead/behind PB pace.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Running timer to split | main |
| label | No | Checkpoint label |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| at_ms | Yes | |
| index | Yes | |
| label | Yes | |
| formatted | Yes | |
| announcement | Yes | |
| delta_vs_best_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description adds necessary behavioral details: the tool does not stop the timer, compares against PB runs, and returns delta. The announcement relay instruction is also helpful. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two paragraphs), front-loaded with the main purpose, and well-structured with parameter details and return value explanation. Every sentence adds value.
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 (2 parameters, no nested objects) and presence of output schema, the description covers all necessary context: purpose, parameters, return structure, and how to interpret results.
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 100%, but the description adds value beyond the schema by explaining default for 'name' and the default label format 'Split N'. It also clarifies the optional nature of 'label'.
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 uses a specific verb ('Record') and resource ('split/lap on a running timer') and explicitly distinguishes from siblings like 'timer_stop' by noting it doesn't stop the timer. The 'speedrun style' analogy further clarifies the use case.
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 a running timer exists and a checkpoint is needed, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though the sibling list provides context. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a millisecond-precision stopwatch (or countdown) on the TimerMCP server.
The server stamps the start on a MONOTONIC nanosecond clock the instant this call arrives. Elapsed time is computed server-side as stop-stamp minus start-stamp, so the constant part of the pipeline delay (user โ Claude โ server) cancels out between start and stop โ only the difference in latency between the two calls can leak in.
Args:
name (string, default "main"): Timer name. NAME IT AFTER THE TASK โ when the user says what they are working on ("start a timer for the auth refactor"), use that as the name ("auth refactor") so their session log reads like a work journal. Pass a comma-separated list (e.g. "alice,bob") to start several timers on the SAME nanosecond โ race mode.
target_ms (number, optional): Turns the run into a countdown (Pomodoro, rest interval, speedrun target). Stop reports over/under.
announcer ('hype'|'zen'|'sergeant'|'sports'|'minimal', optional): Voice for this run's announcements. Defaults to configured style.
start_offset_ms (number, optional): Milliseconds subtracted from the final elapsed to bias out start-side latency. Defaults to configured value (0).
Returns: { started: [{name, elapsed_ms, started_wall, target_ms?}], announcement, dashboard_url }
IMPORTANT: Relay the 'announcement' line to the user with matching energy โ you are the track announcer. Mention the dashboard_url the first time so they can put the live wall display on a second screen.
Errors: fails if a timer with the same name is already running (stop or cancel it first, or pick another name).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Timer name; comma-separate for a simultaneous race start, e.g. "me,rival" | main |
| announcer | No | Announcement personality for this run | |
| target_ms | No | Optional countdown target in ms (e.g. 1500000 for a 25-min Pomodoro) | |
| start_offset_ms | No | Latency handicap subtracted from the final time (start side) |
| Name | Required | Description |
|---|---|---|
| started | Yes | |
| announcement | Yes | |
| dashboard_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations leave room; description adds monotonic clock, latency cancellation, error handling, return format, and announcement instructions. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs and bullet-like sections, front-loaded with purpose. Slightly long but every sentence adds value; no obvious redundancy.
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 4 params, annotations, output schema, and sibling tools, description is highly complete: covers return, errors, naming, usage tips, and behavioral details.
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 100%, but description adds naming guidelines, race mode, countdown purpose, voice personality, and latency handicap meaning, far exceeding baseline.
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 clearly states it starts a millisecond-precision stopwatch or countdown on the TimerMCP server, distinguishing it from siblings like timer_cancel, timer_stop, etc. The verb 'start' is specific to the resource 'timer'.
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?
Provides explicit context on when to use (start a timer) and includes an error condition about duplicate names. No direct when-not or alternatives, but sibling names imply usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check what's on the clock right now. Read-only.
Args:
name (string, optional): One timer, or omit for all running timers.
Returns: { running: [{name, elapsed_ms, formatted, target_ms?, remaining_ms?, splits, best_ms?, recovered, runaway}], count, dashboard_url } 'recovered' = true means the server restarted mid-run and that timer fell back to wall-clock precision. 'runaway' = true means the timer has been running longer than the configured max_hours (default 4) โ the user probably forgot it. Ask if they want to stop it, offering trim_to_ms to cap the recorded time at what they actually worked. elapsed_ms is a live server-side reading at the moment this call was processed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Specific timer, or omit for all |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| running | Yes | |
| dashboard_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (read-only, idempotent), the description explains return fields in detail, including edge cases like 'recovered' (server restart) and 'runaway' (forgotten timer), and notes that elapsed_ms is live. This adds significant behavioral context.
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 is concise and well-structured: a one-sentence summary, clear Args and Returns sections, and every detail earns its place. No redundancy or fluff.
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 (one optional param) and the inline output schema covering all return fields, the description is fully complete. Edge cases and field semantics are explained, leaving no gaps.
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 100% with a basic description. The description adds 'running timers' context to the parameter, clarifying that only active timers are shown, and reiterates the optional nature. This adds meaningful nuance 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 clearly states 'Check what's on the clock right now' with 'Read-only', using a specific verb and resource. It distinguishes from sibling timers (start, stop, cancel, etc.) by focusing on current status.
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 implicitly guides usage by stating it checks currently running timers and allows optional name filter. It lacks explicit when-not-to-use or alternative comparisons, but the context is clear for a simple status check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running timer and get the official elapsed time in milliseconds.
elapsed_ms = (monotonic stop-stamp โ monotonic start-stamp) โ start_offset_ms โ stop_offset_ms. raw_elapsed_ms is the pure unadjusted monotonic difference. Because both stamps are taken server-side, symmetric pipeline latency cancels; offsets exist only to bias out asymmetry if the user wants.
Args:
name (string, default "main"): Which timer to stop.
stop_offset_ms (number, optional): Override the configured stop-side latency handicap for this stop only.
trim_to_ms (number, optional): Cap the recorded time. Use when the user forgot to stop a runaway timer and tells you how long they actually worked (e.g. "I only worked 25 minutes" โ trim_to_ms 1500000). The session records the capped time and is flagged trimmed.
Returns: { session: {name, elapsed_ms, raw_elapsed_ms, formatted, splits, pb, pb_margin_ms?, target_ms?, over_under_ms?, id}, announcement, card_path, card_url }
A shareable SVG result card is written on every stop (card_path on disk, card_url served by the dashboard).
IMPORTANT: Relay the 'announcement' to the user โ big finish energy if it's a PB. Quote the exact millisecond figure.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Timer to stop | main |
| trim_to_ms | No | Cap the recorded time at this many ms (runaway-timer rescue) | |
| stop_offset_ms | No | Latency handicap subtracted from the final time (stop side) |
| Name | Required | Description |
|---|---|---|
| session | Yes | |
| card_url | Yes | |
| card_path | Yes | |
| announcement | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation, and the description transparently explains the elapsed time calculation, that a card is written to disk, and the return structure. No contradictions.
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?
Well-structured with bullet points and emphasis on important notes. Slightly verbose but front-loads the core action. Every sentence is informative.
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?
Covers purpose, usage, parameters, side effects, and return values. With output schema present, the description is complete enough for an agent to use correctly.
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 covers all parameters, but the description adds value by explaining trim_to_ms as a runaway timer rescue and stop_offset_ms as a latency handicap, which is 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 clearly states it stops a running timer and returns elapsed time. It distinguishes from sibling tools like timer_cancel (which cancels without recording) and timer_start.
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?
Provides clear context on when to use the tool and includes important notes like relaying the announcement and using trim_to_ms for runaway timers. Does not explicitly state when not to use, but the context is sufficient.
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.
v1.2.0timer_canceltimer_configtimer_historytimer_splittimer_starttimer_statustimer_stopScored across 7 tools
Each tool has a clear, distinct purpose: start, stop, cancel, split, status, history, and config. There is no functional overlap, and the descriptions explicitly differentiate them.
All tools follow a consistent 'timer_verb' pattern in lowercase snake_case, making the naming predictable and easy to understand.
Seven tools cover the essential timer operations without being excessive. Each tool adds unique value, and the count feels well-scoped for the domain.
The tool set covers the full lifecycle of timer operations: start, stop, cancel, split, live status, history, and configuration. Minor gaps like deleting history or editing sessions are absent but not critical for the core use case.
Privacy-first time tracking for freelancers. EU-hosted, with an MCP server for AI assistants.
MCP server for Speech-to-Text
Nifty's MCP server โ exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
