Skip to main content
Glama
rtdesignstudio

cemainou

by rtdesignstudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Edit Update Tool

edit_update

Correct an already-sent daily update—summary, lines, time, day, or move lines to the day done—or delete one sent by mistake; every change is saved with a reason.

Instructions

Corrects an update already sent (or deletes one sent twice or by mistake, with delete): its summary, its lines (done, doing, blocked, next, decisions), its time, its day, or moves some lines to the day they were really done (split). Every change is kept in the update's history with your reason, so give a real one (e.g. "the gallery was done on 6 Oct, per the commits"). Only the author or an admin; only after the person agreed to the correction. Never send a second update to fix one: correct it.

Input Schema

NameRequiredDescriptionDefault
dateNoMove the whole update to this day (YYYY-MM-DD); its time becomes what was measured that day.
doneNoCorrected done lines. Replaces the lines of this kind written without a task; lines tied to tasks stay.
nextNoCorrected next lines. Replaces the lines of this kind written without a task; lines tied to tasks stay.
repoNoThe git remotes of the working directory, to find your last update here.
agentNoThe agent writing this: claude-code, codex, cursor.
doingNoCorrected in-progress lines. Replaces the lines of this kind written without a task; lines tied to tasks stay.
splitNoMove some lines to the day they were done: into that day's update, created if missing.
deleteNoDeletes the whole update, with its lines and time: only for one sent twice or by mistake, never to correct it (correct it instead). Only after the person confirmed.
reasonYesWhy, in one sentence the team understands, e.g. "date correction: the work was done on 6 Oct, per the commits".
updateNoThe update's number. Leave it out for your last update on this session's project.
blockedNoCorrected blocked lines. Replaces the lines of this kind written without a task; lines tied to tasks stay.
minutesNoCorrected time, only if the person gives it.
projectNoProject slug or name, if not this session's.
sessionNoThis session's id, from the cemainou line at the start of the session. The session's project wins over the repo.
summaryNoA corrected summary.
decisionsNoCorrected decisions. Replaces the lines of this kind written without a task; lines tied to tasks stay.
move_to_projectNoThe project (slug or name) the update really belongs to, when it was reported on the wrong one. Its notes and estimated time go with it; lines linked to tasks of the old project stay as text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses authorization limits, the need for consent, that delete is only for duplicates/mistakes, and that every change is kept in history with the reason. It also explains the required reason with an example.

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 purpose is front-loaded, and each sentence adds operative information: correction scope, history/reason requirement, authorization, and the rule against a second update. There is no filler.

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 the 17-parameter mutation surface, empty annotations, and no output schema, the description supplies the critical behavioral context: authorization, consent, delete semantics, history, and correction vs duplicate-creation. The schema already documents all parameters in detail, so the description is complete enough for correct selection and invocation.

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 description coverage is 100%, so the baseline is 3. The description adds useful grouping and meaning beyond the schema by mapping corrections to summary, line kinds, time, day, split, and delete, though it does not add much for the target-selection 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?

The description uses a specific verb and resource: it corrects or deletes an already-sent update, enumerating what can be changed (summary, lines, time, day, split). It also distinguishes correction from creating a new update with 'Never send a second update to fix one: correct it.'

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?

It gives explicit when-to-use guidance: correct an update already sent, delete only if sent twice or by mistake, never send a second update. It also states preconditions clearly: only the author or admin, and only after the person agreed to the correction.

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

Deploy Server

Other Tools