Time Management

com.pyuntoPublished by pyunto.comv0.4.0Updated Nov 3, 2026

Read your Pyunto Time Management schedule and log time from an AI assistant. E2EE project planning.

Overview

AI-generated overview

Connects an AI assistant to a Pyunto Time Management account so it can read schedules, summarize logged hours, and record or edit time blocks and Gantt tasks.

What you can do
  • Check the connection: account, key name, granted scopes and whether encrypted names can be decrypted
  • Browse projects and Gantt tasks, resolving names into the ids other tools need
  • Read time blocks for a date range and total hours grouped by project, task or day
  • Log, update and delete individual time blocks, and list or restore recently deleted ones
  • Create, complete, reopen, rename, move or archive tasks, and set monthly hour targets
When to use it
Useful when you want an assistant to answer questions about where your hours went, write work logs or diary entries from tracked time, or log and adjust time entries and plan tasks without opening the app. It fits people already using Pyunto Time Management, including self-hosted instances.
Requirements
Runs locally over stdio, typically via npx with the npm package. Needs an API key in PYUNTO_TM_API_KEY for any data access; listing tools works without one. Optional PYUNTO_TM_BASE_URL for self-hosted instances, and PYUNTO_TM_PASSWORD or PYUNTO_TM_PASSWORD_FILE to decrypt end-to-end-encrypted names and memos. Network access to the Pyunto TM server.
Before you install
The API key is a secret and its scopes decide what the assistant can do; tasks:write is separate from blocks:write, so grant only what is needed. Tools write to the real calendar and plan: log_time, update_time_block, delete_time_block, create_task, update_task, complete_task and set_monthly_target change live data. delete_time_block permanently removes one block and its attachments, restorable only within 14 days. Moving task dates also moves dependent tasks. The account password, if…

Installation

In SourceWeft

  1. Open Time Management in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

@pyunto/tm-mcp

MCP (Model Context Protocol) server for Pyunto Time Management. Connects Claude Code, Claude Desktop, Codex CLI, Cursor and any other MCP client to a Pyunto TM account so an assistant can read the schedule, summarise where the hours went, and log time.

User-facing setup instructions live at https://tm.pyunto.com/docs/mcp.en.md (日本語: https://tm.pyunto.com/docs/mcp.ja.md). This file is the developer view.

Tools

ToolScope
whoami — account, key name, scopes, decryption status—
list_projectsprojects:read
list_tasks (filter by project or by a date the task covers)projects:read
list_time_blocks (range ≤ 92 days)blocks:read
time_summary (grouped by project / task / date)record:read
log_time (writes)blocks:write
update_time_block (writes)blocks:write
delete_time_block — one id, restorable for 14 daysblocks:delete
list_deleted_time_blocks / restore_time_blockblocks:read / blocks:write
create_task — a Gantt task with start and end datestasks:write
complete_task — mark finished, or reopentasks:write
update_task — rename, move dates, archivetasks:write
set_monthly_target — the budget the daily draft divides uptasks:write

Every tool returns JSON as text. Failures come back as isError results whose message names the fix (missing scope, wrong key, locked E2EE) rather than throwing at the transport level — an agent can act on that, a stack trace it cannot.

Install

bash
npx -y @pyunto/tm-mcp        # what an MCP client config runs

Build from source

This package lives in an npm-workspaces repository together with the SDK it depends on; build from the repository root so the workspace link is used:

bash
npm installnpm run build                 # both packagesnpm test                      # sdk crypto round-trips + 25 MCP tool checks

Result: mcp/dist/cli.js, the executable stdio server (dist/index.js stays a side-effect-free module the tests can import).

Configuration

Environment only — MCP clients spawn the process and inject env from their config file.

The server starts without an API key and answers tools/list — a client or a directory can see what it offers before anyone signs up. Calling a tool without one returns the same guidance as an isError rather than an opaque 401, and whoami reports the missing key instead of failing.

VariableRequiredDefaultPurpose
PYUNTO_TM_API_KEYfor data—ptm_…, minted in Settings → Account → API keys. Listing the tools works without it
PYUNTO_TM_BASE_URLhttps://tm.pyunto.comSelf-hosted instances
PYUNTO_TM_PASSWORDnoneUnwraps the private key locally so E2EE names/memos decrypt
PYUNTO_TM_PASSWORD_FILEnoneSame, read from a file instead of the env
json
{  "mcpServers": {    "pyunto-tm": {      "command": "npx",      "args": ["-y", "@pyunto/tm-mcp"],      "env": { "PYUNTO_TM_API_KEY": "ptm_…" }    }  }}

How E2EE is handled

Content fields are encrypted in the user's browser; the server never holds the plaintext, and neither does this process by default. Given a password, the server's password-wrapped private key blob (GET /api/v1/keys, scope keys:read) is unwrapped here, in memory, and used to open each project's sealed DEK. The password is never transmitted and nothing is written to disk.

Without a password the server still answers everything schedule-shaped — ids, dates, times, durations, aggregates — and name fields come back empty with a NOTE: explaining why, so the model reports the limitation instead of inventing names.

Layout

src/index.ts     tool definitions + implementations + server wiringsrc/cli.ts       the bin: calls start()test/tools.mjs   stub /api/v1 server, exercises every tool and error pathtest/cli.mjs     spawns the built bin (directly and via symlink) over real MCP

callTool(name, args) is exported for tests; start() attaches the transport and is called only by cli.ts.

delete_time_block is deliberately single-id: no range or filter delete is exposed, because an automated caller getting a range wrong destroys an unbounded amount of data that has no restore path. Its tool description requires the model to show the user the exact block first and get a yes for that block.

There is no delete_task for the same reason, and a sharper one: removing a task detaches every block that logged time against it (tasks.id ON DELETE SET NULL) and orphans its subtasks, with nothing to restore from. update_task offers archive instead — the task leaves every view and can be brought back.

tasks:write is separate from blocks:write on purpose. Recording time against a plan and rewriting the plan are different powers; a key given to something that only logs work should not be able to move deadlines.

update_task returns an array. Moving a task's dates drags its dependents along, and the caller is told what else moved rather than discovering it on the next read.

Source: mcp/README.md at commit 6add94b

Tools

14

whoami

Who this MCP server is connected as: account email, API key name, granted scopes, server URL, and whether end-to-end-encrypted names can be decrypted. Call this first when a tool fails, to see which scopes are missing.

Takes no parameters.

list_projects

List every project the account can see, with id, name, colour and role (owner/editor/viewer). Use it to resolve a project name the user typed into the project_id other tools need. Requires the projects:read scope.

Takes no parameters.

list_tasks

List Gantt tasks (and subtasks) with their id, project, name and date range. Filter to one project with project_id. Use it to resolve a task name into the task_id that log_time takes. Requires the projects:read scope.

Parametersactive_onproject_id

list_time_blocks

The individual time blocks logged between two dates (inclusive, max 92 days), with start/end times, duration, project, task and memo. This is the detailed schedule; use time_summary when you only need totals. Requires blocks:read.

Parametersdate_torequireddate_fromrequired

time_summary

Total hours logged between two dates (inclusive, max 92 days), grouped by project, by task, or by day. This is the tool to answer 'how much time did I spend on X' and to write a work log or diary entry. Requires record:read.

Parametersdate_torequiredgroup_bydate_fromrequired

log_time

Record a block of worked time on the calendar. Writes to the user's real schedule, so confirm the project, date and times with them before calling it. Requires the blocks:write scope; for an end-to-end-encrypted project a memo additionally needs PYUNTO_TM_PASSWORD so it can be encrypted locally.

Parametersendrequireddaterequiredmemostartrequiredtask_idproject_idrequired

update_time_block

Change an already-recorded time block: its date, start/end times, memo, or the task it counts towards. Get block_id from list_time_blocks. Only the fields you pass change. Tell the user what the block currently says and what it will say before calling this. Requires the blocks:write scope; changing a memo on an end-to-end-encrypted project also needs PYUNTO_TM_PASSWORD, and project_id so the memo is encrypted under the right key.

Parametersenddatememostarttask_idblock_idrequiredproject_id

delete_time_block

Permanently delete ONE recorded time block, along with any files attached to it. Before calling it you MUST show the user the block you are about to delete (date, start and end time, project, task and memo, from list_time_blocks) and get an explicit yes for that specific block. Never infer the block from a vague instruction, and never delete several blocks because the user described a range — confirm and delete them one at a time. A deleted block can be put back with restore_time_block for 14 days, after which it and its attachments are purged for good and cannot be recovered; say so when you report the deletion, and do not tell the user the deletion is irreversible. Requires the blocks:delete scope, which is separate from blocks:write and has to be granted deliberately.

Parametersblock_idrequired

list_deleted_time_blocks

Time blocks that were deleted but can still be restored, newest first, each with the date it was deleted and the deadline for putting it back. Use it to find the block_id for restore_time_block when the user says they deleted something by mistake. Requires the blocks:read scope.

Takes no parameters.

restore_time_block

Put a deleted time block back on the calendar, along with any files that were attached to it. Get block_id from list_deleted_time_blocks. Works only within the 14-day recovery window; after that the block is gone for good. Requires the blocks:write scope.

Parametersblock_idrequired

create_task

Add a task to the Gantt chart — a piece of work with a start and end date, which is what time blocks are later logged against. Use this for work that spans days or longer; for time already worked use log_time instead. Writes to the user's real plan, so confirm the project, name and dates with them first. Requires the tasks:write scope; an end-to-end-encrypted project also needs PYUNTO_TM_PASSWORD so the name can be encrypted locally.

Parametersnamerequiredend_daterequiredproject_idrequiredstart_daterequiredparent_task_id

complete_task

Mark a Gantt task finished, or reopen it. The task stays on the chart, drawn dimmed — nothing is deleted. This is how a finished piece of work shows up on the plan. Get task_id from list_tasks. Requires the tasks:write scope.

Parameterstask_idrequiredcompleted

update_task

Change a task's name, dates, or whether it is archived. Only the fields you pass change. Moving the dates also moves every task that depends on this one, and the reply lists everything that moved — tell the user about those too. Archiving hides a task from every view and is reversible; there is deliberately no way to delete a task through this server, because that would detach the time already logged against it. Requires the tasks:write scope; renaming an end-to-end-encrypted project's task also needs PYUNTO_TM_PASSWORD.

Parametersnametask_idrequiredarchivedend_datestart_date

set_monthly_target

Set how many hours a task should get in one calendar month. This is what the daily draft (the ✨ button) divides across the month's remaining workdays — a task with no target is skipped entirely, which is the usual reason the draft produces nothing. Requires the tasks:write scope.

Parametershoursrequiredtask_idrequiredyear_monthrequired

Version history

3
  1. v0.4.0LatestNov 1, 2026
  2. v0.3.6Oct 18, 2026
  3. v0.3.5Sep 29, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts