Agent Memory Bridge is a local-first MCP server providing a two-channel memory system for AI agents, separating durable knowledge from short-lived coordination signals with a governed promotion ladder. It offers 10 core tools:
store: Persist durable knowledge as memory or transient coordination events as signal into logical namespaces (global, project:<workspace>, domain:<name>), with optional tags, TTL, actor identity, session IDs, and correlation IDs.
recall: Search stored entries using full-text queries or metadata filters (kind, tags, actor, session, signal status, correlation ID), with cursor-based polling support.
browse: Inspect recent items in a namespace by kind, domain, or signal status without a specific search query.
stats: Get a health summary including item counts, kind breakdown, top domains, and oldest/newest timestamps.
forget: Remove a specific entry by ID to clean up stale or accidental writes.
claim_signal: Take ownership of a pending signal with a timed lease, with fairness bias for polling consumers.
extend_signal_lease: Extend an active lease to allow more processing time before another consumer can reclaim the signal.
ack_signal: Mark a claimed signal as done to stop downstream polling.
promote: Manually reclassify a memory to a stronger type (learn, gotcha, domain-note) along the governed promotion ladder (session → summary → learn/gotcha → domain-note → belief → concept-note).
export: Export namespace content in markdown, json, or text format with optional filters.
Storage is backed by SQLite with FTS5, requiring no cloud dependencies, and retrieval quality is benchmarked with precision/recall metrics.
Uses SQLite with FTS5 as the local-first storage backend for durable agent memory and signals, enabling full-text search and persistent storage of coding session knowledge without requiring hosted infrastructure.
pip install agent-memory-bridgeInstall once; connect each coding client separately. Installing the package does not register AMB with every coding agent. Each client you want to use must be configured to launch AMB as an MCP stdio server. Clients that should share memory need to use the same configured local AMB home.
A project is more than its current files. Over time, useful context gets scattered across repositories, chats, coding agents, reviews, fixes, and one-off decisions. A new session can see the code but still miss the reasons, constraints, corrections, and history that make the project make sense.
AMB gives that project context a durable place to accumulate without turning memory into an unreviewable transcript dump.
Without shared project memory | With AMB |
Each session reconstructs context | Useful project knowledge carries forward |
Decisions disappear into old chats | Explicit decisions and reasons stay with the project |
Different tools build different partial pictures | Supported MCP clients can use the same configured local AMB home |
Memory can become stale or ambiguous | Provenance, revision, supersession, and inspection keep it governable |
AMB is local-first and inspectable. It does not silently archive every conversation or treat every remembered statement as equal authority.
Related MCP server: mcp-chest-memory
AMB starts small: derive a reviewable baseline from the repository, then add the decisions, constraints, corrections, and context that are worth carrying forward.
repo / project baseline
+
explicit decisions and constraints
+
revisions, corrections, provenance
↓
governed project memory
↓
future sessions · coding agents · toolsThe repository is the common starting point for software projects, but the memory model is about the project, not just the codebase: the durable knowledge surrounding the work can outlive any one chat, agent, or tool.
AMB requires Python 3.11+, Git, and an MCP-compatible coding client that can launch a local stdio server.
Current source version: 0.32.2
Published releases: see GitHub Releases
For the 0.32.2 release line, the normal install route is PyPI. GitHub Releases remains the publication authority for source tags and release notes; an exact source checkout can still be installed with pip install -e . for development or audit work.
For the Quick Start, use a virtual environment so every coding client can point at one stable Python launcher. Replace <venv-python> with the Python executable inside .amb-venv for your operating system.
python -m venv .amb-venv
<venv-python> -m pip install agent-memory-bridgeFor an exact, reproducible 0.32.2 environment, use this install line instead:
<venv-python> -m pip install agent-memory-bridge==0.32.2Installation and client registration are separate. Preview the setup for one client first:
<venv-python> -m agent_mem_bridge setup --client <client>setup is read-only by default: it detects or inspects only bounded client configuration locations and shows the exact AMB fragment or action it recommends. Use a supported client name such as codex, claude-code, vscode, cursor, cline, opencode, or another client listed in Integrations.
If the preview marks that client as eligible for safe automatic configuration, you can explicitly apply it after review:
<venv-python> -m agent_mem_bridge setup --client <client> --applySome clients remain preview/manual because AMB will not guess or rewrite an unsafe configuration format or path. In that case, copy the rendered fragment or follow the client-specific Integration guide. Repeat this step for every coding client you want to connect. To share the same project memory across clients, keep them pointed at the same configured AGENT_MEMORY_BRIDGE_HOME, then reload each client after registration.
<venv-python> -m agent_mem_bridge project init .Project Init detects the local Git repository, proposes a namespace such as project:my-app, and waits for confirmation. It then derives a current repository baseline and opens the Human-first Explore view. It does not automatically learn decisions.
For example, tell the connected coding agent:
Remember that we decided not to add Redis because this project is intentionally local-first and single-node.
The connected agent uses AMB's existing public memory tools to store the explicit decision and reason. AMB does not infer a durable decision from the code or archive the whole conversation.
<venv-python> -m agent_mem_bridge explore \
--namespace project:my-app
<venv-python> -m agent_mem_bridge inspect \
--namespace project:my-app \
--query "Should we add Redis?"Explore answers “What does AMB currently know about this project?” Inspect answers “Why did this information surface for this question?” Both are local and read-only.
This is a conceptual view, not verbatim CLI output:
CODE / WHAT CONVERSATION / WHY
──────────────────── ──────────────────────────
Runtime: Python >=3.11 Decision: Do not add Redis
Package: my-app Reason: local-first,
Tests: pytest single-node projectUnder the hood, AMB keeps repository-derived facts separate from explicitly taught project knowledge:
Code tells AMB WHAT the project is.
Conversations teach AMB WHY it is that way.
That distinction is a trust boundary, not the whole product story: derived facts can be rebuilt from current code, while durable project knowledge remains explicit, reviewable, and governed.
Repository WHAT comes from a clean Git commit. If HEAD changes or the worktree is dirty, AMB will not present an old snapshot as current truth. Refresh is not automatic. Rerun the explicit primitive:
<venv-python> -m agent_mem_bridge bootstrap-repo . \
--namespace project:<name>Refreshing repository WHAT leaves durable project WHY unchanged. Explore is CLI-only, not MCP tool #18, and it does not rank context for the model.
first-run remains optional guided help; it is not the modern Project Learning entrypoint:
<venv-python> -m agent_mem_bridge first-run --namespace project:my-app --query "What should I remember?"Use health checks only when setup is uncertain:
<venv-python> -m agent_mem_bridge doctor
<venv-python> -m agent_mem_bridge verifyAMB works through local stdio MCP. Generic MCP clients are supported; Codex is the reference workflow; Claude Code, Claude Desktop, Cursor, and Cline are documented; and Antigravity, OpenCode, and Hermes have locally tested configuration paths.
Integration labels are deliberately narrow and do not imply client certification. See Integrations for current setup instructions and boundaries.
The useful part of long-lived project memory is not simply remembering more. It is being able to tell where knowledge came from, whether it is still current, and how it changed.
AMB therefore keeps several boundaries explicit:
Memory concern | AMB approach |
Current repository truth | Derived from a clean repository state and refreshed explicitly |
Human decisions and constraints | Stored explicitly as governed durable memory |
Changed knowledge | Revised or superseded instead of silently overwritten |
Why context surfaced | Inspectable through local derived views and evidence paths |
Cross-session reuse | Shared through the same configured local AMB home |
Privacy | Local-first; no hosted memory service is required |
This is where the earlier WHAT / WHY model belongs: it explains one of the mechanisms that keeps memory trustworthy, rather than defining the entire product.
AMB is a governed local project-memory layer for coding agents. It is designed to preserve useful context across sessions and tools while keeping durable knowledge, derived repository facts, provenance, and corrections distinguishable.
It is not a transcript archive, a promise that an agent will remember everything, or a system that silently converts every conversation into durable truth.
Read | For |
System shape and data flow | |
Durable authority, derived views, correction, and audit rules | |
Human-first read-only project view | |
Current implementation facts, evidence, and known limits | |
Client-specific local MCP setup | |
Full install-to-first-success workflow | |
Complete configuration reference | |
Sanitized demos and artifacts |
The product story above intentionally postpones implementation vocabulary. Internally, AMB keeps derived_repository data separate from governed durable memory so one cannot silently become the other. For maintainers and reviewers, the current authority flow is:
flowchart LR
A[Durable Memory / WHY] --> C[Lifecycle-aware Recall]
B[Repository Knowledge / WHAT] --> D[Context Compiler]
S[Dynamic State Authority] --> D
C --> E[Governed Task Memory]
E --> D
D --> F[Transient Bounded Context]
F --> G[Metadata-only Context Attestation]
G --> H[Episode and Run Authority]
H --> I[Verification Receipt]
I --> J[Current Verified Outcome]SQLite/WAL rows are durable authority. Repository snapshots, FTS rows, embedding sidecars, compiled context, reports, and Explorer views are derived. Context bodies are rendered in process and are not durably persisted by the compiler.
AMB is local-first. It does not require a hosted memory service. It separates durable memory from coordination Signals and mutable Dynamic State, keeps provenance visible, and rejects raw transcripts, hidden reasoning, and inline artifact bodies from the durable episode path.
Read the Trust Boundary, Authority Contract, and Closed-Loop Episode Authority for the exact boundaries.
AMB exposes 17 public MCP tools:
store, recall, browse, and stats
forget, feedback, promote, annotate, revise, and export
begin_run, record_run_event, get_run, and complete_run
claim_signal, extend_signal_lease, and ack_signal
The public tool surface stays small. Setup, Project Init, Explore, Inspect, context assembly, and review reports remain CLI or internal derived workflows rather than becoming more MCP tools.
The local protocol cache contract is 300000/public for discovery and 0/private for the tool list; see MCP Compatibility for details.
The current source is 0.32.2, uses schema v12, and retains the frozen 17-tool MCP surface. project init is the preferred first-project path. Default Explore is a Human-first view over existing repository-derived context and governed project knowledge. Current evidence and non-claims live in Production Status; published artifacts live in GitHub Releases.
Read CONTRIBUTING.md for development and public-surface expectations, and SECURITY.md for vulnerability reporting.
Licensed under MIT.
Acknowledge one claimed or pending signal so downstream polling can stop treating it as active work.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact signal id to acknowledge after the work is done. | |
| consumer | No | Consumer identity that must match the owner of an active claim. It may be omitted only when acknowledging a pending, unclaimed signal. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool acknowledges signals and affects downstream polling, but lacks details on idempotency, permissions, or error states for already-acknowledged signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise, front-loaded, and contains no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description covers the action and effect. It is adequate but could add context like idempotency or when to omit the consumer parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Acknowledge' and the resource 'signal' (claimed or pending), and explains the effect: stopping downstream polling from treating it as active work. This distinguishes it from siblings like claim_signal and extend_signal_lease.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (after work on a signal is done) by mentioning 'claimed or pending' signals. However, it does not explicitly state when not to use or mention alternatives, though sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly enrich one durable memory without pretending the write was a new fact.
Use this after store reports duplicate_with_new_metadata. The original content
remains unchanged; title/tag changes and additional provenance are written to an
auditable annotation record.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact durable memory id whose metadata should be explicitly enriched. | |
| tags | No | Optional tags to add. Existing tags remain and the annotation is audited. | |
| actor | No | Optional identity of the human or agent performing the explicit annotation. | |
| title | No | Optional replacement title. Content and memory identity remain unchanged. | |
| provenance | No | Optional additional provenance fields such as source_client, source_model, session_id, or correlation_id. They are retained in the annotation audit trail. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states that original content remains unchanged, and changes create an auditable annotation record. This effectively conveys non-destructiveness and auditability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core purpose and usage condition. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, when to use, and key behavioral traits. With an output schema present (though not described), the tool is sufficiently specified for a moderate-complexity enrichment operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add detailed syntax beyond the schema, but it provides the overarching purpose which helps contextualize the parameters. No extra semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it enriches durable memory without creating a new fact, and names the specific context ('after store reports duplicate_with_new_metadata'). It clearly distinguishes from the sibling tool 'store'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly says when to use ('after store reports duplicate_with_new_metadata'), providing clear contextual guidance. It does not exhaustively list when not to use or compare with all siblings, but the condition is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start one explicit, stateless run and return server-minted run/work-item IDs.
The bridge does not retain an implicit current run. Callers must pass the returned handles to later event, read, and completion calls. Idempotent retries return the same handles and reject conflicting payloads.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Root goal for the run. Keep it bounded and outcome-oriented. | |
| budget | No | Optional bounded JSON budget metadata, such as token or time limits. | |
| agent_id | No | Optional declared agent or worker identifier. It is provenance, not authenticated identity. | |
| non_goals | No | Optional bounded non-goals declared for this run. | |
| thread_id | No | Optional external thread or conversation identifier. | |
| provenance | No | Optional bounded declared provenance for the run. | |
| risk_level | No | Declared run risk level; high and critical preflight reviews require a rollback plan. | medium |
| constraints | No | Optional bounded constraints declared for this run. | |
| model_digest | No | Optional lowercase SHA-256 digest of the model identity or configuration. | |
| memory_scopes | No | Optional declared memory scopes available to the run. These do not grant authorization. | |
| workspace_key | Yes | Declared workspace scope for this run, such as `project:<workspace>`. The server uses it to reject cross-workspace run access. | |
| harness_digest | No | Optional lowercase SHA-256 digest of the harness configuration. | |
| idempotency_key | Yes | Caller-generated retry key. The bridge stores only its SHA-256 digest and returns the original server-minted run for an identical retry. | |
| evidence_profile | No | Evidence governance profile. governed-v2 requires typed events and server-minted receipts. | observational |
| tool_schema_digest | No | Optional lowercase SHA-256 digest of the tool schema used by the run. | |
| acceptance_criteria | No | Optional structured acceptance criteria with stable id or criterion_id values. | |
| chat_template_digest | No | Optional lowercase SHA-256 digest of the chat template. | |
| continuation_of_run_id | No | Optional same-workspace prior run that this run continues. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses statelessness, the lack of an implicit current run, the need to pass handles, idempotent retry behavior, and rejection of conflicting payloads. This is substantial coverage of the tool's non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences, front-loaded with the primary purpose, and every sentence adds critical behavioral information. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a run-initiation tool with an output schema and fully described parameters, the description covers the essential behavioral aspects: return of handles, statelessness, and idempotency. It does not explicitly outline a full workflow, but the reference to 'later event, read, and completion calls' provides sufficient contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its 18 parameters, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema, but schema already describes each parameter in detail, so no penalty is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Start one explicit, stateless run and return server-minted run/work-item IDs.' This clearly identifies the action and distinguishes it from sibling tools like complete_run or record_run_event, which operate on an already-started run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by explaining that the bridge has no implicit current run and that callers must pass returned handles to later event, read, and completion calls. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse recent items when you do not yet know what to search for.
Use this tool to inspect a namespace by filters alone. It is useful when you want to see recent memory, scan a domain bucket, or confirm that signals are flowing before writing a more specific recall query.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional type filter. Use `memory` for durable knowledge and `signal` for coordination events. | |
| limit | No | Maximum number of items to list. Smaller values keep browse output readable. | |
| domain | No | Optional domain tag to narrow the list, using the plain domain name without the `domain:` prefix. | |
| namespace | Yes | Namespace to inspect without a text query, such as `project:<workspace>`, `domain:<name>`, or `global`. | |
| signal_status | No | Optional status filter when browsing signal entries. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool browses/inspects, implying read-only behavior, but does not explicitly confirm it is non-destructive. It mentions 'recent items' but does not clarify ordering or whether results are always recent. Partial transparency, but gaps remain (e.g., effect on state, pagination, error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded: the first sentence states the core purpose. Every sentence earns its place, providing examples and contrast without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required) and an output schema, the description covers key usage contexts (browsing recent items, scanning domains, confirming signals). It does not explain output schema (not required per rules) but could be more explicit about ordering, read-only nature, or error conditions. Overall adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 5 parameters described in the input schema. The tool description adds no additional parameter-level details beyond what the schema already provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Browse recent items' and 'inspect a namespace by filters alone.' It provides specific use cases (recent memory, domain bucket, confirm signals flowing) and distinguishes itself from the sibling tool 'recall' by contrasting with a 'more specific recall query.' The verb 'browse' matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool: 'when you do not yet know what to search for' and 'before writing a more specific recall query.' It enumerates scenarios (see recent memory, scan domain bucket, confirm signals flowing) and implicitly distinguishes from alternatives like 'recall' by naming it directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim one signal with a short lease for lightweight work coordination.
Use this when a worker should take ownership of a pending signal before it acts.
If signal_id is omitted, the bridge claims the next eligible signal in the
namespace that matches the optional filters, with a small fairness bias inside
the oldest pending window so one polling consumer does not keep winning by accident.
| Name | Required | Description | Default |
|---|---|---|---|
| consumer | Yes | Stable worker or agent identifier that will own the lease, for example `reviewer-a` or `worker:planner`. | |
| tags_any | No | Optional OR-style tag filter used to narrow which pending signals are claimable. | |
| namespace | Yes | Namespace that holds the coordination events to claim, such as `project:<workspace>`. | |
| signal_id | No | Optional exact signal id to claim. Leave empty to claim the next eligible signal. | |
| lease_seconds | No | How long the claim lease should last before another consumer can reclaim the signal. | |
| correlation_id | No | Optional workflow correlation id used to claim signals from one handoff thread. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the fairness bias and optional filters, which adds value. However, it does not mention edge cases like what happens if the signal is already claimed or if the lease expires, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Two short paragraphs no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with 100% schema coverage and an output schema exists, the description covers the main use case adequately. It could be slightly more complete by mentioning the outcome format, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only emphasizing that omitting signal_id claims the next eligible signal. This is partially redundant with the schema's default null and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool claims a signal with a short lease for lightweight work coordination. It distinguishes the action from siblings by focusing on claiming and leasing, but does not explicitly differentiate from similar tools like ack_signal or extend_signal_lease.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'when a worker should take ownership of a pending signal before it acts.' It also explains behavior when signal_id is omitted. However, no exclusions or alternatives are mentioned, such as when to use ack_signal instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append or correct a run outcome without changing memory ranking or policy.
On new runs, verified_success requires a matching current server-minted governed receipt.
Outcome corrections form an append-only supersession chain.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | Server-minted run identifier returned by `begin_run`. | |
| metrics | No | Optional structured outcome metrics, limited to 32 KiB. | |
| outcome | Yes | Declared outcome for this append-only outcome revision. | |
| evidence | No | Structured outcome evidence, limited to 32 KiB. | |
| provenance | No | Optional bounded declared provenance for the outcome. | |
| workspace_key | Yes | Declared workspace scope that owns the run. | |
| evaluator_type | Yes | Evidence source class. Agent self-report cannot establish verified success. | |
| idempotency_key | Yes | Caller-generated retry key scoped to this run; only its SHA-256 digest is stored. | |
| evaluator_digest | No | Optional lowercase SHA-256 digest of the evaluator implementation or configuration. | |
| evaluator_version | No | Optional bounded evaluator version label. | |
| termination_reason | No | Optional bounded reason the run ended. | |
| regression_of_run_id | No | Distinct same-workspace run with a current `verified_success` outcome; required for a `regression` outcome. | |
| supersedes_outcome_id | No | Current outcome head to supersede when recording a correction. | |
| expected_last_sequence | No | Current run sequence CAS precondition; required by governed-v2 runs. | |
| expected_database_epoch | No | Database epoch CAS precondition; required by governed-v2 runs. | |
| expected_run_generation | No | Run generation CAS precondition; required by governed-v2 runs. | |
| verification_receipt_id | No | Server-minted governed verification receipt. Ordinary MCP callers cannot mint receipts; required for verified_success on new runs. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the append-only supersession chain and the receipt requirement for verified_success, which are important behavioral traits. However, it doesn't mention other behavioral aspects like CAS preconditions, idempotency semantics, or what happens on conflicting updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and key constraint. Every sentence adds value; no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 17-parameter tool with no annotations, the description covers the most critical behavioral constraints (receipt requirement, supersession chain) and the schema covers all parameter semantics. The output schema exists, so return values are documented. It could elaborate on governed-v2 CAS preconditions, but the schema already describes those, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context to key parameters: 'verified_success requires a matching current server-minted governed receipt' explains verification_receipt_id, and 'append-only supersession chain' explains supersedes_outcome_id. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Append or correct' and identifies the resource 'run outcome', clearly stating what the tool does. It also includes the constraint 'without changing memory ranking or policy', which distinguishes it from memory-related sibling tools like store, forget, and revise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: for new runs with verified_success requiring a receipt, and for corrections forming a supersession chain. It implies this is for finalizing outcomes rather than recording intermediate events (sibling record_run_event), but doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export bridge content into a readable or portable format.
Use this tool when you want to inspect a namespace outside the MCP client, create a human-readable snapshot, or move memory into another system without opening the database directly.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional type filter for the export. | |
| limit | No | Maximum number of entries to export in one call. | |
| query | No | Optional full-text query to narrow the export. Leave empty to export by filters alone. | |
| format | No | Output format for the exported memory. Use `markdown` for readable notes, `json` for structured interchange, or `text` for plain text. | markdown |
| tags_any | No | Optional OR-style tag filter. Any matching tag is enough for an entry to be included. | |
| namespace | Yes | Namespace to export, such as `project:<workspace>`, `domain:<name>`, or `global`. | |
| signal_status | No | Optional status filter when exporting signal entries. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as exporting content into a readable/portable format, implying a read operation without side effects, but it does not explicitly state nondestructive behavior, permission requirements, or other behavioral traits beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the action and resource, and the second listing usage scenarios. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters with full schema descriptions, the presence of an output schema, and a succinct purpose statement, the description is largely complete. It does not discuss limitations like the 500 max limit, but those are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema, so it meets the baseline for fully documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'export' and the resource 'bridge content', and distinguishes its purpose from sibling tools by specifying external use cases: inspecting a namespace outside the MCP client, creating a human-readable snapshot, or moving memory into another system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios ('when you want to inspect a namespace outside the MCP client...'), but does not mention when not to use or point to alternative tools among siblings, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the active lease on one claimed signal.
Use this when a worker still owns a signal but needs more time before another consumer can reclaim it. Expired leases cannot be extended; those signals must be reclaimed instead. Hard signal expiry still takes precedence over lease renewal.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact signal id whose active lease should be extended. | |
| consumer | Yes | Consumer identity that currently owns the lease. Only the active claimant can extend it. | |
| lease_seconds | Yes | Additional lease duration in seconds. The bridge extends from the current lease end when possible, but never beyond the signal's hard expiry. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that expired leases cannot be extended and that hard expiry overrides lease renewal. It does not detail error states or idempotency, but the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first sentence immediately states the purpose, and the second paragraph adds usage guidelines. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema (not shown but present), the description provides sufficient context for a lease extension tool. It explains the core behavior, constraints, and relates to sibling tools implicitly. Minor gap: no mention of return value or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning beyond schema: 'id' is exact signal id, 'consumer' is current claimant, 'lease_seconds' extends from current lease end but not beyond hard expiry. This provides critical context for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: extending the active lease on a claimed signal. It uses a specific verb ('extend') and resource ('active lease on one claimed signal'), and distinguishes from sibling tools like 'claim_signal' and 'ack_signal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (worker owns signal, needs more time) and when not to use (expired leases must be reclaimed). Mentions precedence of hard signal expiry, clarifying boundary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record structured retrieval feedback for one recalled memory result.
Evidence is append-only/shadow-only. Provenance is caller-declared and not authenticated. This tool does not mutate memory records, recall results, or ranking behavior.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional compact reason. Required for `misleading` and `outdated` outcomes. | |
| outcome | No | Declared retrieval outcome. Required for votes and corrections; optional for retractions. | |
| memory_id | Yes | Exact recalled memory id being evaluated. | |
| namespace | Yes | Namespace used by the recall receipt, such as `project:<workspace>` or `global`. | |
| provenance | No | Optional declared provenance fields such as source_app, source_client, source_model, client_session_id, client_workspace, client_transport, or actor. | |
| result_rank | Yes | One-based rank of the memory in the recalled result list. | |
| feedback_type | No | Append-only feedback event type. Defaults to a root vote. | vote |
| recall_receipt | Yes | Signed recall receipt token returned by a durable memory text `recall` response. | |
| supersedes_feedback_id | No | Current feedback head id. Required for corrections and retractions; omitted for root votes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses key behavioral traits: 'Evidence is append-only/shadow-only. Provenance is caller-declared and not authenticated. This tool does not mutate memory records, recall results, or ranking behavior.' This is comprehensive given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the purpose. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, an output schema, and no annotations, the description covers key behavioral aspects (append-only, provenance trust). It lacks details on error handling or response format, but output schema likely covers return values. Minor gaps noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds no per-parameter details, but provides overarching behavioral context. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Record structured retrieval feedback for one recalled memory result.' This distinguishes it from siblings like recall (which retrieves) and store (which stores memories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a recall, but does not explicitly state when to use or when to avoid. There is no mention of alternatives or conditions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one stored entry by id.
Use this tool to remove a bad memory, an accidental write, or a signal that should no longer exist. The response tells you whether anything was deleted and returns the removed item metadata when a match is found.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact memory identifier to remove. Use this when a record is noisy, wrong, or no longer belongs in the bridge. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explicitly states the tool 'Delete' (destructive hint) and describes the response: 'The response tells you whether anything was deleted and returns the removed item metadata when a match is found.' This is sufficient for a simple deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first states the action, the second provides usage context, and the third explains the response. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (though not shown), the description covers the core behavior and response. It is functionally complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter (100% coverage), and the description adds meaning beyond the schema by specifying when to use it: 'Use this when a record is noisy, wrong, or no longer belongs in the bridge.' This enriches the semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete one stored entry by id,' providing a specific verb and resource. It distinguishes from siblings like 'store' and 'recall' by focusing exclusively on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: 'to remove a bad memory, an accidental write, or a signal that should no longer exist.' While it does not explicitly mention when not to use it, the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current run/work-item projections plus append-only events for reconnect or compaction recovery.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | Server-minted run identifier returned by `begin_run`. | |
| event_limit | No | Maximum number of ordered events to return in this page. | |
| workspace_key | Yes | Declared workspace scope that owns the run. | |
| since_sequence | No | Return only events whose per-run sequence is greater than this value. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that this is a read operation ('Read') and introduces the concept of 'append-only events,' signaling non-destructive behavior. It adds the recovery use case, but does not describe potential prerequisites or side effects, making it slightly above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with high information density. The verb is front-loaded, and every phrase adds value: resource type, operation, and a concrete use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core function and a key scenario (reconnect/compaction recovery). With an output schema present, the return structure is handled elsewhere. Minor gap: no explicit guidance on how this fits with sibling run lifecycle tools, so a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the input schema, so the description does not need to elaborate. The tool description does not mention parameters, but the schema covers them fully; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Read' and clearly identifies the resource (run/work-item projections and append-only events). It distinguishes this from sibling tools like record_run_event and begin_run by focusing on reading state for recovery scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reconnect or compaction recovery, providing a clear context for when to invoke this tool. However, it does not explicitly exclude alternative tools or name them, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually promote one stored memory to a stronger durable record type.
Use this tool when you know a record should be treated as a learn, gotcha, or domain note even if the reflex layer has not promoted it yet. Promotion keeps the same id and updates the stored title, tags, and structured content in place.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact memory identifier to reclassify. Use this when a stored record should be treated as a stronger kind of durable memory. | |
| to_kind | Yes | Target durable record type. Use `learn` for reusable claims, `gotcha` for pitfalls and fixes, or `domain-note` for broader synthesized guidance. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states that promotion 'keeps the same id and updates the stored title, tags, and structured content in place', which is useful. However, it does not mention permissions, reversibility, or error cases (e.g., if id does not exist). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, four sentences total, with the core action in the first sentence. It is front-loaded, concise, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, schema descriptions, and an output schema, the description covers the core behavior and primary use case. Missing details like prerequisites (memory must exist) are minor. The description is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description reinforces the purpose but adds little new semantic detail beyond the schema. For example, 'id' is described as 'Exact memory identifier' in schema, and 'to_kind' has enum values explained. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool promotes a stored memory to a stronger durable record type. It specifies the action ('promote'), the resource ('stored memory'), and the outcome ('stronger durable record type'). It distinguishes from siblings by mentioning manual promotion versus automatic reflex layer promotion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool when you know a record should be treated as a learn, gotcha, or domain note even if the reflex layer has not promoted it yet.' This provides a clear condition for use. It does not explicitly contrast with sibling tools like 'store' or 'recall', but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall matching entries or poll for new signals from the bridge.
Use this tool to search durable memory, filter by metadata, or poll for fresh
coordination signals. For issue-like work, prefer project and domain recall before
external search. For workflow polling, pass since, an empty query, and kind="signal".
Empty-query Signal recall returns a next_since cursor for the next polling cycle;
other recall modes return next_since=null. The cursor tracks later insertions,
not status changes to older Signals.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional type filter. Use `memory` for durable knowledge recall and `signal` for coordination or polling flows. | |
| actor | No | Optional actor filter for entries written by a specific agent or user. | |
| limit | No | Maximum number of entries to return. Smaller values keep context tighter. | |
| query | No | Optional text query for full-text recall. Leave empty to use filter-only retrieval or polling. | |
| since | No | Optional cursor for polling only entries newer than a previously seen same-namespace entry id used as a Signal polling anchor. Requires an empty query and `kind="signal"`. | |
| tags_any | No | Optional OR-style tag filter. Any matching tag is enough for an entry to qualify. | |
| namespace | Yes | Namespace to search or poll, such as `project:<workspace>`, `domain:<name>`, or `global`. | |
| session_id | No | Optional session filter to narrow results to one conversation or run. | |
| signal_status | No | Optional status filter for signals. Useful when you want only pending handoffs, currently claimed work, or already-acked coordination events. | |
| correlation_id | No | Optional correlation filter to recall entries linked to the same workflow, handoff, or task. | |
| evidence_context | No | Optional caller-declared evidence labels. Only `model`, `harness`, and `chat_template` are accepted; signed receipts contain bounded SHA-256 digests, never raw values. These labels are not authenticated and do not affect retrieval order or feedback identity. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully explains behavioral traits: distinguishes between memory and signal modes, specifies that empty-query Signal recall returns a `next_since` cursor while other modes return null, and clarifies that the cursor tracks insertions, not status changes. This covers the essential behavioral aspects without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-organized paragraphs: purpose, usage guidelines, and behavioral nuance. Each sentence earns its place, front-loading critical info and avoiding redundancy. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, two distinct use cases, and an output schema, the description provides complete operational context. It covers both retrieval and polling modes, parameter combinations, cursor behavior, and even suggests workflow preferences. The output schema handles return value detail, so the description does not need to reiterate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant usage context beyond the schema. For example, it explains that `since` requires an empty query and `kind='signal'`, and describes the meaning of `next_since` cursor. This enriches parameter understanding beyond the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's dual purpose: recall entries from durable memory and poll for new signals. It differentiates from siblings like 'store' and 'forget' by being retrieval-focused, and gives explicit guidance on when to use each mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this tool to search durable memory, filter by metadata, or poll for fresh coordination signals.' Includes specific instructions for workflow polling with `since`, empty query, and `kind='signal'`. Also advises preferring project/domain recall for issue-like work, offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append one structured event to a run's durable authority ledger.
Sequence allocation, event persistence, child work-item creation, and projection updates occur in one transaction. This tool never sets an implicit current run.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | Server-minted run identifier returned by `begin_run`. | |
| payload | No | Optional structured JSON payload, limited to 32 KiB. Raw reasoning fields are rejected. | |
| summary | Yes | Bounded factual event summary. Raw transcript or hidden reasoning is not allowed. | |
| agent_id | No | Optional declared agent responsible for the event. | |
| evidence | No | Optional structured evidence references, limited to 32 KiB. | |
| thread_id | No | Optional external thread or conversation identifier for the event. | |
| event_type | Yes | Structured v1 or governed-v2 logical event type. | |
| provenance | No | Optional bounded declared provenance for the event. | |
| work_item_id | No | Existing server-minted work-item identifier. Omit only for `work_item_started` when creating a child work item. | |
| workspace_key | Yes | Declared workspace scope that owns the run. | |
| owner_agent_id | No | Optional declared owner for a newly created child work item. | |
| work_item_goal | No | Goal for a new child work item, used only with `work_item_started`. | |
| idempotency_key | Yes | Caller-generated retry key scoped to this run; only its SHA-256 digest is stored. | |
| memory_attribution | No | Required receipt-bound or explicit manual memory attribution for memory_recalled, memory_applied, and memory_rejected. Recall receipt tokens are validated but never persisted. | |
| parent_work_item_id | No | Parent work-item identifier, used only when creating a child work item. | |
| event_schema_version | No | Event payload schema version; governed-v2 runs require version 2. | |
| expected_last_sequence | No | Optional compare-and-swap precondition. The append is rejected without writes when the authority ledger has a different latest sequence. | |
| expected_database_epoch | No | Database epoch CAS precondition; required by governed-v2 runs. | |
| expected_run_generation | No | Run generation CAS precondition; required by governed-v2 runs. | |
| expected_work_item_status | No | Optional compare-and-swap precondition for an existing work item. Conflicts report the actual authority-derived status. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses meaningful behavioral traits: transactional atomicity (sequence allocation, persistence, child work-item creation, projection updates in one transaction) and the absence of implicit current-run setting. This goes beyond a bare action statement, though it omits permission or failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and each sentence provides distinct value: the first defines the action, the second explains transactional scope and a key side-effect disambiguation. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 20 parameters and rich schema descriptions, the description appropriately focuses on non-obvious cross-cutting behavior (transactionality and child work-item creation). The output schema exists, so return-value documentation is not required. It is complete for an agent to select and invoke the tool, though additional usage guidance would push it higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 20 parameters with detailed descriptions. The tool description adds no additional parameter-specific meaning, but it does not need to; the baseline of 3 applies because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: append one structured event to a run's durable authority ledger. It specifies the resource (run's ledger) and the scope (one structured event), but it does not explicitly differentiate from sibling tools like `store` or `begin_run`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'append' and notes that it never sets an implicit current run, but it does not state when to prefer this tool over alternatives or provide exclusions/alternatives. The context is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new durable memory that explicitly supersedes an older record.
The predecessor remains available for audit. The bridge adds an exact supersedes
edge and records the revision receipt instead of silently mutating content in place.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact durable memory id that the new revision supersedes. | |
| tags | No | Optional tags for the new revision. Defaults to compatible predecessor tags. | |
| actor | No | Optional identity responsible for the revision. | |
| title | No | Optional title for the new revision. Defaults to the predecessor title. | |
| reason | No | Optional compact reason stored with the predecessor/successor audit link. | |
| provenance | No | Optional provenance overrides for the new revision. | |
| replacement_content | Yes | Complete replacement content for the new auditable memory revision. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that the predecessor remains for audit, that it adds a 'supersedes' edge, and that it records a revision receipt instead of mutating in place. This is transparent, though it could mention any required permissions or irreversible aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the main action. Every sentence adds value: the first declares the purpose, the second adds critical behavioral detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no annotations, output schema exists), the description is complete. It explains the core behavior and audit trail. Return value is covered by the output schema. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add meaningful meaning beyond the schema; it uses the term 'durable memory' but that is not a parameter. The parameter descriptions in the schema already are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new durable memory that supersedes an older record, using a specific verb ('revise') and resource ('durable memory'). This distinguishes it from siblings like 'store' (create new) and 'forget' (remove).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for updating with an audit trail, but does not explicitly state when to use it versus alternatives like 'store' (which may silently overwrite) or 'forget'. No when-not-to-use or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a quick health summary for one namespace.
Use this tool when you want to inspect what is in the bridge without opening SQLite directly. It returns total item count, a kind breakdown, top domains, and the oldest and newest entry timestamps for the namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | Yes | Namespace to summarize, such as `project:<workspace>`, `domain:<name>`, or `global`. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a non-destructive read operation and explains what information is returned. Could mention that it is safe or has no side effects, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only, front-loaded with purpose, followed by usage guidance and output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, read-only, output schema exists), description fully covers purpose, usage, parameters, and return values. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter with full description including examples (project:<workspace>, domain:<name>, global). Description adds context linking parameter to the summary output, providing extra value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'quick health summary' for a namespace, specifying verb and resource, and distinguishes from sibling tools like browse or manage operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when inspecting the bridge without SQLite, and lists returned contents (item count, kind breakdown, top domains, timestamps). Missing explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store one entry in the bridge for later retrieval or coordination.
Use this tool when you want to persist a compact memory record or write a signal
that another workflow can poll later. Write durable knowledge as kind="memory"
and transient coordination events as kind="signal".
Returns the stored entry identifier, timestamp, and duplicate information. Repeated
memory writes may deduplicate; signal writes are intended to remain append-like.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | `memory` stores durable knowledge for later retrieval. `signal` stores pollable coordination events for handoff or workflow triggers. | memory |
| tags | No | Optional stable labels for retrieval and filtering, for example `kind:gotcha`, `domain:retrieval`, or `project:demo-app`. | |
| actor | No | Optional writer identity such as an agent, reviewer, or user profile. | |
| title | No | Optional short label for UI display or scanning. Keep it concise and stable when possible. | |
| content | Yes | Machine-readable memory payload to persist. Prefer compact claims, fixes, decisions, or signals over long transcript-style prose. | |
| namespace | Yes | Logical memory bucket to write into, such as `project:<workspace>`, `domain:<name>`, or `global`. | |
| expires_at | No | Optional ISO-8601 expiry timestamp for a signal. Use this when a coordination event should stop being claimable after a deadline. | |
| session_id | No | Optional session or thread identifier used to trace entries back to one conversation or work unit. | |
| source_app | No | Optional source name for the writer, such as `codex`, `codex-session-watcher`, or another local automation. | |
| ttl_seconds | No | Optional relative expiry in seconds for a signal. Useful for short-lived handoff or review events. | |
| source_model | No | Optional external model identifier such as `gpt-5.4` or `gemini-2.5-pro`. | |
| source_client | No | Optional external client identifier such as `codex`, `antigravity`, or `claude-code`. | |
| correlation_id | No | Optional shared identifier used to link related writes, handoffs, or workflow events across entries. | |
| client_transport | No | Optional transport label such as `stdio`, `http`, or `sse`. | |
| client_workspace | No | Optional external client workspace root or project label when useful for provenance. | |
| client_session_id | No | Optional external client session or thread identifier when the caller can provide one. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that 'Repeated memory writes may deduplicate; signal writes are intended to remain append-like.' It also states what is returned: 'Returns the stored entry identifier, timestamp, and duplicate information.' This provides adequate transparency about behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with front-loaded purpose. It uses four clear sentences covering purpose, usage guidance, kind distinction, and return behavior. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, 2 required) and the existence of an output schema (so return values need not be detailed), the description is quite complete. It covers the two main use cases (memory vs signal), deduplication behavior, and the return information. It is sufficient for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds some context about the 'kind' parameter (durable vs transient) and the general purpose of storing compact records vs signals, but does not significantly enhance meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Store one entry in the bridge for later retrieval or coordination.' It specifies the verb (store), resource (entry in bridge), and the broad context (retrieval or coordination). This clearly distinguishes it from sibling tools like recall (retrieve), ack_signal (acknowledge), etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use this tool when you want to persist a compact memory record or write a signal that another workflow can poll later.' It also gives detailed guidance on the 'kind' parameter: 'Write durable knowledge as kind="memory" and transient coordination events as kind="signal".' This helps the agent decide when to use store versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.27.3begin_runcomplete_runget_runrecord_run_eventv0.26.1annotatefeedback8 fields changedInput schema / properties / feedback_type{
"default": "vote",
"description": "Append-only feedback event type. Defaults to a root vote.",
"enum": [
"vote",
"correction",
"retraction"
],
"title": "Feedback Type",
"type": "string"
}Input schema / properties / outcome / anyOf[
{
"enum": [
"helpful",
"misleading",
"outdated",
"not_applicable",
"not_used"
],
"type": "string"
},
{
"type": "null"
}
]Input schema / properties / outcome / defaultnull
Input schema / properties / outcome / description"Declared retrieval outcome for the recalled memory."
"Declared retrieval outcome. Required for votes and corrections; optional for retractions."
Input schema / properties / outcome / enum[ "helpful", "misleading", "outdated", "not_applicable", "not_used" ]
Input schema / properties / outcome / type"string"
Input schema / properties / supersedes_feedback_id{
"anyOf": [
{
"exclusiveMinimum": 0,
"type": "integer"
},
{
"type": "null"
}
],
"default": null,
"description": "Current feedback head id. Required for corrections and retractions; omitted for root votes.",
"title": "Supersedes Feedback Id"
}Input schema / required[ "namespace", "recall_receipt", "memory_id", "result_rank", "outcome" ]
[ "namespace", "recall_receipt", "memory_id", "result_rank" ]
recall1 field changedInput schema / properties / evidence_context{
"anyOf": [
{
"additionalProperties": {
"type": "string"
},
"maxProperties": 3,
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional caller-declared evidence labels. Only `model`, `harness`, and `chat_template` are accepted; signed receipts contain bounded SHA-256 digests, never raw values. These labels are not authenticated and do not affect retrieval order or feedback identity.",
"title": "Evidence Context"
}v0.25.1ack_signal1 field changedInput schema / properties / consumer / description"Optional consumer identity. When provided, the bridge checks that another active claimant does not own the lease."
"Consumer identity that must match the owner of an active claim. It may be omitted only when acknowledging a pending, unclaimed signal."
feedbackrecall1 field changedInput schema / properties / since / description"Optional cursor for polling only entries newer than a previously seen entry id. Most useful with `kind=\"signal\"`."
"Optional cursor for polling only entries newer than a previously seen same-namespace entry id used as a Signal polling anchor. Requires an empty query and `kind=\"signal\"`."
revisev0.9.0store6 fields changedInput schema / properties / client_session_id{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional external client session or thread identifier when the caller can provide one.",
"title": "Client Session Id"
}Input schema / properties / client_transport{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional transport label such as `stdio`, `http`, or `sse`.",
"title": "Client Transport"
}Input schema / properties / client_workspace{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional external client workspace root or project label when useful for provenance.",
"title": "Client Workspace"
}Input schema / properties / source_client{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional external client identifier such as `codex`, `antigravity`, or `claude-code`.",
"title": "Source Client"
}Input schema / properties / source_model{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional external model identifier such as `gpt-5.4` or `gemini-2.5-pro`.",
"title": "Source Model"
}Input schema / properties / tags / description"Optional stable labels for retrieval and filtering, for example `kind:gotcha`, `domain:retrieval`, or `project:mem-store`."
"Optional stable labels for retrieval and filtering, for example `kind:gotcha`, `domain:retrieval`, or `project:demo-app`."
v0.6.5ack_signalbrowse1 field changedInput schema / properties / signal_status{
"anyOf": [
{
"enum": [
"pending",
"claimed",
"acked",
"expired"
],
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional status filter when browsing signal entries.",
"title": "Signal Status"
}claim_signalexport1 field changedInput schema / properties / signal_status{
"anyOf": [
{
"enum": [
"pending",
"claimed",
"acked",
"expired"
],
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional status filter when exporting signal entries.",
"title": "Signal Status"
}extend_signal_leaserecall1 field changedInput schema / properties / signal_status{
"anyOf": [
{
"enum": [
"pending",
"claimed",
"acked",
"expired"
],
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional status filter for signals. Useful when you want only pending handoffs, currently claimed work, or already-acked coordination events.",
"title": "Signal Status"
}store2 fields changedInput schema / properties / expires_at{
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional ISO-8601 expiry timestamp for a signal. Use this when a coordination event should stop being claimable after a deadline.",
"title": "Expires At"
}Input schema / properties / ttl_seconds{
"anyOf": [
{
"exclusiveMinimum": 0,
"type": "integer"
},
{
"type": "null"
}
],
"default": null,
"description": "Optional relative expiry in seconds for a signal. Useful for short-lived handoff or review events.",
"title": "Ttl Seconds"
}v0.3.1browseexportforgetpromoterecall12 fields changedInput schema / properties / actor / description"Optional actor filter for entries written by a specific agent or user."
Input schema / properties / correlation_id / description"Optional correlation filter to recall entries linked to the same workflow, handoff, or task."
Input schema / properties / kind / anyOf[
{
"type": "string"
},
{
"type": "null"
}
][
{
"enum": [
"memory",
"signal"
],
"type": "string"
},
{
"type": "null"
}
]Input schema / properties / kind / description"Optional type filter. Use `memory` for durable knowledge recall and `signal` for coordination or polling flows."
Input schema / properties / limit / description"Maximum number of entries to return. Smaller values keep context tighter."
Input schema / properties / limit / maximum100
Input schema / properties / limit / minimum1
Input schema / properties / namespace / description"Namespace to search or poll, such as `project:<workspace>`, `domain:<name>`, or `global`."
Input schema / properties / query / description"Optional text query for full-text recall. Leave empty to use filter-only retrieval or polling."
Input schema / properties / session_id / description"Optional session filter to narrow results to one conversation or run."
Input schema / properties / since / description"Optional cursor for polling only entries newer than a previously seen entry id. Most useful with `kind=\"signal\"`."
Input schema / properties / tags_any / description"Optional OR-style tag filter. Any matching tag is enough for an entry to qualify."
statsstore10 fields changedInput schema / properties / actor / description"Optional writer identity such as an agent, reviewer, or user profile."
Input schema / properties / content / description"Machine-readable memory payload to persist. Prefer compact claims, fixes, decisions, or signals over long transcript-style prose."
Input schema / properties / correlation_id / description"Optional shared identifier used to link related writes, handoffs, or workflow events across entries."
Input schema / properties / kind / description"`memory` stores durable knowledge for later retrieval. `signal` stores pollable coordination events for handoff or workflow triggers."
Input schema / properties / kind / enum[ "memory", "signal" ]
Input schema / properties / namespace / description"Logical memory bucket to write into, such as `project:<workspace>`, `domain:<name>`, or `global`."
Input schema / properties / session_id / description"Optional session or thread identifier used to trace entries back to one conversation or work unit."
Input schema / properties / source_app / description"Optional source name for the writer, such as `codex`, `codex-session-watcher`, or another local automation."
Input schema / properties / tags / description"Optional stable labels for retrieval and filtering, for example `kind:gotcha`, `domain:retrieval`, or `project:mem-store`."
Input schema / properties / title / description"Optional short label for UI display or scanning. Keep it concise and stable when possible."
v0.2.1recallv0.2.0storeMost tools have clearly distinct purposes, with a few pairs like recall/browse and promote/annotate/revise that could be initially confused but are well-delineated by descriptions. Overall, an agent can reliably select the right tool for memory, signal, or run operations.
The majority of tool names follow an imperative verb or verb_noun pattern (store, recall, begin_run, ack_signal), but a few nouns like 'feedback' and 'stats' break the convention. This mixed style is still readable but not fully consistent.
At 17 tools, the set is on the heavier side, though the complex domain of memory plus run/signal coordination justifies most entries. It sits at the boundary where agents might find the surface area slightly overwhelming.
The tools cover the full memory lifecycle (create, read, update, delete) and provide robust run and signal workflows. Minor gaps exist, such as no direct get-memory-by-id or list-runs operation, but existing tools accommodate these needs reasonably well.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zzhang82/Agent-Memory-Bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
