Atimelogger MCP

ATimeLogger MCP Server

A standalone MCP (Model Context Protocol) server that exposes the ATimeLogger REST API to AI assistants — locally over stdio (Claude Desktop / Claude Code / OpenAI Codex) or remotely as a connector (claude.ai in the browser, Claude mobile apps, ChatGPT). Scope: activities (start/stop/pause/log), reports/history, and activity types.

The same package also installs [`atimelogger-cli`](#command-line-interface) — a read-only JSON CLI that needs no AI assistant at all. Use it from cron jobs, status bars, and shell pipelines; it shares the server's internals (fuzzy type names, period words, DST-correct timezones) but runs entirely on its own. A library entry point covers the third case, calling ATimeLogger in-process from your own code.

Setup

Requires Node 20+.

1. Generate a Personal Access Token in the ATimeLogger web app: Settings → API Tokens → Generate token. The value (starting with atl_pat_) is shown only once — copy it right away. You can revoke the token from the same page at any time.

1. Register the server. No install or build step needed — npx fetches the published package on first run:

Claude Code — a one-liner:

claude mcp add atimelogger \

-e ATL_TOKEN=atl_pat_... \ -- npx -y atimelogger-mcp

Claude Desktop — a JSON block to merge into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), then restart Claude Desktop:

{

"mcpServers": { "atimelogger": { "command": "npx", "args": ["-y", "atimelogger-mcp"], "env": { "ATL_TOKEN": "atl_pat_..." } } } }

OpenAI Codex (CLI, IDE extension, or the ChatGPT desktop app's Codex mode) — also a one-liner; the configuration is shared by all three Codex surfaces:

codex mcp add atimelogger --env ATL_TOKEN=atl_pat_... -- npx -y atimelogger-mcp

Equivalent ~/.codex/config.toml block:

[mcp_servers.atimelogger]

command = "npx" args = ["-y", "atimelogger-mcp"] env = { "ATL_TOKEN" = "atl_pat_..." }

MCP support in Codex is not gated by plan — it works with any ChatGPT subscription that includes Codex, or with a plain API key. (Using the tools from the ChatGPT web/mobile app is a different path — see Connect from ChatGPT below.)

Running from source

Instead of the published package, you can clone and build:

git clone https://github.com/zaplitny/atimelogger-mcp && cd atimelogger-mcp

npm install npm run build npm run setup # paste the token, verifies it, prints registration snippets pointing at the local build

Troubleshooting: a 401 from any tool means the token is invalid, expired, or was revoked — generate a new one in Settings → API Tokens and update ATL_TOKEN in the MCP config.

No token yet? The server also starts without ATL_TOKEN in docs-only mode: the app_help tool (official app documentation) works, so you can ask your assistant how ATimeLogger features work before setting up API access; the time-tracking tools return setup instructions until a token is configured.

Tools

Tools accept human-readable type names (fuzzy matched); internal ids also flow through tool outputs and parameters for exact targeting, but are never shown to the user. Durations are returned as "2h 15m" strings; times are shown in the user's ATimeLogger timezone unless a timezone parameter is given.

Usage examples

Things you can say to your assistant once the server is registered:

Timers

"Start tracking work" · "Stop the timer" · "Pause reading, I'll be back in 10" · "What am I tracking right now?"

Backdating — forgot to press start or stop:

"Start Development — I actually began at 11:30" · "Stop work, I finished 20 minutes ago" · "I've been in a meeting since 14:00, track it"

Logging past activities

"Log 2 hours of Reading yesterday from 9 to 11pm" · "Add a gym session for last Saturday morning, 90 minutes, tag it 'legs'" · "I slept from 23:30 to 7:15, log it"

Annotating existing entries

"Add a note to the current timer: reviewing the Q3 report" · "Tag this morning's Work session with 'client-x'" · "Update yesterday's meeting entry — it was the architecture sync"

Reports & history

"Where did my week go?" · "How much did I work in June, broken down by week?" · "Compare my sleep this month vs last month" · "Show everything I tracked today" · "Which day last week had the most Development time?"

Learning the app — answered from the official documentation rather than guesswork:

"How do goals work?" · "Why isn't my sync picking up yesterday's entries?" · "What's the difference between a group and a type?" · "Can I export to CSV?" · "How do I edit an entry's times?"

Combinations — the assistant chains tools on its own:

"Stop whatever is running and start Work" · "Continue from where the last entry ended — start Development from that time" · "Fill yesterday's gap between lunch and the meeting with Reading"

Activity names are fuzzy-matched against your own type list, so "start dev" finds "Development"; the assistant asks when a name is ambiguous.

Command-line interface

atimelogger-cli is installed by the same package and stands on its own — no MCP client, no assistant, no API key beyond the same ATL_TOKEN. It is a read-only JSON CLI for scripts and automation (cron jobs, status bars, shell pipelines) where speaking MCP is impractical, and it reuses the internals the MCP tools are built on: fuzzy type names, period words, DST-correct timezones, humanized durations.

export ATL_TOKEN=atl_pat_...

npx -y -p atimelogger-mcp atimelogger-cli status atimelogger-cli report --period this_week --type work atimelogger-cli intervals --period yesterday --tag gym --compact | jq .

Commands: status, types, report, intervals, plus doctor — run atimelogger-cli --help for all options. doctor is the first thing to run when something is off: it checks the token's presence and shape, whether the host is reachable, whether the token still authenticates, and whether the account has trackable types, telling you which layer broke instead of leaving you to guess. It exits 1 when unhealthy and never echoes the token. Output is always JSON (pretty by default, --compact for one line) with stable keys: durations carry both a humanized string and raw seconds, paging is a has_more boolean, and empty results give [] rather than dropping the key — so jq pipelines don't break on a quiet day. Errors go to stderr as {"error": "..."} with exit code 1 (2 for usage mistakes, including an unresolvable --type). The CLI never starts, stops, or edits anything — write operations stay in the MCP server, where a human is in the loop; scripted writes from cron are retry-prone and can corrupt your timeline.

Library use (experimental)

The package also exports its task-shaped core, so a long-running process can call ATimeLogger in-process instead of spawning a binary per request — useful for daemons, bots, editor plugins, or anything that wants the conveniences (fuzzy type names, period words, DST-correct timezones, humanized durations) without the MCP transport.

import { createClient, clientFromEnv } from "atimelogger-mcp";

const atl = createClient({ token }); // credentials passed explicitly // …or, for the single-account case, read ATL_TOKEN + ATL_BASE_URL: // const atl = clientFromEnv();

// reads const { active } = await atl.status(); const { duration, seconds, by_type } = await atl.report({ period: "this_week", type_names: ["work"] }); const { days, has_more } = await atl.intervals({ period: "yesterday" });

// writes await atl.start({ type_name: "development", started_minutes_ago: 10 }); await atl.stop(); // name optional if one is active await atl.pauseResume({ action: "pause" }); await atl.log({ type_name: "reading", from: "2026-08-05 21:00", to: "2026-08-05 22:30" }); await atl.update({ activity_id, comment: "architecture sync" });

await atl.api.get("/api/…"); // escape hatch for anything unwrapped

Prefer clientFromEnv() over hand-rolling createClient({ token: process.env.ATL_TOKEN }) — the latter ignores ATL_BASE_URL and would silently target production. Unlike the MCP server and the CLI, it throws rather than exiting the host process when no token is configured.

Writes are part of the client rather than something you assemble against api, because the sequencing matters: update does a read-modify-write, since a raw PUT soft-deletes every interval missing from the payload and would silently destroy the entry's tracked time. (The CLI stays read-only for a different reason — unattended shell retries, not programs.)

Results are fully typed (CurrentStatus, TimeReport, IntervalsPage, StartedActivity, …), and every field is present unless its type marks it optional — days, active and by_type are empty arrays rather than missing keys, so destructuring is safe on empty results. Durations come as both a humanized string and raw seconds. Errors are typed too: UsageError (bad arguments or an unresolvable type name), ApiError (the server answered with a failure, carries .status), NetworkError (the request never arrived, keeps the original as .cause).

Each client owns its own HTTP client and caches, so several accounts can coexist in one process. A fetch override makes fixture-backed testing straightforward, with no network access:

const atl = createClient({ token: "test", baseUrl: "https://example.test", fetch: fakeFetch });

app_help is not part of this surface — it answers from the public documentation site rather than the account, so it stays an MCP tool.

These clients are purely in-process — no daemon, no persisted state, nothing shared between invocations; keep the process alive to keep the caches warm. Importing the library never reads the environment. Experimental while the package is 0.x: signatures may change in a minor release, so pin an exact version if you depend on them.

Remote server (Custom Connector)

Besides the local stdio setup above, the server can run as a remote MCP server and connect to Claude as a Custom Connector — or to ChatGPT via Developer Mode (section C). This is the path to use if you want to reach your ATimeLogger data from claude.ai in the browser, the Claude mobile apps, or the ChatGPT web/mobile apps, where local stdio servers aren't available.

There are two audiences here: people who just want to connect to a running endpoint, and people who want to self-host their own.

A. Connect to a remote endpoint

If you have the HTTPS URL of a running instance (for example one you ho