← eHourCONTENT HISTORY
WHAT CHANGED
Update to eHour
Snapshot Oct 24, 2026 · 13:33 UTC · version 1.0.0
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save eHour and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Log, correct, or move time entries and start or stop timers in eHour. Use when the user asks to record or reassign work in their connected eHour account.",
"included_files": [],
"name": "track-time",
"skill_md_contents": "---\nname: track-time\ndescription: Log, correct, or move time entries and start or stop timers in eHour. Use when the user asks to record or reassign work in their connected eHour account.\n---\n\n# Track time in eHour\n\nUse the connected eHour MCP tools. Names below are the server's canonical names;\nthe host may namespace them. Inspect the live tool schemas before calling them.\nIf the connection or required tool is missing, ask the user to connect eHour.\nDo not substitute a local file or claim that time was saved.\n\n## Log or correct time\n\n1. Establish the date, duration, and assignment. Use ISO dates and decimal hours\n (90 minutes is 1.5 hours). Resolve relative dates using known user context;\n ask when the date or timezone is ambiguous. Do not infer hours from meetings\n or other activity unless the user requested that workflow.\n2. Resolve the assignment with `getAssignments` for the current user, or\n `listAssignments` for an explicitly requested other user. `trackTime` also\n accepts project code or name, narrowed by task and client. Reuse returned\n prefixed IDs; a project ID is not an assignment ID. Ask the user to choose\n when the server returns disambiguation candidates. Keep prefixed IDs internal\n and refer to projects by name, code, and task in user-facing replies unless\n the user explicitly asks for technical identifiers.\n3. Use `addTime` for an explicit increment or reduction such as “add another\n hour” or “subtract 30 minutes.” It appends one signed adjustment and preserves\n existing detail rows, comments, tags, sources, and time windows. Generate a\n UUID `operationId` once for each logical adjustment and reuse that same UUID\n if the call must be retried; do not generate a new ID for a retry. Use\n `trackTime` when the user specifies the desired assignment total for the day.\n Clarify “log two hours” when replacement versus addition is unclear.\n4. Read `getTimesheet` before replacing an existing total with `trackTime`.\n Omitted comments can affect existing comments; preserve the intended comment\n and ask if merging multiple comments is unclear. `hours: 0` deletes the\n assignment's time for that date, including its entry details; use it only\n when deletion is explicitly intended. Never use zero as a placeholder.\n5. Report the returned result, date, assignment, and hours. A tool error is not\n success. After a timeout or uncertain write, reuse `addTime`'s operation ID\n for the retry. Read the timesheet before retrying other write tools.\n\nAct on behalf of another person only when explicitly requested. Pass that same\nuser identity to both reads and writes. The server decides management access;\ndo not switch identities or use another API to work around a denial.\n\n`trackTime` can collapse detailed time rows and discard their tags or start/stop windows.\nA daily total does not prove that there are no such details.\nIf preserving detailed entries is required, explain this limitation and use the eHour interface instead of claiming the tool will preserve them.\nBefore replacing known detailed entries, make the loss of detail clear and obtain the user's agreement.\n\n## Move time between assignments\n\nUse `moveTimeEntries` to move existing entries between two assignments for the\nsame user. Resolve both assignments and prefer an explicit inclusive date\nrange. If the intended scope is unclear, ask which dates to move before calling;\n\"move my hours from A to B\" does not by itself mean all recorded history.\n\nOmitting either date leaves that side unbounded. Omitting both moves every\nrecorded entry from the source assignment. Before an unbounded move, explain\nthat scope, identify the source and target assignments and whose entries will\nmove, and obtain the user's confirmation. Preserve an explicit request to move\nall entries; do not invent a cutoff or silently move only a recent period.\n\nReport the returned entry count, hours, and effective dates. Do not fetch the\nentire timesheet history just to prepare the move or invent preview totals.\nThe move is atomic: surface locked dates and other errors without silently\nsplitting the operation to move only the entries that succeed.\n\n## Timers\n\nOnly one timer can run for a user. `startTimer` returns an `action` of `started`,\n`already_running`, or `assignment_attached`; use that value instead of claiming\nthat every call started a new timer. It can store an optional comment. Do not\nsilently stop an existing timer to switch projects.\n\nFor a simple request such as \"start my timer\", call `startTimer` immediately\nwith no assignment arguments. Do not first call `getTimerStatus` or\n`getAssignments`: `startTimer` safely returns the existing timer without\nresetting it, and the server permits a newly started timer to remain unassigned.\nWhen the user supplies a project code, project name, or assignment ID, pass it\ndirectly to `startTimer`; the server resolves it. Call `getAssignments` only\nafter resolution fails or remains ambiguous. Use `getTimerStatus` only when the\nuser asks for timer status or elapsed time, or to recover from an uncertain\nwrite result.\n\nUse `updateTimer` to correct the running timer's project, task, or comment\nwithout resetting its start time. Omitted assignment and comment fields are\npreserved; an explicitly empty comment clears the comment. A task name supplied\nwithout a project is resolved within the running timer's current project.\n\n`stopTimer` records elapsed time. A timer may have no assignment; resolve one\nbefore stopping in that case. An omitted stop comment reuses the timer's stored\ncomment. Ask for any required comment. Use the duration\nreturned by the tool, not a guessed elapsed time. After an uncertain stop, check\nboth timer status and the relevant timesheet before retrying.\n\n`discardTimer` cancels the running timer and permanently discards its elapsed\ntime without creating a timesheet entry. Use it only when the user explicitly\nasks to cancel, discard, or stop without saving. Do not substitute it for\n`stopTimer`. Report the discarded project and duration returned by the tool.\n\nLocked dates, budget limits, required tags/comments, and missing permissions\nmust be resolved through supported eHour behavior. Do not fabricate a tag,\nunlock a date, or change a budget to make the time entry succeed.\n"
}SHA-256 of public snapshot: 142cf32350494ff2e34bb4e7e0e83e60aa60988628063e5eabdf0b0539fa456a