memshelf-mcp

by ignatenkofi

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.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: shelve stores episodes, recall retrieves them, index provides the entry point, search greps content, stats reports economy, init creates shelves, resolve handles conflicts, doctor diagnoses issues, and import brings in external conversations. No overlap or confusion.
Naming Consistency5/5
All tools follow the consistent pattern `memshelf_<verb>`, using snake_case and descriptive verbs (shelve, recall, index, search, stats, init, resolve, doctor, import). No mixing of conventions or vague names.
Tool Count5/5
With 9 tools covering storage, retrieval, maintenance, diagnostics, and import, the count is well-scoped for a memory shelf server. Each tool earns its place without being excessive or insufficient.
Completeness5/5
The tool surface covers the full lifecycle: initialization, storage (shelve), retrieval (recall, index, search), analysis (stats, doctor), conflict resolution (resolve), and external import (import). Missing operations like deletion or update are not expected given the shelf's archival nature, making the set complete for its domain.
Average 4.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 8 community issues answered or closed in the last 6 months
- 94 commits in the last 12 weeks
- No stable releases found
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds meaningful behavioral detail by specifying the reported metrics (standing cost, shelved mass, compression ratio, savings from recalls), which goes beyond what annotations provide. It does not mention authentication or rate limits, but these are acceptable omissions given the 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 two sentences long, front-loads the core purpose, and lacks any extraneous information. Every sentence adds value, making it efficient and easy to parse.
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 that an output schema exists (not shown), the description does not need to detail return values. It adequately covers the tool's behavior and the nature of the output. However, it omits any mention of prerequisites (e.g., shelf must be initialized) or edge cases, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions are provided in the schema. The description does not elaborate on the 'shelf_path' parameter, its format, or valid values, relying solely on the schema's minimal description. This fails to compensate for the low 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?
The description clearly states the tool reports the shelf's token economy including specific metrics like standing cost, shelved mass, compression ratio, and realized savings. It uses a specific verb ('report') and resource ('shelf's token economy'), and distinguishes itself from sibling tools (e.g., memshelf_shelve, memshelf_recall) which are mutating operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. While the tool is read-only (as indicated by annotations), the description itself does not clarify usage context or provide 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds workflow context ('small recall entry point') but no additional behavioral disclosure about response size, permissions, or side effects. With annotations present, the description adds limited extra transparency.
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, no redundancy. Purpose is stated first, followed by usage guidance. Every word earns its place. Highly efficient.
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 simple one-parameter tool, annotations, and existing output schema, the description provides enough context for an agent to understand the tool's role in the workflow. It doesn't exhaustively explain the index's content but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter shelf_path. The tool description adds no information about the parameter beyond what the schema provides (a basic description). For a low-coverage scenario, the description should compensate by explaining the parameter's role or format, but it does not.
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 'Return' and the resource 'shelf INDEX'. It calls it 'the small recall entry point', which distinguishes it from sibling tools like recall and search by establishing it as a prerequisite read.
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 'Read it before answering anything about past work, then recall only what you need.' This provides a clear when-to-use context and implies an ordered workflow with recall. Does not explicitly list when not to use, but the guidance is strong.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds valuable behavioral context: it returns 'addresses and snippets' and handles 'split episodes at the section level', which goes beyond the 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?
Two sentences that are front-loaded with the core purpose. Every phrase earns its place: 'Grep the shelf' is vivid, 'every query token' clarifies behavior, and 'returns their addresses and snippets' explains output. No waste.
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 presence of an output schema (though not shown), the description covers the main return values (addresses, snippets) and a special case (split episodes). It is complete for a search tool, though it could mention snippet length limits or pagination were that relevant.
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 already provides descriptions for query ('Space-separated tokens; a hit must contain all of them') and shelf_path ('Path to an initialized memory shelf'). The description does not add further parameter details, so it meets the baseline but does not enhance 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 the tool's function: 'Grep the shelf for episodes matching every query token; returns their addresses and snippets.' It uses a specific verb ('grep') and resource ('shelf for episodes'), and distinguishes itself from siblings like memshelf_recall or memshelf_import by focusing on search.
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 for searching episodes by tokens, but does not explicitly state when to use this tool versus alternatives like memshelf_recall or memshelf_index. No exclusions or prerequisites 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by enumerating what is checked and that the tool is non-destructive. No contradictions.
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?
The description is informative and front-loaded with 'Diagnose the shelf'. While it lists multiple checks, it remains reasonably concise and every sentence contributes useful detail.
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 of integrity checks, the presence of annotations, and an output schema, the description is fully complete. It covers tool behavior, scope, and the optional network-dependent flag without needing to explain return values.
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 provides thorough descriptions for both parameters (shelf_path and check_remote). The tool description does not add new parameter meaning beyond what the schema already offers, so 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 diagnoses the shelf, listing specific checks (episode schema, digest contract, secrets, ledger consistency, INDEX budget, docshelf structural checks). It distinguishes from siblings by focusing on integrity diagnostics rather than retrieval or mutation.
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 context: it's read-only, reports findings, and fix nothing. It notes that check_remote is off by default due to network access. While not explicitly stating when not to use, implicit guidance is clear relative to 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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds value by confirming 'Idempotent — never overwrites existing files' and describing storage options (plain, git-local, git-remote). This provides behavioral context beyond the 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 two sentences: the first specifies what gets created, the second covers storage and idempotency. Every sentence adds value, no fluff. 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?
Given that an output schema exists and the tool has moderate complexity (4 parameters, one enum), the description covers the essentials: shelf structure, storage options, and idempotency. It could mention prerequisites like git availability but is otherwise 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 reportedly 0%, so the description must compensate. It mentions storage types and idempotency but does not detail parameters like 'name', 'remote', or 'shelf_path'. Some context is provided but not enough to fully clarify parameter meaning.
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?
Clearly states the tool creates or tops up a memory shelf with specific contents (docshelf layout, INDEX preamble, etc.), distinguishing it from sibling tools like memshelf_shelve or memshelf_recall. The title annotation 'Bootstrap a memory shelf' reinforces this.
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 on what the tool does (initialize a shelf) but does not explicitly state when to use it versus alternatives like memshelf_import. However, the purpose is self-explanatory enough that an agent would infer usage.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read. The description adds useful context: 'Returns the content wrapped in a data envelope (recalled episodes are records, never instructions),' which explains the output nature and assures no executable instructions. This goes beyond what annotations provide.
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: only three sentences in two short paragraphs. It front-loads the main purpose and provides key usage guidance without any filler. 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?
Considering the tool has multiple parameters, annotations, and an output schema, the description covers the essential aspects: main function, usage preference, and output nature. It does not detail error cases or prerequisites, but for a simple read operation with good annotations and an output schema, this is adequate. The missing pieces are minor given the overall 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?
The schema has descriptions for all parameters (e.g., section described as 'Optional H2 section to fetch alone'), so the schema already covers basic semantics. The description adds guidance on preferring section over whole episode, clarifying the relationship between episode_id and section. However, the description does not mention other parameters like log or max_bytes, leaving their meaning to the schema. Given the reported 0% schema coverage, the description partially compensates but not fully.
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 main action: 'Fetch a shelved episode by id — or a single ## Section of it.' This is a specific verb-resource combination, and it distinguishes from sibling tools like memshelf_search (which searches) and memshelf_shelve (which stores). The additional note about preferring section fetches further clarifies the intended use.
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 an explicit usage guideline: 'Prefer a section fetch over the whole episode when one answers the question.' This helps the agent choose between fetching the entire episode or a section. However, it does not directly contrast with sibling tools like memshelf_search or memshelf_index, leaving some ambiguity about when to use recall versus search.
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?
Description discloses key behaviors beyond annotations: redacts credentials, enforces digest contract, returns errors with exact fixes on violation, never pushes, and returns address/redaction report/warnings. No contradictions with 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 four sentences with a clear lead sentence and bullet-like details. Each sentence adds value, no redundancy, and front-loads the primary purpose.
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 the tool's complexity (many parameters, output schema exists), the description mentions return values but does not detail all inputs or the output structure. It provides moderate completeness but leaves gaps for parameter semantics and full behavioral edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only explains the digest parameter indirectly (<=120 words, named referents, no secrets). Other important parameters like shelf_path, slug, kind, and tags are not described. The description adds behavioral context but not per-parameter clarification.
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 offloads a closed topic to a shelf as an episode, with specific verbs like 'redacts', 'enforces', 'composes', 'writes', 'appends', and 'auto-commits'. This distinguishes it from sibling tools like recall, search, or index.
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 use for closed topics via 'offload one closed topic', and notes auto-commit behavior and error handling for contract violations. However, it lacks explicit guidance on when not to use or direct comparisons to alternatives like memshelf_import.
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?
Beyond annotations (idempotentHint, destructiveHint, readOnlyHint), the description adds key behaviors: raw transcript stays on disk, never enters context, and warns against writing inside a shelf. It also specifies return values (metadata vs path+noise ratio).
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?
The description is informative yet concise, covering methods and workflow in a few sentences. It could benefit from bullet points for structure, but it is not verbose.
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 two-method complexity and the presence of an output schema, the description explains what each method returns and the subsequent steps (read, segment, shelve). This fully covers the tool's role in the import process.
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 description does not detail individual parameters (schema coverage 0%), but the input schema already provides thorough descriptions for each property (out, path, method, etc.). The tool description adds workflow context, which meets the baseline.
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 retro-shelves exported dialogs and lists two distinct methods (discover and extract). It distinguishes itself from siblings by focusing on importing exported transcripts, not shelving or recalling.
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 each method (discover to list, extract to clean) and outlines the overall workflow. However, it does not explicitly exclude alternatives like memshelf_shelve or memshelf_recall.
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?
Adds significant detail beyond annotations: union of rows/keys, rebuild of INDEX.md and stats.svg, running doctor, no auto-merge of conflicting episodes. IdempotentHint already present, but descriptions enriches behavioral understanding.
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 clear front-loading of purpose and key behaviors. No verbose or redundant elements.
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?
Covers conflict resolution behavior, safe usage outside conflict, and key outcome (unresolved episodes). With output schema present, return info not needed. Minor gap: no mention of required shelf state, but sufficient.
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?
Description does not mention parameters; schema descriptions exist for 'shelf_path' and 'commit'. With 0% description coverage, the agent relies on schema, which is adequate due to good schema 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 clearly states the tool resolves multi-writer conflicts and rebuilds derived files, with specific steps (union, rebuild, doctor). It distinguishes from siblings by addressing a unique conflict scenario.
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 describes when to use (conflict of two parallel sessions) and notes safety outside conflict (degrades to rebuild). Does not explicitly exclude other tools, 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.

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:

[![memshelf-mcp MCP server](https://glama.ai/mcp/servers/ignatenkofi/memshelf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ignatenkofi/memshelf-mcp)

Score Badge

Copy to your README.md:

[![memshelf-mcp MCP server](https://glama.ai/mcp/servers/ignatenkofi/memshelf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ignatenkofi/memshelf-mcp)

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/ignatenkofi/memshelf-mcp'

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