memento-context

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are largely distinct: init/get/save/delete/move cover clear lifecycle operations, and attachment/conversation save are separately named. Some overlap exists between save_memento and save_conversation (both persist mementos, differing mainly by whether attachments are included), but descriptions help disambiguate. The confusing 'mandatory init first' pattern creates redundancy concern but not ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_memento pattern: init_memento, get_mementos, save_memento, delete_memento, move_memento, get_memento_attachments, save_memento_attachments, save_conversation. Minor deviation with save_conversation breaking the pattern, and pluralization of get_mementos vs singular memento naming is slightly inconsistent.
Tool Count5/5
8 tools is well within the ideal 3-15 range for a memory/context management server. Each tool serves a clear purpose in the lifecycle: initialization, retrieval, saving, attachment handling, deletion, and movement. No unnecessary tools present.
Completeness4/5
The tool surface covers the full memento lifecycle: init, read (with scope filtering), create, attach files, delete, move, and conversation capture. Minor gaps exist—there's no update/edit operation for an existing memento's content (only delete then save), and no search/filter tool beyond basic scope filtering.
Average 3.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/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 clarifies the scope semantics but doesn't disclose what happens with no scope (all active mementos, presumably), whether results are paginated, ordered, or limited in size, or what an 'active' memento means versus inactive ones. For a read tool with zero annotations, this is a moderate gap.
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, zero waste. Every clause serves a distinct purpose: the verb+resource line states what it does, and the second line clarifies the parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description covers the essential scope semantics well. However, no annotations exist to fill gaps about behavioral details (pagination, ordering, active definition), and there is no output schema. It's adequate but leaves 'active' and potential side-effect-free assumptions unexplained.
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 schema already documents the scope parameter. The description adds value by explaining what each scope value returns (all vs global vs repo), which goes slightly beyond the schema's terse 'which memory area to read.' This is at baseline 3.
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 states the verb+resource ('Returns active mementos') with clear scoping options. It doesn't explicitly name sibling tools like get_memento_attachments, but the sibling set includes many mutation/management tools, so the read-oriented purpose is reasonably distinguishable.
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 gives clear context on the three scope values and what each returns, but it doesn't state when to prefer this over siblings or exclude alternatives. The scope guidance is useful but there's no explicit when-to-use vs alternative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. The 'MANDATORY' all-caps framing conveys that this is a required prelude that loads state, but it doesn't disclose what side effects occur (e.g., does calling it twice reset state? does it create server-side sessions? what is the return value?) The behavior 'loads all mementos' is stated but minimal detail is given about what initialization actually entails beyond the get_mementos redundancy note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long sentence that packs in imperative instruction, usage guidance, and the redundancy note. It's reasonably concise and front-loads the critical mandate, but the all-caps shouting and the run-on structure makes it slightly harder to parse. It earns its sentences but could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an initialization tool with zero required params and no output schema, the description covers the critical usage context (when to call, that it loads state). However, it doesn't explain what the tool returns, whether it's safe/idempotent to call repeatedly, or the nature of the 'memento' state being loaded, which would be useful for a first-call setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one optional parameter. The description adds meaning to repo_path by explaining the scoping behavior ('scoped memory tied to this path instead of server's working directory'), which goes beyond the schema's phrasing. This adds genuine value to the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool initializes/loads mementos and is the mandatory first call, but the core purpose ('initializes a memento session/context') is only implied through the imperative framing and the parenthetical about loading mementos. It distinguishes from get_mementos by noting calling both is redundant, which provides sibling differentiation.
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 gives extremely explicit usage guidance: ALWAYS first action, every session, no exceptions, before greetings or simple questions. It also explicitly tells the agent NOT to call get_mementos after since it would be redundant—clear when-not guidance naming a specific sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 a prerequisite dependency (requires init/get_mementos first), which is useful, but it doesn't describe what the return payload looks like, whether it's a read-only safe operation, performance/latency implications of fetching all attachments, or error conditions. For a tool that fetches potentially large attachment data, the cost implication is understated.
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, zero waste. It states the purpose, the usage constraint, and the prerequisite in under 20 words. Front-loaded with the purpose before the caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is reasonably complete: it states purpose, when to use, and prerequisite. However, no annotations exist and there's no output schema, so the description should hint at what the return data looks like (attachment files, presumably paths or blobs) and any cost implication of fetching attachments. The prerequisite detail is good, but the attachment-heavy nature of this read is worth flagging.
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 the single 'id' parameter is documented in the schema as 'Exact memento ID to inspect.' The description adds the prerequisite context of which prior tool provides a valid ID, but doesn't add substantially beyond the schema. Baseline 3 is appropriate since the schema already handles the parameter documentation and the description confirms the ID comes from prior steps.
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?
Clear verb+resource: 'Reads and returns all attachment files for a specific memento.' It distinguishes from siblings by specifying attachments specifically, differentiating it from get_mementos which presumably lists mementos without attachments. However, it doesn't explicitly name which siblings it differs from beyond the mention of init/get_mementos.
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?
Provides clear usage guidance: 'Use this only when the extra detail is needed' and explicitly states the prerequisite 'Requires init_memento or get_mementos first.' It gives context on when to invoke and what must happen first, though it doesn't name explicit alternatives or when-not-to-use scenarios beyond the implied 'only when needed.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 it 'saves' a conversation, implying a write with side effects (persistence), but doesn't detail what happens on overwrite, whether it's destructive to existing mementos, how attachments are processed, or whether multiple scopes interact. For a persistence tool with no annotation coverage, this is a notable gap.
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 concise sentences with zero waste. It front-loads the primary action and immediately follows with critical usage conditional and prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema or annotations, the description is somewhat thin. It explains the core action and prerequisites but doesn't clarify parameter interactions (text vs summary vs conversation), what 'explicit user request' means concretely for an agent, or how scope affects storage. It's adequate but has clear gaps for a persistence tool with this 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 description coverage is 100%, so the schema already documents all 6 parameters. The description adds minimal semantics beyond the schema — it mentions attachments exist and the tool saves conversations/summaries, which loosely maps to text/summary/conversation params. But it doesn't clarify the relationship between text, summary, and conversation (e.g., must one be provided, do they combine, etc.). Baseline 3 is appropriate.
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 states it saves a conversation or summary as a memento with attachments, which is a specific verb+resource. However, it doesn't fully distinguish from sibling save_memento and save_memento_attachments — the relationship between these close siblings is unclear, which limits differentiation.
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 'Only use this on explicit user request' and requires 'init_memento or get_mementos first.' This provides clear when-to-use context and prerequisites. It doesn't explicitly name alternatives like save_memento, but it does give clear preconditions for usage.
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 burden of behavioral disclosure. It does reveal a persistence trait (across sessions), the scope-decision requirement, and the prerequisite call. However, it doesn't disclose whether save_memento overwrites existing mementos, whether deletion is possible, or what the response returns. These are gaps given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences containing the core purpose, the decision responsibility, and the prerequisite. No wasted words. Slightly more could be added about boundaries or behavior, but the current content is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 params and no output schema, but schema covers 100% of parameters. The description reasonably covers purpose, the scope-decision, and sequencing. However, for a persistent-storage mutation tool with no annotations and no output schema, more detail on overwrite behavior, return values, and scope-selection heuristics would improve completeness.
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 all 4 parameters have schema descriptions. The description itself adds limited parameter meaning beyond the schema—it clarifies that 'scope' involves a decision the agent must make (global vs repo) and that text is the memento content. It doesn't clarify tags format beyond schema, and 'expires' formatting is fully in schema. Baseline 3 is appropriate since the schema does 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?
Description states it 'Saves a persistent memento across sessions' with a specific verb+resource. It distinguishes itself from siblings by noting the tool's scope-selection responsibility (global vs repo). However, it doesn't explicitly differentiate from save_memento_attachments or save_conversation beyond the core save action.
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 gives clear context by stating the agent must choose between global and repo scope. It also provides an explicit prerequisite: 'Requires init_memento or get_mementos first.' This is useful guidance about sequencing, though it doesn't name specific sibling alternatives or when-not-to-use scenarios.
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 the disclosure burden. It discloses the bidirectional move behavior and the prerequisite requirement, but doesn't state outcomes like whether the original is deleted, idempotency, or failure behavior when IDs/scope are invalid. Adequate but not rich behavioral context.
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 concise sentences with zero waste. Front-loads the core action, then the when-to-use, then the prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no nested objects) so the description covers the essentials. However, given no annotations and no output schema, it could usefully disclose whether the memento is removed from the original scope after moving and any error conditions. Adequate but not fully complete.
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 documents both parameters. The description adds the 'reclassify stored memory' framing but doesn't elaborate on target_scope values beyond 'global or repo' which the schema already provides. Baseline 3 is appropriate with full schema coverage.
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?
Specific verb (Moves) + resource (memento) + clear scope transition (global↔repository), explicitly distinguishes the bidirectional nature. Clearly differentiated from sibling tools like delete_memento, save_memento, and get_mementos.
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?
States when to use ('when the user asks to reclassify stored memory') and names a prerequisite (requires init_memento or get_mementos first). It doesn't explicitly name alternatives/exclusions, but the prerequisite guidance provides clear usage context beyond structured fields.
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 of behavioral disclosure. It clearly states this is a destructive/irreversible deletion operation by implication ('Deletes'), which is an inherent behavioral trait. It mentions the 'exact ID' requirement, which suggests deletion is strict and may fail without an exact match. However, it doesn't describe failure cases, whether deletion cascades to attachments (potentially relevant given save_memento_attachments exists), or confirm if it's reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, front-loaded verb. It earns each sentence: the first states the action and scope, the second provides the prerequisite. Compact and efficient, though it could arguably be trimmed.
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 single-parameter destructive tool with no output schema, the description covers the essential aspects: what it deletes, the ID requirement, and the prerequisite step to obtain a valid ID. Given its simplicity, it's reasonably complete. A minor gap is not disclosing potential side effects on associated attachments, which is a plausible concern given the sibling attachment tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description reinforces the 'exact ID' requirement, adding nuance beyond the schema by emphasizing matching precision. The description's mention that the ID applies 'regardless of whether it is global or repository-scoped' clarifies the ID's semantics which the schema alone doesn't convey. Only one parameter, so little room for ambiguity.
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?
Clear verb+resource: 'Deletes an existing memento by its exact ID'. Explicitly clarifies it works for both global and repository-scoped mementos, which helps distinguish from related tools like move_memento or save_memento. Very specific and unambiguous.
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?
Provides a clear prerequisite: 'Requires init_memento or get_mementos first', which tells the agent what must happen before calling this tool to obtain the exact ID. However, it doesn't state when NOT to use it or contrast with alternatives like move_memento, though the prerequisite guidance is a solid usage constraint.
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 copies (a non-destructive mutation) and requires prior initialization, but doesn't state potential failure modes (e.g., what happens if an id doesn't exist, whether file overwrites occur, size limits). The copy semantics and prerequisite requirement are disclosed, but failure behavior is absent. A 3 reflects that it adds meaningful context beyond the name but leaves gaps.
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, zero waste. Both sentences earn their place: one states the primary action and target, the other provides usage constraints and prerequisites. Front-loaded with the core purpose.
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 tool has no output schema and no annotations, but the description addresses the key context: what it does, the user-trigger constraint, and the prerequisite ordering with sibling tools. For a file-copy operation with 2 well-documented params, this covers the essential operating context. Minor gap: no mention of overwrite/duplicate file behavior or id-not-found handling, but the description is serviceable for the complexity level.
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 both parameters (id and paths) are already fully documented in the schema. The description adds the 'exact memento ID' qualifier for id and clarifies paths are 'absolute file paths', but these largely echo the schema. Per the rule, baseline 3 is appropriate when 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 verb (Copies), resource (files into attachments directory), and target (existing memento). It distinguishes from siblings like get_memento_attachments and save_memento by specifying it populates the attachments directory of an existing memento. Very specific and unambiguous.
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?
Explicitly states 'Only use this on explicit user request', establishing a clear trigger condition. Also names the prerequisite tools (init_memento or get_mementos) that must be called first, providing clear when-to-use and ordering guidance, which is valuable for a tool with sibling tools like save_memento.
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:

[![memento-context MCP server](https://glama.ai/mcp/servers/FranBarInstance/memento-context/badges/card.svg)](https://glama.ai/mcp/servers/FranBarInstance/memento-context)

Score Badge

Copy to your README.md:

[![memento-context MCP server](https://glama.ai/mcp/servers/FranBarInstance/memento-context/badges/score.svg)](https://glama.ai/mcp/servers/FranBarInstance/memento-context)

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/FranBarInstance/memento-context'

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