Atimelogger MCP Server

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 — 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.

2. 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 host yourself, per section B):

1. Open claude.ai in a browser (desktop or mobile). The one-time "add" step is done in the web UI; once added it also shows up in the mobile apps.
2. Go to Settings → Connectors → Add custom connector.
3. Enter a name (e.g. ATimeLogger) and the server URL, ending in /mcp:

   https://your-host.example.com/mcp
   

4. Click Add.
5. In any chat, open the + menu → Connectors and toggle the connector on.

Then talk to Claude as usual — "what am I tracking right now?", "where did my week go?", etc. (see Usage examples). On mobile it works the same way once the connector is enabled for the conversation.

Note on how Claude reaches your server. Custom connectors connect from Anthropic's cloud infrastructure, not from your own device — this is true even in the mobile apps and Claude Desktop. Your endpoint must be reachable over the public internet. A server on localhost, behind a VPN, or blocked by a firewall won't connect even though you can reach it from your own machine.

B. Self-host the remote endpoint

The server speaks stdio, so to expose it over HTTPS you put a small proxy in front that serves it over Streamable HTTP, then terminate TLS with a reverse proxy. One working setup:

1. Run the server behind an HTTP proxy, in Docker. The host only needs Docker — no source checkout, no Node install. The image pulls the published npm package plus mcp-proxy, which serves the stdio server over Streamable HTTP:

FROM node:22-slim
RUN npm i -g atimelogger-mcp mcp-proxy
EXPOSE 8080
CMD ["mcp-proxy", "--port", "8080", "--", "atimelogger-mcp"]

Pin a version (npm i -g atimelogger-mcp@0.1.0) if you want reproducible rebuilds; to upgrade later, rebuild with --no-cache (or bump the pin) and recreate the container.

Build and run it, bound to localhost only, with your token passed as an env var:

docker build -t atimelogger-mcp .
docker run -d --name atimelogger-mcp \
  -p 127.0.0.1:9095:8080 \
  --restart unless-stopped \
  -e ATL_TOKEN=atl_pat_your_token_here \
  atimelogger-mcp

Verify it's up locally (a bare GET returns 400 Bad Request — that's expected, it means the endpoint is listening and refusing an incomplete handshake):

curl -i http://127.0.0.1:9095/mcp

2. Put a TLS reverse proxy in front. Example nginx location block inside your HTTPS server block. The streaming directives (proxy_buffering off, long proxy_read_timeout) matter — without them the connection stalls:

location /mcp {
    proxy_pass http://127.0.0.1:9095/mcp;
    proxy_http_version 1.1;

    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # streaming essentials
    proxy_set_header Connection '';
    proxy_buffering  off;
    proxy_cache      off;
    proxy_read_timeout  3600s;
    chunked_transfer_encoding on;
}

sudo nginx -t && sudo systemctl reload nginx

Your public endpoint is now https://your-host.example.com/mcp — add it as a Custom Connector per section A.

3. Test before wiring up Claude (optional). The MCP Inspector confirms the endpoint independently:

npx @modelcontextprotocol/inspector

Set transport type to Streamable HTTP, enter the URL, and check that the handshake succeeds and the tool list appears.

Security — read before exposing this. The remote server is authenticated by the single ATL_TOKEN baked into the container, so anyone who can reach the URL acts as you against your ATimeLogger account. There is no per-user login at the MCP layer. If you self-host:

• Keep the endpoint private (don't publish the URL), or put an auth check in front of it (e.g. a required header or basic auth in nginx).
• Only bind the container to 127.0.0.1 (as above) so the raw HTTP port is never exposed directly — nginx stays the only public door.
• Treat the token like a password; rotate it from Settings → API Tokens if it's ever exposed.

C. Connect from ChatGPT (Developer Mode)

The same remote endpoint works in the ChatGPT web app as a custom MCP app via Developer Mode (paid plans). The exact settings location and flow change from time to time — follow the official guide: https://developers.openai.com/api/docs/guides/developer-mode. In short:

1. Enable Developer mode in ChatGPT settings (see the guide for where it currently lives).
2. Create a new app/connector for the server URL ending in /mcp, with authentication set to None (the ATimeLogger token lives server-side; see the security note above).
3. Enable it in a chat, then talk as usual — "what am I tracking right now?", "log 2 hours of reading yesterday 9 to 11pm".

Notes:

• Set it up once in the web app; after that the connector also works in the ChatGPT mobile apps.
• ChatGPT connects from OpenAI's infrastructure, so the endpoint must be publicly reachable — same rule as for Claude custom connectors.
• Write actions (starting/stopping timers, logging entries) ask for confirmation in ChatGPT before running by default.
• Plan, region, and feature limitations may apply and change over time — check the official documentation for the current state. (Don't confuse Developer Mode with ChatGPT's search/fetch-only connectors for Deep Research — this server exposes action tools, so Developer Mode is the path that works.)

Limitations

• start_activity cannot attach a comment (the underlying start endpoint takes only a type and time); add one afterwards with update_activity, or use log_interval for retroactive entries with comments/tags.
• Only comments and tags of existing entries can be edited (update_activity); interval times cannot be changed and entries cannot be deleted — use the ATimeLogger app for that (the assistant can explain how via app_help).
• History requests are capped at 100 days by the backend.