How do I use keeping-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@keeping-mcp log 2 hours of development work for project Alpha" 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.

keeping-mcp

Official

by Red-Square-Software

Overview Schema Related Servers Score Discussions

TypeScript

Remote

keeping-mcp

Open-source Model Context Protocol (MCP) server that exposes the Keeping (api.keeping.nl) time-tracking API as tools an AI coding assistant can call. Built for solo developers who use Claude Code (or any MCP-capable client) and want their billable hours logged into Keeping at the end of a session instead of typed in by hand, while keeping Keeping's existing native Jortt invoicing integration intact. Every write tool is dry-run by default — your hours never reach Keeping until you explicitly confirm.

⚠ Writes are dry-run BY DEFAULT
Every write tool (keeping_add_entry, keeping_update_entry, keeping_delete_entry, keeping_start_timer, keeping_stop_timer, keeping_resume_timer) returns a preview unless you pass confirm: true in the tool call.
Setting KEEPING_REQUIRE_CONFIRM=false in your environment disables this gate. Writes then happen on the first call — there is no second chance.
Recommendation: never disable this gate unless you are running the server in a non-interactive automation context and have explicitly accepted the loss of the confirmation step.

Related MCP server: WorkTracker MCP Server

Install

From npm

No install required — npx fetches the package on first run:

KEEPING_TOKEN=kp_live_your_token_here npx -y keeping-mcp

The server speaks the MCP stdio protocol and stays in the foreground waiting for JSON-RPC frames on stdin — exit with Ctrl+C. In practice you do not run it by hand; an MCP-capable client (Claude Code, Claude Desktop, Cursor, etc.) spawns it for you using the config snippets below.

Optional — install globally so keeping-mcp is on your PATH:

npm install -g keeping-mcp
KEEPING_TOKEN=kp_live_your_token_here keeping-mcp

Requires Node.js >=22. The package is published to npmjs.com/package/keeping-mcp with sigstore provenance attestations.

Claude Code on Windows 11

Add to %APPDATA%\Claude\claude_desktop_config.json or to your project's .mcp.json file.

{
  "mcpServers": {
    "keeping-mcp": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "keeping-mcp"],
      "env": {
        "KEEPING_TOKEN": "kp_live_your_token_here"
      }
    }
  }
}

The cmd /c wrapper is required on Windows — npx resolves to npx.cmd, and Claude Code's process spawn does not search PATHEXT extensions (see anthropics/claude-code#58510).

Claude Code on macOS / Linux

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or ~/.config/Claude/claude_desktop_config.json (Linux), or your project's .mcp.json.

{
  "mcpServers": {
    "keeping-mcp": {
      "command": "npx",
      "args": ["-y", "keeping-mcp"],
      "env": {
        "KEEPING_TOKEN": "kp_live_your_token_here"
      }
    }
  }
}

Other MCP clients

Any MCP-capable client that supports the stdio transport works. The server is started by npx -y keeping-mcp and reads KEEPING_TOKEN from its environment. Discoverable in the MCP Registry as io.github.Red-Square-Software/keeping-mcp.

Get a Keeping access token

Sign in to your Keeping account.
Open Preferences (top-right menu).
Find the section Show features for developers and enable it.
A new Personal access tokens section appears.
Click Generate new token, name it (e.g. "Claude Code"), and copy the value.
Store it as KEEPING_TOKEN in your shell environment OR in your Claude Code config env block.

The token has full read+write access to your time entries — treat it like a password. Never commit it to git, never paste it into a chat, never read it back from a tool response (keeping-mcp never echoes it).

Configuration

Variable	Required	Default	Purpose
`KEEPING_TOKEN`	yes	—	Keeping personal access token (created via the section above).
`KEEPING_REQUIRE_CONFIRM`	no	`true`	When `true`, write tools return a preview unless called with `confirm: true`. Setting to `false` disables the gate entirely — see warning below.
`KEEPING_ORG_ID`	no	—	Pin all calls to one organisation id. When unset and the token has access to multiple orgs, write tools require explicit `organisation_id` input per call.
`KEEPING_LOG_LEVEL`	no	`info`	Server stderr log verbosity. Accepts: `debug`, `info`, `warn`, `error`.

⚠ Writes are dry-run BY DEFAULT
Every write tool (keeping_add_entry, keeping_update_entry, keeping_delete_entry, keeping_start_timer, keeping_stop_timer, keeping_resume_timer) returns a preview unless you pass confirm: true in the tool call.
Setting KEEPING_REQUIRE_CONFIRM=false in your environment disables this gate. Writes then happen on the first call — there is no second chance.
Recommendation: never disable this gate unless you are running the server in a non-interactive automation context and have explicitly accepted the loss of the confirmation step.

Tools

keeping-mcp registers 12 tools when the server starts. Read tools (keeping_me, keeping_organisations, keeping_projects, keeping_tasks, keeping_list_entries, keeping_timer_status) call Keeping's API without confirmation. Write tools (keeping_add_entry, keeping_update_entry, keeping_delete_entry, keeping_start_timer, keeping_stop_timer, keeping_resume_timer) return a dry-run preview unless invoked with confirm: true (default behavior controlled by KEEPING_REQUIRE_CONFIRM).

Dry-run workflow (example transcript)

Write tools follow a two-step pattern: propose-then-confirm. The first call returns a preview of the HTTP request the server would send; the second call (with confirm: true) actually sends it.

Step 1 — preview (no confirm, no API call made). Illustrative; actual field names match Keeping's OpenAPI (see https://developer.keeping.nl).

{
  "tool": "keeping_add_entry",
  "input": {
    "description": "Phase 4 release prep",
    "hours": 1.5,
    "project_id": 123
  },
  "response": {
    "would_post": {
      "method": "POST",
      "url": "https://api.keeping.nl/v1/456/time-entries",
      "body": {
        "description": "Phase 4 release prep",
        "hours": 1.5,
        "project_id": 123,
        "date": "2026-06-12",
        "purpose": "work"
      }
    }
  }
}

Step 2 — confirm (confirm: true added, request is sent to Keeping). Illustrative; actual response shape mirrors Keeping's OpenAPI.

{
  "tool": "keeping_add_entry",
  "input": {
    "description": "Phase 4 release prep",
    "hours": 1.5,
    "project_id": 123,
    "confirm": true
  },
  "response": {
    "id": 98765,
    "day": "2026-06-12",
    "hours": 1.5,
    "description": "Phase 4 release prep",
    "project_id": 123,
    "purpose": "work"
  }
}

Verifying provenance

Releases are published via GitHub Actions OIDC trusted publishing (no long-lived npm tokens). Every release carries an npm provenance attestation linking the published tarball to a specific commit in this repository.

npm audit signatures
# or, for a single package:
npm view keeping-mcp --json | jq '.dist.attestations'

Local development

git clone https://github.com/red-square-software/keeping-mcp.git
cd keeping-mcp
npm ci
npm test
npm run build
KEEPING_TOKEN=kp_live_your_token_here node dist/bin/keeping-mcp.js

All server output goes to stderr — stdout is reserved for MCP JSON-RPC framing. Never write diagnostic output to stdout; use console.error for logging.

License

MIT — see LICENSE.

Available Tools

12 tools

keeping_add_entryCreate a time entryA

Destructive

Create a new time entry. DRY-RUN BY DEFAULT — call without confirm first to receive a would_post preview; call again with confirm: true ONLY after a human reviewed the preview. Body shape depends on the organisation's timesheet mode: 'times' mode requires start/end (HH:mm in org timezone); 'hours' mode requires a decimal hours value. Purpose defaults to 'work'. The date defaults to today in Europe/Amsterdam.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No	HH:mm in org timezone; only used when org timesheet is 'times' mode.
`date`	No	Calendar date YYYY-MM-DD; defaults to today in Europe/Amsterdam.
`note`	No
`hours`	No	Decimal hours; required when org timesheet is 'hours' mode.
`start`	No	HH:mm in org timezone; only used when org timesheet is 'times' mode.
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`purpose`	No	Time-entry category. Maps to Keeping's purpose enum; billable status is determined at the project level.	work
`tag_ids`	No
`task_id`	No
`project_id`	No
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.
`external_references`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, destructiveHint=true which seems contradictory), the description adds critical behavioral context: dry-run default, confirmation requirement, and mode-dependent body shape. This helps the agent understand the non-standard create process.

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?

Three sentences, front-loaded with core action, then process, then mode dependency. No wasted words; every sentence adds essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters and no output schema, the description covers the key complexities (dry-run, mode, defaults). Omits details on some optional params (tag_ids, project_id, etc.) but those are documented in schema. Lacks description of the preview object, but the existence of a preview is mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema: purpose defaults to 'work', date defaults to Europe/Amsterdam today, and clarifies when start/end or hours are needed. Schema coverage is 58%, so description compensates well by explaining contextual requirements.

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 'Create a new time entry' and provides specific details about dry-run behavior and mode-dependent parameters, distinguishing it from sibling tools like list, update, delete, and timer operations.

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?

Explicitly explains the two-step process: first dry-run for preview, then confirm with human review. Also clarifies when to use start/end vs hours based on org timesheet mode. No explicit exclusion of alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_delete_entryDelete a time entryA

Destructive

DESTRUCTIVE: permanently deletes the entry — cannot be undone. Owns the dry-run gate: without confirm: true, the tool fetches the entry and returns a would_delete preview so a human can verify the right entry is targeted. Only call with confirm: true after a human reviewed the preview.

ParametersJSON Schema

Name	Required	Description
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`entry_id`	Yes	Numeric Keeping time-entry id to permanently delete.
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark destructiveHint: true, but description adds context: permanently deletes, cannot be undone, preview behavior, and human verification requirement. Adds value beyond 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?

Very concise, front-loads the most important point (destructive, permanent). Uses bold for emphasis. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the tool's behavior (preview vs delete) is well explained. Lack of description about return values is minor for a delete operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with 100% coverage. Description adds context on how confirm parameter interacts with the preview flow, which is helpful but not essential beyond the schema.

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?

Clearly states 'permanently deletes the entry' and 'cannot be undone'. Distinguishes from sibling tools like keeping_add_entry and keeping_update_entry.

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?

Explicitly explains the dry-run gate: without confirm: true, it returns a preview. Instructs to only call with confirm: true after human review. Provides clear when-to-use and 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.

keeping_list_entriesList time entriesA

Read-onlyIdempotent

Returns time entries for a date range. Wire shape preserved exactly as returned by the Keeping API — no field renaming — so this tool doubles as schema discovery for Phase 3 write tools. Dates are calendar dates in YYYY-MM-DD; not UTC timestamps. Single-day calls hit GET /{orgId}/time-entries?date=...; multi-day ranges hit GET /{orgId}/report/time-entries?from=...&to=....

ParametersJSON Schema

Name	Required	Description
`to`	No	Inclusive end date; defaults to `from` (single day).
`from`	Yes	Inclusive start date. Calendar date in YYYY-MM-DD; Europe/Amsterdam timezone.
`limit`	No
`user_id`	No	Defaults to the authenticated user.
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.6/5.0

Behavior5/5

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 significant behavioral context: wire shape preservation for schema discovery, date format (calendar dates, not UTC), and endpoint selection logic (single-day vs multi-day). 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences. Each sentence serves a distinct purpose: stating the core function, explaining the schema discovery benefit, and providing date/endpoint details. No superfluous information. Front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and no output schema, the description covers key context: date behavior, endpoint variation, and schema preservation. However, it does not mention pagination or handling of large result sets beyond the 'limit' parameter. This is a minor gap but not critical for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so baseline is 3. The description adds meaning beyond the schema by explaining the 'to' defaults to 'from' for single-day calls, the 'from' parameter timezone (Europe/Amsterdam), and that 'user_id' defaults to authenticated user. This enriches the agent's understanding of parameter behavior.

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 'Returns time entries for a date range' with a specific verb ('Returns') and resource ('time entries'). It distinguishes from sibling write tools by being a read-only list operation. The description also provides implementation details (API endpoints) that clarify the purpose.

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?

The description implicitly guides usage by explaining the tool's dual role: reading time entries and schema discovery for write tools. It explains date range behavior and API routing but does not explicitly state when to avoid this tool or name alternatives among siblings. The context from sibling names (e.g., keeping_add_entry) makes the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_meWho am IA

Read-onlyIdempotent

Returns the authenticated user (id, first_name, surname, code, role, state) wrapped under a user key, plus the resolved organisation_id. Identity is cached for the server's lifetime. Pass the optional organisation_id input to override the KEEPING_ORG_ID default; required when the token has access to multiple organisations.

ParametersJSON Schema

Name	Required	Description	Default
`organisation_id`	No	Override KEEPING_ORG_ID. Required when token has access to multiple orgs.

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds caching behavior (identity cached for server lifetime) and output format, which are valuable beyond 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?

Two sentences: first states purpose and output structure, second adds caching and parameter usage. No wasted words, front-loaded with key information.

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 no output schema, the description fully explains the return shape, caching, and parameter semantics. No gaps for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description explains the parameter's purpose ('override the KEEPING_ORG_ID default; required when the token has access to multiple organisations'), adding context not in the schema.

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 returns the authenticated user with specific fields (id, first_name, etc.) wrapped under a 'user' key, plus the resolved organisation_id. This distinguishes it from sibling tools that return lists of organisations, projects, etc.

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?

Describes when to use the tool (get identity) and specifies when the optional organisation_id parameter is needed (required for multi-org tokens). This gives clear context for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_organisationsList organisationsA

Read-onlyIdempotent

Returns the list of organisations the token can access. Each organisation includes feature flags (projects, tasks, timesheet_mode) verbatim from the API. Cached for the server's lifetime.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds caching behavior ('Cached for the server's lifetime') and notes that feature flags are included verbatim, providing value beyond 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?

Two clear sentences with no unnecessary words. Front-loaded purpose and includes key behavioral detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, description covers the main output (list of organisations with feature flags) but could be more detailed about other response fields. Still adequate for understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so description does not need to add parameter information. Baseline score of 4 given zero parameters.

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?

Description clearly states the tool returns a list of organisations the token can access. It uses specific verb 'returns' and resource 'organisations', distinguishing it from sibling tools like keeping_projects and keeping_tasks.

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?

The context implies using this tool to get organisations, and siblings cover other resources. However, no explicit guidance on when to use or not use this tool versus alternatives is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_projectsList projectsA

Read-onlyIdempotent

Returns the list of projects available for the selected organisation. If the projects feature is disabled for the organisation, returns a human-readable note instead of an error. Not cached — fresh per call.

ParametersJSON Schema

Name	Required	Description	Default
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds 'Not cached — fresh per call,' which is behavioral context beyond annotations. It also clarifies the non-error response for disabled features.

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?

Three short sentences: purpose, edge case, caching behavior. No redundant words, front-loaded with core purpose. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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, no output schema), the description covers purpose, edge case, and caching. It could optionally mention the return format (list of project objects), but not required for completeness. Overall adequate.

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%, so the schema already documents the single optional parameter. Description does not add new parameter semantics beyond what the schema provides, justifying baseline score of 3.

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?

Description clearly states 'Returns the list of projects available for the selected organisation,' specifying verb ('Returns') and resource ('projects'). It distinguishes from sibling tools like keeping_tasks or keeping_list_entries by focusing on projects. The mention of behavior when disabled adds further clarity.

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?

Usage is clearly implied: call to get projects. It notes the edge case of a disabled projects feature, guiding the agent on expected output (note vs error). However, no explicit when-not-to-use or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_resume_timerResume a stopped timerA

Destructive

Resume a previously-stopped time entry as an ongoing timer. Implemented as POST /{orgId}/time-entries/{entry_id}/resume. Returns the resumed entry plus server_time_ms — the millisecond-precision server timestamp captured from the X-Server-Time-Ms response header (TIMER-02). When the header is missing or unparseable, server_time_ms falls back to the local clock and a warning is logged to stderr. NOTE: Keeping may return a different time_entry.id than the input entry_id — when the original entry's date is no longer 'today', Keeping creates a NEW ongoing entry rather than modifying the old one. Always read time_entry.id from the response; do not assume it matches your input. Cannot resume locked entries (returns a 403 error). DRY-RUN BY DEFAULT — call without confirm first to receive a would_post preview; call again with confirm: true ONLY after a human reviewed the preview.

ParametersJSON Schema

Name	Required	Description
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`entry_id`	Yes	Numeric Keeping time-entry id of the previously-stopped entry to resume.
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations: dry-run behavior, ID change on non-today entries, fallback for server_time_ms, and error handling (403 for locked). Annotations only indicate readOnlyHint=false and destructiveHint=true; the description elaborates fully.

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 lengthy but every sentence adds value. It is front-loaded with the main purpose. Could be slightly more concise, but no unnecessary words.

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 no output schema, the description explains the return value (resumed entry plus server_time_ms) and covers key scenarios (locked entries, ID change). Complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds critical context for the 'confirm' parameter (must not be set autonomously) and explains the dry-run flow, which goes beyond schema descriptions.

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 starts with a clear verb+resource: 'Resume a previously-stopped time entry as an ongoing timer.' This distinguishes it from sibling tools like keeping_start_timer and keeping_stop_timer.

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?

Explicit step-by-step guidance: dry-run first, then confirm only after human review. Also notes limitations (locked entries, ID change). Provides a complete usage pattern.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_start_timerStart a running timerA

Destructive

Start a new ongoing time entry (a running timer). Implemented as POST /{orgId}/time-entries with start set and NO end / NO hours — Keeping interprets the omission of end as 'this entry is ongoing'. Returns { timer_id } on success; use this id with keeping_stop_timer or keeping_resume_timer. DRY-RUN BY DEFAULT — call without confirm first to receive a would_post preview; call again with confirm: true ONLY after a human reviewed the preview. start defaults to the current time in Europe/Amsterdam; purpose defaults to 'work'.

ParametersJSON Schema

Name	Required	Description	Default
`note`	No
`start`	No	HH:mm in org timezone; defaults to the current time in Europe/Amsterdam when omitted.
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`purpose`	No	Time-entry category. Maps to Keeping's purpose enum; billable status is determined at the project level.	work
`task_id`	No
`project_id`	No
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the tool creates a running timer via POST, omitting end/hours to indicate ongoing status. Aligns with annotations (destructiveHint=true, readOnlyHint=false). 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Brief three sentences covering purpose, API details, workflow, and defaults with no unnecessary words.

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 7 parameters, no output schema, and annotations, the description covers the workflow, defaults, and purpose, leaving no critical gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning for start (defaults to Europe/Amsterdam current time) and purpose (defaults to 'work'), and explains confirm's role. However, doesn't cover note, task_id, project_id, organisation_id beyond schema, which have 57% coverage.

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?

Clearly states the tool starts a running timer, describes the HTTP POST implementation, and distinguishes from siblings like keeping_stop_timer and keeping_resume_timer by specifying the returned timer_id.

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?

Explicitly explains the dry-run default workflow: call without confirm first to get a preview, then with confirm true only after human review. Also directs to use the resulting timer_id with stop/resume tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_stop_timerStop a running timerA

Destructive

Stop an ongoing time entry (running timer) by setting its end. Implemented as PATCH /{orgId}/time-entries/{entry_id}/stop. Returns the updated entry plus server_time_ms — the millisecond-precision server timestamp captured from the X-Server-Time-Ms response header (TIMER-02). When the header is missing or unparseable, server_time_ms falls back to the local clock and a warning is logged to stderr. DRY-RUN BY DEFAULT — call without confirm first to receive a would_post preview; call again with confirm: true ONLY after a human reviewed the preview.

ParametersJSON Schema

Name	Required	Description
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`entry_id`	Yes	Numeric Keeping time-entry id of the ongoing entry to stop.
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructiveHint annotation, the description discloses the PATCH endpoint, return value including server_time_ms with fallback behavior, and dry-run preview mechanism. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core action, but includes some repetitive details (e.g., endpoint path) that could be condensed. Still, most sentences earn their place.

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 fully explains the return object and error handling for missing headers. It covers the complete workflow from dry-run to confirmed execution, leaving no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds critical semantics: clarifies the confirm parameter's dry-run workflow and restrictions, entry_id as numeric ID, and organisation_id as override for multi-org tokens.

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 stops an ongoing timer by setting its end, with a specific verb and resource. It distinguishes itself from siblings like keeping_start_timer and keeping_resume_timer by focusing on stopping.

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 provides explicit usage guidance: dry-run by default, then confirm only after human review. It warns the LLM not to set confirm autonomously, which is crucial for safe invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_tasksList tasksA

Read-onlyIdempotent

Returns the list of tasks available for the selected organisation. If the tasks feature is disabled for the organisation, returns a human-readable note instead of an error. Not cached — fresh per call.

ParametersJSON Schema

Name	Required	Description	Default
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description adds value by stating the special error handling and that it is not cached, providing useful behavioral insights beyond 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?

Three concise and well-structured sentences, each adding essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers purpose, special behavior, and caching. Lacks explicit return format but is sufficient for a tool with no output schema and simple input.

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 a clear description for the only parameter. The tool description does not add further semantic details about the parameter.

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?

Clearly states it returns the list of tasks for the selected organisation, with a special behavior of returning a note instead of an error when disabled. Distinguishes itself from siblings by focusing on listing tasks.

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?

Explicitly describes when to use (to get tasks for the organisation) and notes the edge case of disabled feature. Lacks explicit alternatives but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_timer_statusTimer status (read-only)A

Read-onlyIdempotent

Returns the most recent time entry for the authenticated user plus a derived is_running boolean indicating whether a Keeping timer is currently running. Read-only; no API mutation. Use this to decide whether keeping_stop_timer (running timer → stop) or keeping_resume_timer (stopped entry → resume) is the appropriate next call (both ship in Phase 3).

ParametersJSON Schema

Name	Required	Description	Default
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context (derived is_running, no API mutation) without contradicting 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?

Two sentences, front-loaded with essential information, every sentence adds value. No wasted words.

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?

Even without an output schema, the description explains the return value (most recent time entry and is_running boolean). Annotations cover safety, so the description is fully complete for this read-only tool.

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?

Only one optional parameter (organisation_id) with 100% schema description coverage. The description adds no additional meaning 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?

The description clearly states it returns the most recent time entry and a derived is_running boolean. It distinguishes itself from sibling tools by noting it is read-only and used to decide between stop or resume timer calls.

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?

Explicitly states to use this tool to decide whether keeping_stop_timer or keeping_resume_timer is appropriate, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keeping_update_entryUpdate a time entryA

Destructive

Edit an existing time entry owned by the authenticated user. PATCH semantics — only the fields you supply are updated. DRY-RUN BY DEFAULT — call without confirm first to receive a would_post preview; call again with confirm: true ONLY after a human reviewed the preview. NOTE: date, purpose, and user_id are immutable in Keeping; this tool does not accept them.

ParametersJSON Schema

Name	Required	Description
`end`	No	HH:mm in org timezone; only used when org timesheet is 'times' mode.
`note`	No
`hours`	No	Decimal hours; only used when org timesheet is 'hours' mode.
`start`	No	HH:mm in org timezone; only used when org timesheet is 'times' mode.
`confirm`	No	Set to true ONLY after a human has reviewed the would_post preview returned by a prior dry-run call. The MCP client (LLM) MUST NOT set this autonomously — wait for the human to type 'yes' / 'confirm'.
`tag_ids`	No
`task_id`	No
`entry_id`	Yes	Numeric Keeping time-entry id to update.
`project_id`	No
`organisation_id`	No	Override KEEPING_ORG_ID; required for multi-org tokens.
`external_references`	No

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds critical behavioral details beyond annotations: PATCH semantics, dry-run default, confirmation requirement, and immutable fields. Annotations already indicate write and destructive, but description enriches understanding.

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 concise sentences plus a note; all sentences are essential and front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains the critical dry-run workflow and immutability. Lacks details on return values or error handling, but for an update tool without output schema, it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 55% with many parameters described in schema. The description adds general context (PATCH semantics, immutable fields) but does not detail the undocumented parameters (note, hours, etc.). Still adds value beyond schema.

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?

Clearly states 'Edit an existing time entry' with verb and resource. Differentiates from sibling add/delete tools by specifying PATCH semantics and immutable fields.

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?

Explicitly describes the two-step dry-run-then-confirm process, instructs not to set confirm autonomously, and notes that date/purpose/user_id are immutable. Provides clear when-to-use context.

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. Dates show when Glama detected each change.

12 tool updatesv1.0.1Jul 29, 2026
- First observedkeeping_add_entry
- First observedkeeping_delete_entry
- First observedkeeping_list_entries
- First observedkeeping_me
- First observedkeeping_organisations
- First observedkeeping_projects
- First observedkeeping_resume_timer
- First observedkeeping_start_timer
- First observedkeeping_stop_timer
- First observedkeeping_tasks
- First observedkeeping_timer_status
- First observedkeeping_update_entry

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: user info, organisations, projects, tasks, entries (CRUD), timer status, and timer lifecycle (start/stop/resume). No two tools have overlapping purposes.

Naming Consistency4/5

All tools share a consistent keeping_ prefix and snake_case. Some are noun-only (keeping_me, keeping_organisations) while others are verb_noun (keeping_list_entries, keeping_add_entry), but the pattern is predictable and readable.

Tool Count5/5

12 tools cover the essential operations for a time-tracking server: identity, lists, full entry CRUD, and timer management. Neither too sparse nor overloaded.

Completeness4/5

Core workflows are fully supported: listing resources, managing entries, and controlling timers. Missing update/delete for projects and tasks, but those resources appear read-only in the API, so the gap is minor.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

invoice-badgerOAuth
com.invoicebadger
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Finance Payments & Billing
2
Tallymeter
com.tallymeter
Time tracking and invoicing for AI agents and their humans: track, log and bill work by agent.
Project Management Payments & Billing Workplace & Productivity
2
KeitoOAuth
io.github.osodevops
Track Keito time entries and LLM costs from AI agents.
AI & Machine Learning Observability Developer Tools
2
copilotcliswitchgate-mcp
com.clauxel.copilotcliswitchgate
Remote MCP for Copilot CLI switch gate MCP, structured receipts, audit logs, and reviewer-ready evid
CI/CD & DevOps Feature Flags Developer Tools
2

Related MCP Servers

Timesheet MCP Serverofficial
Project Management Workplace & Productivity
timesheetIO
A
license
B
quality
B
maintenance
Enables natural language control of the Timesheet API for timer management, task tracking, and project management through MCP tools.
Updated 19 days ago (2026-08-18 17:52 UTC)
50
74
1
MIT
WorkTracker MCP Server
Project Management Workplace & Productivity
SkyTechNerds
A
license
Not graded
quality
B
maintenance
Enables natural language time tracking and booking for WorkTracker via MCP tools, allowing users to assign time, list projects, and manage daily schedules through conversational commands.
Updated 23 days ago (2026-08-14 12:45 UTC)
MIT
Work-Timer
Project Management Finance
JoelBondoux
A
license
Not graded
quality
D
maintenance
An MCP server for time tracking and billing that allows freelancers to control timers, manage projects, and export invoices via natural language in any MCP-compatible AI assistant.
Updated 2 days ago (2026-09-03 21:34 UTC)
6
MIT
WBSO MCP Server
Project Management Research & Data Developer Tools
rubenmaas
F
license
B
quality
F
maintenance
Enables AI assistants to automatically detect WBSO-relevant work and log R&D time tracking entries based on configurable project criteria.
Updated 8 months ago (2026-01-13 12:26 UTC)
8
3
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Red-Square-Software/keeping-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

keeping-mcp

⚠ Writes are dry-run BY DEFAULT

Install

From npm

Claude Code on Windows 11

Claude Code on macOS / Linux

Other MCP clients

Get a Keeping access token

Configuration

⚠ Writes are dry-run BY DEFAULT

Tools

Dry-run workflow (example transcript)

Verifying provenance

Local development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Timesheet MCP Serverofficial

Latest Blog Posts

MCP directory API