Skip to main content
Glama

Wait for Memory Change

montycat_await_memory_change
Read-onlyIdempotent

Wait until a memory changes, then return immediately when another agent or session writes, updates, or removes an entry—use it to coordinate shared memory or confirm a write landed.

Instructions

Wait until memory CHANGES — returns the moment another agent or session writes, updates, or deletes something in this memory.

This is a live subscription to the database, not a poll: it sleeps until a change actually happens and then returns immediately. Use it to coordinate with other agents sharing a scope ("tell me when someone adds to our shared memory"), or to confirm a write from another session landed. Do NOT call it in a tight loop as a substitute for searching — to find things, use montycat_semantic_search.

Returns {changes: [...], next_seq, oldest_seq, cursor_expired, timed_out}. Each change is {seq, key, event, value} where event is "inserted" (covers create and update) or "removed". Pass the returned next_seq back as since_seq on the next call to resume exactly where you left off. If the bounded buffer has discarded part of that history, cursor_expired is true and oldest_seq identifies the earliest retained record.

Args: scope: Owner/user id whose memory to watch (keyspace mem_). Use "shared" for the common keyspace — the usual choice when coordinating between agents. keyspace: Explicit keyspace override (advanced; bypasses scope). timeout_sec: How long to wait before giving up (default 30). On timeout the result is empty with timed_out: true — that is a normal outcome, not an error. since_seq: Resume cursor from a previous call. Omit on the first call to watch only for changes from now on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo
keyspaceNo
since_seqNo
timeout_secNo
Install Server

TDQS

A5/5.0
Behavior5/5

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

It discloses the live-subscription behavior, explains that timeout is a normal outcome rather than an error, describes cursor resumption via since_seq/next_seq, and covers buffer expiry with cursor_expired and oldest_seq. This adds substantial behavioral context well beyond what the annotations already state.

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?

Although the description is longer than average, every section earns its place: behavior, usage, return contract, and parameter details are separated cleanly. The length is justified by four parameters and a non-obvious return/cursor contract.

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?

The description is complete for this tool's complexity: no output schema exists, yet it documents the return shape, event semantics, timeout behavior, cursor continuation, and both scope and keyspace modes. An agent has everything it needs to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates: it documents all four parameters, including scope's shared keyspace, keyspace as an advanced override, timeout_sec's default and normal timeout behavior, and since_seq's cursor semantics. This is exactly the compensation needed when the schema provides no descriptions.

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 waits until memory is written, updated, or deleted, and returns at the moment of change. It also distinguishes itself from montycat_semantic_search, so an agent can tell this subscription-style tool apart from its siblings.

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 explicitly states when to use the tool: coordinating with other agents sharing a scope and confirming that a write from another session landed. It also gives a clear exclusion: do not use it in a tight loop as a substitute for searching, and directs agents to montycat_semantic_search instead.

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

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/MontyGovernance/montycat-mcp'

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