Agent Memory Bridge

by zzhang82

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.32.2
Disambiguation4/5
Most 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.
Naming Consistency3/5
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.
Tool Count3/5
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.
Completeness4/5
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.
Average 4.2/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 158 commits in the last 12 weeks
- Last stable release on August 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Agent-Memory-Bridge MCP server](https://glama.ai/mcp/servers/zzhang82/Agent-Memory-Bridge/badges/card.svg)](https://glama.ai/mcp/servers/zzhang82/Agent-Memory-Bridge)

Score Badge

Copy to your README.md:

[![Agent-Memory-Bridge MCP server](https://glama.ai/mcp/servers/zzhang82/Agent-Memory-Bridge/badges/score.svg)](https://glama.ai/mcp/servers/zzhang82/Agent-Memory-Bridge)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zzhang82/Agent-Memory-Bridge'

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