Skip to main content
Glama

log_event

Log progress events like goals, decisions, and next steps to preserve context for future sessions. Each event is atomic and concise, ensuring the brief stays skimmable and linked to related knowledge.

Instructions

Record a progress signal for the current work session.

Call this proactively as work happens — every time you set or change the goal, make a non-trivial decision (and why), hit a dead-end worth not repeating, touch an important file, surface an open question, or decide the next step.

Keep each event ATOMIC and concise: one item per call, 1-2 sentences. Log several small events rather than dumping a whole session summary into one — the brief is meant to stay skimmable. Reference durable notes inline as [[Entity]] so they link in the brief's "Related knowledge".

This is how the next session inherits your context. Returns the new event id (use it later in supersedes). If supersedes_query retired a prior event, a second line names which id was retired (or notes that none matched), so the retraction is auditable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesOne of: 'goal' (what this session is achieving), 'decision' (a choice made — include the rationale), 'deadend' (something tried that failed — so it isn't repeated), 'file' (a file touched or relevant), 'question' (an open question), 'next_step' (the concrete next action).
contentYesOne atomic item in 1-2 sentences (a decision + its why, a single dead-end, one next step) — not a multi-paragraph session summary. Reference durable notes inline as [[Entity]] to link the graph.
projectNoProject namespace; defaults to the current session's project.
importanceNoPriority 1-5 (5 = critical). Higher items survive the brief budget.
supersedesNoIds of earlier events this one makes obsolete (e.g. a reversed decision). Superseded events are excluded from future briefs.
supersedes_queryNoRetire a prior event you don't have the id for: the single best-matching ACTIVE event of the SAME type in this project is found by keyword search and superseded. Use when you change a past decision but don't know its id. The retired id is reported back and recorded, so it stays auditable.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations indicate a non-read-only, non-idempotent, non-destructive tool. The description adds behavioral context beyond annotations: it returns the new event id, and if 'supersedes_query' is used, it reports which prior event was retired. It also notes that superseded events are excluded from future briefs, providing transparency about 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long (200+ words) but well-structured into paragraphs that front-load the purpose and then detail usage guidelines and return behavior. Every sentence adds value, though some minor redundancy could be trimmed.

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 tool's complexity (6 parameters, 2 required, output schema), the description fully covers when to use, how to use (atomic, concise, inline links), return values (event id, optional retirement note), and the lifecycle of events (superseding, budget filtering). No gaps identified.

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%, with each parameter well-described. The description adds high-level guidance beyond schema: e.g., 'atomic and concise', 'reference durable notes inline as [[Entity]]', and explains the interplay between 'supersedes' and 'supersedes_query'. This extra context justifies a score above the baseline 3.

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 clearly states the tool's purpose: 'Record a progress signal for the current work session.' It specifies the verb 'Record' and the resource 'progress signal', and distinguishes from sibling tools like 'checkpoint' and 'note_entity' by detailing the exact types of events to log (goal, decision, dead-end, etc.).

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?

The description provides extensive guidance on when to use: 'proactively as work happens' with specific triggers (goal changes, decisions, dead-ends, file touches, questions, next steps). It also explicitly advises how to NOT use the tool: 'Keep each event ATOMIC and concise', 'not a multi-paragraph session summary'. This helps the agent decide between this tool and others.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kirill-sviridov/handoff-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server