Skip to main content
Glama

Log Update Tool

log_update

Records a confirmed status update covering completed work, in-progress items, blockers, next steps, and decisions so team progress is captured clearly.

Instructions

Saves a status update: what was done since the last update, what is in progress, blockers, next steps and decisions. Call it ONLY after the person has seen the draft and confirmed it. Short, outcome-focused lines; never secrets, credentials, personal data or code.

Input Schema

NameRequiredDescriptionDefault
gitNoThat day's commits and lines, from git log --numstat (see next_steps). Only for work in a git repo.
dateNoThe day of the main update, YYYY-MM-DD, only if the latest day worked was not today. Any day from last_update's oldest_day on (the team's reporting window, often months), not only the last two weeks.
daysNoEarlier days, when the work since the last update spans several days (see days_worked, unreported_days and the commit dates): one entry per day, each saved on its day with the time measured for it, back to oldest_day (the window the admin set, often months), all in one call. The latest day goes in the main fields.
doneNoWhat was finished since the last update.
nextNoOptional: only what the person planned or said comes next, never suggestions or ideas of the agent.
repoNoThe output of git remote -v in the working directory (all remotes; one URL also works). Preferred: it finds the project by itself.
agentNoThe agent writing this: claude-code, codex, cursor.
doingNoWhat is still in progress. The first line becomes the person's current focus.
focusNoWhat the person is focused on now, if different from the first "doing" line.
linksNoCommit hashes, pull request or page URLs.
notesNoWhat colleagues should know about this project (access, a convention, a gotcha; never secrets), if the person said so. Needs a project.
blockedNoOptional: only what is stuck right now and on whom or what it waits; not risks or nice-to-haves.
commitsNoThe commits in this update's git log whose message mentions a task number (#12, fixes #12): they show on that task's page. Only those; the server ignores numbers that are not tasks of this project.
minutesNoOnly if the person corrected the measured time of the day.
projectNoProject slug or name, when there is no repo or it is not linked. Leave both empty for work outside any project.
sessionNoThis session's id, from the cemainou line at the start of the session. The session's project wins over the repo.
summaryYesOne sentence a colleague understands without context: what changed for the project.
untimedNoEstimated time for days reported earlier with no time at all (untimed_days in last_update). Only the time is added, to that day's update; a day that already has time is skipped.
internalNotrue if the client must not see this update (only on projects visible to the client; see client_sees_updates in last_update).
separateNoOnly if the person explicitly wants a second, separate update for a day that already has one. By default, work on a day that already has an update (today_update in last_update, from another session) is added to it: new lines appended, summary replaced by yours (write it for the whole day).
decisionsNoDecisions taken, worth remembering.
new_tasksNoTitles of new tasks for the person, from "next" lines they agreed to turn into tasks. Needs a project.
next_doneNoIds from open_next (last_update) that this work finished: each becomes a done line.
started_atNoWhen the work started today, ISO 8601. Optional: by default the server knows it from the first agent session of the day.
period_fromNoStart of the period covered, ISO 8601. Optional: by default the previous update.
next_droppedNoIds from open_next that will not be done any more: they disappear from today's update.
task_changesNoTasks this update moves (from my_open_tasks): done, still doing, blocked, dropped. Their lines are added automatically; do not repeat them in done / doing.
blocked_resolvedNoIds from open_blockers (last_update) that are not blocked any more: they leave the blockers. Do not repeat them in blocked.
estimated_minutesNoOnly for a day without measured time (see days_worked / unreported_days): the time estimated from the commit times, confirmed by the person. Kept apart from measured hours; ignored if the day has measured time.
decisions_to_contextNotrue if the person agreed to add this update's decisions to the project context (/ctx): each becomes a dated line under Decisions; the rest of the context is not touched, decisions already there are skipped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the confirmation gate and the prohibition on secrets/credentials/personal data/code, but it omits side effects such as merging into an existing day's update, internal/client visibility, and task/time side effects.

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 the action and scope, then the confirmation and privacy constraints. No filler or repetition.

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

Completeness3/5

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

The schema is rich and covers the many parameters, but the description is thin for a 30-parameter mutation tool with no annotations or output schema. It covers the key confirmation gate but not broader workflow relationships to siblings such as edit_update, last_update, or task/time handling.

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 description coverage is 100%, so all 30 parameters are already documented in the schema. The description adds only general content categories, not parameter-level semantics; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Saves') and resource ('status update'), plus the scope ('since the last update') and content categories. It is clear, but it does not explicitly distinguish itself from edit_update or comment_update.

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?

Gives an explicit gating condition: 'Call it ONLY after the person has seen the draft and confirmed it.' This is clear usage context, but there is no when-not guidance or alternative-tool routing for editing or commenting.

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