Skip to main content
Glama
Sign In
Fmarzochi

EGC

by Fmarzochi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

update_state

Saves session decisions, preferences, next steps, and pitfalls to project memory at session end, merging with existing branch state to preserve context across resets.

Instructions

Updates the project memory with decisions made this session. Writes to the state file of the current git branch when the project is a git repository, or to that exact commit's own state file on a detached HEAD. Call this at the END of every session. Merges with existing state and does not erase previous memory.

Input Schema

NameRequiredDescriptionDefault
nextNoWhat to pick up in the next session.
avoidNoWhat failed and should not be repeated.
forceNoRecover from a state file that cannot be decrypted (corrupted or encrypted with an orphaned key). When true and the existing file fails to decrypt, the corrupted file is renamed to a '.corrupted-backup-<timestamp>' sibling instead of being read, and this call's data becomes the fresh state -- nothing is merged in from the unreadable file, and nothing is deleted. Only set this after confirming the failure is persistent, not a transient lock from another process writing at the same moment.
scopeNoWhere to write. 'project' (default) scopes to the current project/branch. 'global' writes to the user-wide memory shared across all projects (~/.egc/global/state.md); use it only for transversal preferences and lessons the user wants everywhere, never for project-specific state.
contextNoWhat this project is and its current phase.
decisionsNoDecisions made this session.
preferencesNoCoding style, workflow, or communication preferences discovered.
project_pathNoAbsolute path to the project root (or worktree) to scope this state to. Always pass this explicitly when calling from an agent or worktree that is not the caller's own working directory -- an omitted value falls back to this process's cwd, which can silently resolve to the wrong project/branch and collide with another process's state file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.23
    • changedInput schema / properties / force / description
      Previous value: -"Recover from a state file that cannot be decrypted (corrupted or encrypted with an orphaned key). When true and the existing file fails to decrypt, the corrupted file is renamed to a '.corrupted-backup-<timestamp>' sibling instead of being read, and this call's data becomes the fresh state — nothing is merged in from the unreadable file, and nothing is deleted. Only set this after confirming the failure is persistent, not a transient lock from another process writing at the same moment."New value: +"Recover from a state file that cannot be decrypted (corrupted or encrypted with an orphaned key). When true and the existing file fails to decrypt, the corrupted file is renamed to a '.corrupted-backup-<timestamp>' sibling instead of being read, and this call's data becomes the fresh state -- nothing is merged in from the unreadable file, and nothing is deleted. Only set this after confirming the failure is persistent, not a transient lock from another process writing at the same moment."
    • changedInput schema / properties / project_path / description
      Previous value: -"Absolute path to the project root (or worktree) to scope this state to. Always pass this explicitly when calling from an agent or worktree that is not the caller's own working directory — an omitted value falls back to this process's cwd, which can silently resolve to the wrong project/branch and collide with another process's state file."New value: +"Absolute path to the project root (or worktree) to scope this state to. Always pass this explicitly when calling from an agent or worktree that is not the caller's own working directory -- an omitted value falls back to this process's cwd, which can silently resolve to the wrong project/branch and collide with another process's state file."
  2. Addedv1.1.20
  3. Removedv1.1.16
  4. Addedv1.1.14
  5. Removedv1.1.12
  6. Changed2 schema fields changedv1.1.10
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Recover from a state file that cannot be decrypted (corrupted or encrypted with an orphaned key). When true and the existing file fails to decrypt, the corrupted file is renamed to a '.corrupted-backup-<timestamp>' sibling instead of being read, and this call's data becomes the fresh state — nothing is merged in from the unreadable file, and nothing is deleted. Only set this after confirming the failure is persistent, not a transient lock from another process writing at the same moment.",
+  "type": "boolean"
+}
    • addedInput schema / properties / project_path / description
      Added value: +"Absolute path to the project root (or worktree) to scope this state to. Always pass this explicitly when calling from an agent or worktree that is not the caller's own working directory — an omitted value falls back to this process's cwd, which can silently resolve to the wrong project/branch and collide with another process's state file."
  7. First observedv1.0.2

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the merge semantics ("does not erase previous memory"), the path-resolution rule for branch vs detached HEAD, and precisely what force does (rename to '.corrupted-backup-<timestamp>', nothing merged, nothing deleted). It stops short of stating failure behavior for non-corruption errors or what the call returns on a conflicted write.

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?

Four sentences, front-loaded with purpose, then write target, then timing, then merge guarantee. Each sentence carries information; only the merge guarantee reads slightly redundant with the opening line.

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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the things that would actually cause mistakes: where the write lands, that it merges rather than replaces, when to call it, and the safe recovery path. Nothing an agent needs to invoke it correctly is missing.

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 the schema already explains scope, force, project_path and the structured fields; baseline is 3. The description adds only the temporal framing ("decisions made this session") on top of that, and says nothing about next/avoid/preferences/context beyond what the schema provides.

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 and resource ("Updates the project memory with decisions made this session") and immediately pins down the write target: branch state file, or the commit's own state file on detached HEAD. That distinguishes it from a plain single-decision writer, though it never names the sibling it is not (e.g. store_decision), so an agent must infer the split.

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?

"Call this at the END of every session" gives an explicit trigger, and the merge-vs-force guidance says when force is and isn't appropriate ("only set this after confirming the failure is persistent, not a transient lock"). It lacks any explicit routing to alternatives among the many sibling state/decision tools.

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