Skip to main content
Glama

commonly_log_cycle

Append a one-line takeaway to this agent’s cycle memory once per heartbeat to record decisions and observations; entries are append-only and kept in a rolling 40-entry window.

Instructions

ADR-012 Phase 2: append a one-line takeaway to this agent's cycles[] memory. THIS is the only tool that writes cycles — commonly_save_my_memory cannot (it rejects the section as append-only). Append-only; the kernel rejects whole-array overwrites. Use this once per heartbeat to record what happened (decisions, observations, anything you'd want to remember next time). Past entries surface back via the event payload cyclesDigest field. Two caps, both enforced server-side and both REPORTED in the response rather than applied silently: content over 500 chars is truncated with an ellipsis (truncated: true + storedChars/submittedChars), and the section keeps only the 40 most recent entries, so an append past that evicts the oldest (evicted: true + retainedEntries/entryCap). Both flags are ALWAYS present, including as false — so a MISSING truncated/evicted does not mean "nothing was cut", it means you are talking to a backend that predates this reporting and cannot tell you either way. This description ships on npm and the backend ships on a deploy, so the two can be on different clocks; check for the field, then check its value. Cycle memory is a rolling window, not an archive — at one entry per heartbeat the horizon is hours, so put anything durable in long_term via commonly_save_my_memory.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "commonly_log_cycle"
  }
}

Input Schema

NameRequiredDescriptionDefault
podIdNo
contentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.16

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden, and it does: append-only enforcement by the kernel, a 500-char truncation with reported `truncated`/`storedChars`/`submittedChars`, a 40-entry eviction cap with `evicted`/`retainedEntries`/`entryCap`, and the non-obvious rule that the flags are always present as booleans so a missing field signals an older backend rather than 'nothing cut'. That last point is exactly the kind of behavioral detail no schema can express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Well front-loaded — purpose first, caps second, caveat last — but the middle section restates the same idea twice ('both REPORTED in the response rather than applied silently', then the flag enumeration) and the npm-vs-deploy clock paragraph is a verbose way to say 'verify both the field's presence and its value'. The density is justified by substance, but several sentences could be tightened without information loss.

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

Completeness4/5

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

With no annotations and no output schema, the description must supply both the safety profile and the return shape, and it does name every response field an agent needs (`truncated`, `storedChars`, `submittedChars`, `evicted`, `retainedEntries`, `entryCap`, plus `cyclesDigest` in the event payload). The one real omission is `podId`, which leaves a small but genuine gap in an otherwise self-sufficient definition.

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 0%, so the description must compensate and it half does: it thoroughly characterizes `content` (500-char cap, truncation behavior) but never mentions `podId` at all — an agent must infer whether it is required, what it defaults to, or when to set it. Given only two parameters and the required one thoroughly covered, this is adequate rather than complete.

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?

States a precise verb and resource: 'append a one-line takeaway to this agent's `cycles[]` memory'. It immediately distinguishes itself from the nearest sibling by asserting 'THIS is the only tool that writes `cycles` — commonly_save_my_memory cannot', so an agent can route correctly without opening either schema.

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?

Gives an explicit cadence ('once per heartbeat'), an explicit exclusion (commonly_save_my_memory rejects the section as append-only), and an explicit redirect for the case this tool does not fit ('put anything durable in `long_term` via commonly_save_my_memory'). It also frames the tradeoff — rolling window vs archive — that drives the routing decision.

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