Skip to main content
Glama

AccountHub

by ai.accounthub
OverviewDiscussionsAdmin

add_memory

Record what was done / learned / DECIDED so the user's OTHER AI assistants (terminal Claude Code, claude.ai, ChatGPT) can see it — a shared cross-assistant journal. Set source to who you are ('claude-web' when you are claude.ai, 'chatgpt' when you are ChatGPT, 'terminal' for local Claude Code). When the entry came from one connected account's work (mail, Slack, calendar, Drive), pass account (a label from list_accounts) — its belongs_to is applied automatically; set belongs_to yourself (a name from list_accounts belongs_to_options; leave it out if unsure) only when the entry is not from any one account's work. Set visibility when it is not for the owner's eyes only, and confidence for profile entries and anything about a person.

WRITE AT THE MOMENT OF DECISION — not at the end of the conversation (a chat has no end). The moment the user decides something (「〜にしよう」「〜で行く」「それで決定」「やめる」), write one kind: 'decision' entry. Template: 「決定: … ／ 理由: … ／ 捨てた案: … ／ いつまで: …」. If that decision overrides or corrects an earlier entry, pass supersedes: [id] (the id from search_memory / get_memory_digest) — then there is ONE current answer instead of two contradicting ones.

CORRECTIONS: when you find that an entry you read is outdated or wrong (「実はマージ済み」「以前の記録より正しいのは…」), do NOT just append a second entry — write the corrected entry with supersedes: [the old id]. To retract without a replacement, write 「取り消し: … 理由: …」 with supersedes. Nothing is ever deleted; the old entry stays in history.

SHARED-MEMORY ADMISSION RULE — this journal is NOT a work log. Another assistant reads it top-to-bottom later; write to it only what that assistant would otherwise be materially more likely to get wrong. Ask yourself: "Would another assistant be materially more likely to make a wrong decision without this information?" If not, do not write it.

Write a normal entry for:

  1. decision — a policy/spec/operating rule was decided

  2. a material state change — implementation / merge / deploy / send / configuration change / production update actually happened

  3. learning — a reusable insight that should change future implementation or judgment

  4. a meaningful handoff — you are stopping mid-task and another assistant needs to know where things stand to continue

  5. profile — a durable fact or standing rule about the user (set confidence)

Do NOT write, as a rule: starting an investigation, having read some files, having run a test once, CI going green, a small in-progress step, "I will do X next", "nothing changed", or any checkpoint/processed-id/retry-count/run-count/scheduled-job bookkeeping — those stay operational: true (unchanged from before).

Standard granularity per session (a guideline, not a hard limit): usually at most 1 activity session digest, 1 decision per decision made, 1 learning if one is worth keeping — roughly 1-3 entries total. Prefer one consolidated entry over a fine-grained timeline.

RUN STATE (scheduled routines): for a piece of state you name and keep updating yourself — a ticket's status, a monitor's progress — give it a stable memory_key and pass replace_previous: true on each update. For timestamped snapshots, always pass RFC 3339 observed_at; an older observation is rejected even if it finishes later. To add references without advancing the observation time, first read the current row and pass its id as expected_current_id; on conflict, reread and merge. For everything else, prefer supersedes.

Also call this whenever the user says 記録して / メモして / 他のアシスタントにも共有して. The result carries the entry's id and belongs_to; a note tells you if something was adjusted (e.g. belongs_to overridden by the account's label).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoEntry type: 'activity' (何をやったか, default) | 'learning' (学び・知見) | 'decision' (決定事項) | 'profile' (ユーザーについての情報).
tagsNoFreeform tags, e.g. project names.
sourceNoWho is writing: 'terminal' (local Claude Code), 'claude-web' (claude.ai), 'chatgpt', or 'other'. Set this to who YOU are.
accountNoThe connected account (a label from list_accounts) whose mail / Slack / calendar work this entry came from. PASS THIS FIRST whenever the entry came out of one account's messages, events or files: that account's `belongs_to` is applied automatically and wins over `belongs_to`.
contentYesWhat to record — anything from a one-line note to a long daily digest.
belongs_toNoOnly for an entry that is NOT from any one connected account's work — otherwise pass `account` and the label is filed automatically. A NAME from `belongs_to_options` in list_accounts (or get_memory_digest): the labels are the user's own (a company, a project, 'プライベート'…); choose from that closed list, never invent one — an unknown name is refused with the valid list. If you are not sure, leave it out (the entry stays unfiled and the user sorts it later).
confidenceNoHow sure you are: 'verified' (checked against a primary source — put it in source_reference), 'reported' (someone said so / second-hand / another assistant's memory), 'inferred' (your own inference). ALWAYS set it for `profile` entries and for anything stated about a person. Omit only when it genuinely does not apply. Readers keep reported/inferred claims out of text addressed to third parties.
memory_keyNoStable canonical key for a piece of CURRENT STATE this entry is about, e.g. 'accounthub/reddit/RD-E2E-1' or 'socialgist/slack-monitoring-policy'. Use the SAME memory_key every time you update that same topic's state, so a later reader can find 'the current state of X' instead of picking an old row. Required when replace_previous is true; omit for an ordinary one-off entry.
supersedesNoids of entries THIS entry corrects, confirms or retracts — take them from the `id` field of search_memory / get_memory_digest results. Each is flagged superseded (never deleted; history keeps it, with superseded_by pointing here) and stops appearing as current. Use it whenever you read an entry that is now outdated or wrong: a correction (「実はマージ済みだった」), a decision that overrides an earlier one, or a retraction (content 「取り消し: … 理由: …」). No stable key needed. Only this user's CURRENT entries: if an id was already superseded by someone else, nothing is written and the error names the current successor — read it and supersede THAT id if it is still wrong. Retrying the exact same write is safe (it returns the existing entry with replayed: true).
visibilityNoWho may ever read this: 'private_self' (default — only the owner), 'shared_1on1' (the other party sees it too), 'company' (team-wide), 'hr_private' (evaluation/compensation/contracts — stored, never auto-sent). When in doubt leave it out; the default is the safe one.
observed_atNoRFC 3339 source observation time for timestamped CURRENT STATE, including Z or an offset. Pass this with memory_key + replace_previous for snapshots. Older observations are rejected atomically even if their requests finish later. For legacy CURRENT_UNRESOLVED_SNAPSHOT content it is also derived from a strict ISO checked_at line.
occurred_onNoYYYY-MM-DD the entry is about. Omit for today.
operationalNoSet true ONLY for bookkeeping a scheduled job has to persist (checkpoints, processed message ids, "nothing new", retry counts). Such entries are kept out of the journal reads. Do NOT use it for anything a human would want to recall.
replace_previousNoSet true when this entry REPLACES the current state of memory_key (e.g. a task moved from in-progress to done, or a decision superseded an earlier one). The previous current entry for that memory_key is flagged superseded — never deleted, still visible via include_superseded — and this new entry becomes the one normal reads return. Requires memory_key. Default false (ordinary append-only write, unchanged behavior).
source_referenceNoWhere this came from — Slack permalink, Otter URL, thread id. Keep full text in the source system and put the pointer here.
expected_current_idNoCompare-and-swap token: the current memory id you read before changing content without advancing observed_at (for example adding source/task references). Required for same-observation enrichment. On conflict, read the new current row, merge, and retry with its id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / expected_current_id
      Added value: +{
+  "description": "Compare-and-swap token: the current memory id you read before changing content without advancing observed_at (for example adding source/task references). Required for same-observation enrichment. On conflict, read the new current row, merge, and retry with its id.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}
    • addedInput schema / properties / observed_at
      Added value: +{
+  "description": "RFC 3339 source observation time for timestamped CURRENT STATE, including Z or an offset. Pass this with memory_key + replace_previous for snapshots. Older observations are rejected atomically even if their requests finish later. For legacy CURRENT_UNRESOLVED_SNAPSHOT content it is also derived from a strict ISO checked_at line.",
+  "format": "date-time",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply destructiveHint=false and a title, so the description carries the real behavioral load and does so: nothing is ever deleted, superseded entries remain in history, retrying an identical write is safe (replayed: true), a conflict names the current successor, and list_accounts' belongs_to wins over a manually passed belongs_to. It even discloses that the result returns a note when something was adjusted.

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?

Front-loaded around the admission rule and moment-of-decision, with clear section breaks (CORRECTIONS, ADMISSION RULE, RUN STATE). It is long, and some material duplicates the schema's own parameter descriptions (supersedes, replace_previous, observed_at), but for a 16-parameter cross-assistant journal the length is largely earned.

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?

With 16 parameters, no output schema, and only content required, the description covers the decision surface fully: granularity guidance (1-3 entries per session), what the result carries (id, belongs_to, note), the admission test for shared memory, and the conflict/retry behavior. Nothing material for calling it correctly is missing.

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 coverage is 100%, so a 3 is the baseline; the description nonetheless adds selection logic the schema states only mechanically — set source to who you are, pass account before belongs_to when the work came from one account, set confidence for profile/person claims, use memory_key + replace_previous for run state and supersedes otherwise. It maps parameters to concrete situations rather than restating their types.

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 specific verb and resource ('Record what was done / learned / DECIDED') and frames the resource's purpose ('a shared cross-assistant journal'). It implicitly contrasts with the read-side siblings (search_memory, get_memory_digest) by emphasizing what to write rather than what to read, so an agent can tell it apart without opening the 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?

Provides explicit when-to-use (five enumerated entry categories plus the 記録して/メモして trigger), explicit when-NOT-to-use ('Do NOT write, as a rule: starting an investigation, CI going green, ...'), and named alternatives ('do NOT just append a second entry — write the corrected entry with supersedes'). This is about as complete as usage guidance gets.

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

All AccountHub toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources