Supports routing responses through Archestra gateway with OpenAI models for enhanced performance.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Personal Memory Gateway Query my notes about the MCP hackathon"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Privacy-First Memory Layer for AI.
Seamlessly bridge your local knowledge with any AI assistant through a secure, MCP-compatible gateway.
Get up and running in seconds with zero configuration:
npx @shubham-01-star/pmg initRelated MCP server: M3 Memory
Personal Memory Gateway (PMG) is a local-first backend designed to store, manage, and serve your personal knowledge to AI models. It acts as a secure "VPN for your memory," ensuring that sensitive data is redacted and privacy is gated before any context is shared.
MCP Tool Integration: Seamlessly connects to Cursor, Claude Desktop, and other MCP clients via query_personal_memory and save_memory tools.
Privacy-First Ingestion: Automatically watches local directories, chunks documents, and stores them in a local vector database (LanceDB).
Intelligent Redaction: Applies a multi-stage pipeline to redact PII and sensitive information before retrieval.
Archestra Integration: Optionally route responses through high-performance gateways like Archestra (supporting Gemini/OpenAI).
Telemetry Dashboard: Monitor system health and manage your indexed data through a built-in web interface.
graph TD
A[Local Files] -->|Ingestion| B(Chunking & Embedding)
B -->|LanceDB| C[Vector Repository]
D[MCP Client] -->|Query| E[Privacy Pipeline]
E -->|Redaction| F[Consent Gate]
F -->|Context| G[AI Model]
C -->|Retrieval| Enpm i -g @shubham-01-star/pmg
pmg init
pmggit clone https://github.com/shubham-01-star/pmg.git
cd pmg
npm install
npm run build
npm run runAdd PMG to your mcpServers configuration:
{
"mcpServers": {
"pmg": {
"command": "npx",
"args": ["-y", "@shubham-01-star/pmg"],
"env": {
"INGEST_DIR": "/path/to/your/data",
"LANCE_DB_PATH": "/path/to/lancedb/storage"
}
}
}
}Variable | Description | Default |
| Directory to watch for memory files |
|
| Enable Archestra integration ( |
|
| Embedding model source ( |
|
| Port for the telemetry dashboard |
|
| Enable PII redaction pipeline |
|
Once running, access the telemetry dashboard at: 👉 http://localhost:8787/dashboard
Monitor: Real-time events and memory retrieval stats.
Manage: Upload new documents or clear existing memories.
Status: Visual health probes for all internal services.
PMG includes a comprehensive suite of smoke tests and backend validations.
# Run backend smoke suite
make test-backend
# Integrated flow test
node scripts/one-command-flow.mjs "topic" "path/to/sample.txt"Distributed under the MIT License. See LICENSE for more information.
Search local memory and return privacy-filtered personal context for a topic. MUST call this tool when user asks to query memory, asks personal preference/history, or explicitly says 'call tool query_personal_memory'. Do not skip tool call in those cases.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The specific topic, keyword, or question to search for in memory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral details. It mentions 'privacy-filtered' but doesn't explain side effects, permissions, or what happens on missing topic. Adequate but lacks key transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource. Second sentence provides clear usage rules. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 required param, no output schema, the description tells purpose and use cases well. Lacks return format details, but overall fairly complete for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers topic fully. Description adds no parameter-specific info beyond schema. Goal of description to add value beyond schema is not met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search local memory and return privacy-filtered personal context'. Verb-resource pair is specific. Distinguishes from sibling 'save_memory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: user asks to query memory, personal preference/history, or explicit tool invocation. Includes directive not to skip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new fact, preference, or piece of information to the user's permanent memory. MUST call this tool when user says 'remember this', 'save this', or explicitly says 'call tool save_memory'. Do not reply with a normal answer before attempting the tool call.
| Name | Required | Description | Default |
|---|---|---|---|
| fact | Yes | The content to remember (e.g. 'User prefers Python', 'Project Alpha deadline is Dec 25'). | |
| category | No | A category tag for organization (e.g. 'coding_style', 'personal_info', 'work'). Defaults to 'general'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes an additive write operation (not destructive) but does not disclose potential side effects like storage limits, overwrite behavior, or consistency guarantees. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then usage instructions. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers core usage and triggers. However, it omits details about memory management (e.g., editing, deletion, size limits), but for a save-only tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds value by clarifying that 'fact' is the content to remember and 'category' is a tag, and mentions the default category. This aids understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it saves a new fact, preference, or piece of information to permanent memory. It provides specific trigger phrases ('remember this', 'save this') and distinguishes from the sibling tool query_personal_memory by focusing on creation vs retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to call the tool (trigger phrases, explicit 'call tool save_memory') and instructs not to reply normally before attempting the call. This provides clear usage guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0query_personal_memorysave_memoryScored across 2 tools
The two tools have clearly distinct purposes: one for querying memory and one for saving memory. There is no overlap or ambiguity between them.
Both tool names follow the verb_noun pattern with underscores, using 'query' and 'save' as verbs and 'memory' as the object, which is consistent and predictable.
With only two tools, the set feels thin for a personal memory gateway. While it covers basic query and save operations, the number is at the low end of what might be expected.
The set lacks essential operations like updating, deleting, or listing memories, which are typical for managing personal memory. This gap can lead to agent failures when such operations are needed.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
AI memory layer — one shared, persistent memory across every AI tool you connect.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
