How do I use Unified Memory MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unified Memory MCP remember I use pnpm for JavaScript projects" 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.

Unified Memory MCP

by yksanjo

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Unified Memory MCP

Local, explicit memory vault exposed as an MCP server. It is meant to give Codex, ChatGPT Apps, and your own agent clients a shared memory layer without relying on private product memory crossing surfaces automatically.

What It Does

Stores memories in ~/.unified-memory-mcp/memories.json.
Writes a minimal audit log to ~/.unified-memory-mcp/events.jsonl.
Exposes MCP tools over stdio.
Hides sensitive: true memories from default read/search/list calls.
Keeps the storage format human-readable and easy to back up or inspect.

Related MCP server: Codex Memory

Tools

remember: create a memory.
search_memory: search active memories by text and filters.
list_memories: list recent memories.
get_memory: fetch a memory by id.
update_memory: patch an existing memory.
forget_memory: hard-delete a memory.
memory_stats: show vault paths and aggregate counts.

Memory Shape

{
  "id": "mem_...",
  "type": "preference",
  "scope": "personal",
  "namespace": "default",
  "content": "Prefer pnpm over npm for JavaScript projects.",
  "tags": ["javascript", "package-manager"],
  "source": "manual",
  "confidence": 0.8,
  "sensitive": false,
  "created_at": "2026-07-04T00:00:00.000Z",
  "updated_at": "2026-07-04T00:00:00.000Z",
  "expires_at": null,
  "metadata": {}
}

Allowed type values: preference, project, workflow, fact, decision, context, rule.

Allowed scope values: personal, company, repo, project, global.

Local Usage

cd /Users/yoshikondo/unified-memory-mcp
npm test
npm run smoke
npm run smoke:http

Run the MCP server directly:

MEMORY_MCP_HOME=/Users/yoshikondo/.unified-memory-mcp node /Users/yoshikondo/unified-memory-mcp/src/server.js

Run the optional Streamable HTTP MCP server:

MEMORY_MCP_HOME=/Users/yoshikondo/.unified-memory-mcp \
MEMORY_MCP_HOST=127.0.0.1 \
MEMORY_MCP_PORT=3199 \
npm run http

The HTTP endpoint is http://127.0.0.1:3199/mcp; health is available at http://127.0.0.1:3199/health.

If you bind to anything other than localhost, set MEMORY_MCP_TOKEN and put the service behind HTTPS before connecting remote clients.

Codex Setup

Add this to ~/.codex/config.toml:

[mcp_servers.unified_memory]
command = "node"
args = ["/Users/yoshikondo/unified-memory-mcp/src/server.js"]
startup_timeout_sec = 10
tool_timeout_sec = 30

[mcp_servers.unified_memory.env]
MEMORY_MCP_HOME = "/Users/yoshikondo/.unified-memory-mcp"

Restart Codex after changing MCP config.

Privacy Notes

Do not store secrets, credentials, private keys, API tokens, or raw sensitive personal data. Mark entries sensitive: true only as an extra visibility guard; it is not encryption.

This is separate from built-in ChatGPT memory and Codex memory. It is an explicit source of truth that clients can connect to through MCP.

For ChatGPT, this is the backend MCP surface. You still need a ChatGPT App or remote MCP deployment with HTTPS and appropriate auth before ChatGPT web can use it.

Available Tools

7 tools

forget_memoryForget MemoryB

Destructive

Hard-delete a memory entry from the local vault.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`reason`	No

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds 'Hard-delete' complementing the destructiveHint=true annotation by clarifying irreversibility. However, it does not disclose other behavioral traits like permission requirements or cascade effects, so it provides moderate value beyond annotations.

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 a single sentence with no wasted words. It is front-loaded and efficient, though it could benefit from additional detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0% schema description coverage, no output schema, and two parameters, the description is insufficient. It omits explanations for parameters (especially 'reason') and return behavior, leaving significant gaps for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the purpose of the 'reason' parameter or provide any guidance on parameter usage. The description adds no meaning beyond the schema's raw property definitions.

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 'Hard-delete a memory entry from the local vault.' clearly states the action (hard-delete), the resource (memory entry), and the scope (local vault), making it specific and distinguishable from siblings like update_memory or search_memory.

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer this over update_memory (soft delete) or other tools, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoryGet MemoryA

Read-onlyIdempotent

Fetch one active memory by id. Sensitive memories are hidden unless include_sensitive is true.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`include_sensitive`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds value by disclosing that sensitive memories are hidden by default and require the include_sensitive flag to be visible, which is beyond annotation details.

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 no fluff. Every sentence provides essential information: what the tool does and a key behavioral condition.

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 (fetch by id) and the presence of annotations covering safety, the description is largely complete. It covers the main behavioral nuance (sensitive memories) but could mention error handling or id format. No output schema exists, so return values are not detailed.

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 0% description coverage, so the description carries the burden. It explains the effect of 'include_sensitive' but does not describe the 'id' parameter beyond its implied role. This adds some value but leaves the id parameter undocumented.

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 'Fetch', the resource 'one active memory', and the unique identifier 'by id'. It is specific and distinguishes this tool from siblings like list_memories or search_memory.

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 when to use the include_sensitive parameter ('Sensitive memories are hidden unless include_sensitive is true'). It does not explicitly mention when not to use the tool or alternatives, 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.

list_memoriesList MemoriesB

Read-onlyIdempotent

List recent active memories with optional filters. Sensitive memories are excluded by default.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Require all listed tags.
`type`	No	Restrict to a memory type.
`limit`	No	Maximum results, up to 100.
`scope`	No	Restrict to a scope.
`namespace`	No	Restrict to a namespace.
`include_expired`	No	Include expired memories.
`include_sensitive`	No	Include memories marked sensitive.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. Description adds that sensitive memories are excluded by default and focuses on recent active ones, but lacks detail on ordering or default limit.

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?

Single sentence, front-loaded with the main action. Efficient but could be structured with bullet points for clarity.

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 7 parameters and no output schema, the description covers core functionality but misses details like default limit, ordering, or what 'recent' means. Adequate but not comprehensive.

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 descriptions for all 7 parameters. Description adds no additional parameter information beyond 'with optional filters', 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?

Description clearly states it lists recent active memories with optional filters, distinguishing from sibling tools like search_memory (search vs list) and remember (create).

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?

No guidance on when to use this tool vs alternatives like search_memory. Does not specify when to include sensitive or expired memories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_statsMemory StatsB

Read-onlyIdempotent

Return vault paths and aggregate counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds what is returned but lacks detail on data format or aggregation semantics.

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?

Single sentence is concise and front-loaded. However, it is very brief and could be slightly more informative without loss of conciseness.

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 tool with no parameters and strong annotations, the description is minimally adequate but does not explain what 'vault paths' are or how counts aggregate.

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?

No parameters exist, and schema coverage is 100%. Baseline 3 applies; description adds no parameter info beyond the 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?

Description uses specific verb 'Return' and distinguishes resource 'vault paths and aggregate counts'. This clearly differentiates from sibling tools like list_memories or remember.

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?

No guidance on when to use this tool versus alternatives like list_memories or search_memory. Use cases are implicit but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rememberRememberB

Create a durable memory entry in the local vault.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Lower-friction labels used for filtering.
`type`	No	Kind of memory.
`scope`	No	Who or what this memory applies to.
`source`	No	Where this memory came from.
`content`	Yes	The memory content to store.
`metadata`	No	Small JSON object for source references or app metadata.
`namespace`	No	Project, company, repo, or user namespace.
`sensitive`	No	Hide from default search/list/get results.
`confidence`	No	Confidence from 0 to 1.
`expires_at`	No	Optional ISO timestamp when the memory expires.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds minimal behavioral context beyond 'durable' and 'local vault'. It does not disclose side effects, idempotency, or what happens on duplicate creation.

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 a single, concise sentence that covers the core function without unnecessary words.

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 has 10 parameters and no output schema, the description is minimal. It provides no information about return values or parameter interactions, though the schema is detailed. Adequate for a simple create operation but lacks depth.

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 is 3. The description does not add extra meaning; all parameter details are already in the input 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 the verb 'Create' and the resource 'durable memory entry in the local vault'. It effectively distinguishes from sibling tools like search_memory, list_memories, and forget_memory which have different 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or contrast with siblings like update_memory or search_memory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_memorySearch MemoryA

Read-onlyIdempotent

Search active memory entries by query and filters. Sensitive memories are excluded by default.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Require all listed tags.
`type`	No	Restrict to a memory type.
`limit`	No	Maximum results, up to 100.
`query`	No	Search text. Empty query returns recent matches for filters.
`scope`	No	Restrict to a scope.
`namespace`	No	Restrict to a namespace.
`include_expired`	No	Include expired memories.
`include_sensitive`	No	Include memories marked sensitive.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds key behavior beyond annotations: sensitive memories excluded by default, empty query returns recent matches. Annotations indicate read-only, idempotent, non-destructive; description complements well.

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 short sentences, no fluff, front-loaded with action and resource.

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?

Covers all essential behavioral aspects for a search tool with no output schema; explains default exclusion and query behavior.

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 100% of parameters, but description adds context about include_sensitive default and query behavior with empty string.

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 it searches memory entries by query and filters. Distinguishes from sibling tools like list_memories and get_memory by emphasizing search capability.

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 context for when to use (searching by query/filters) but lacks explicit exclusion or comparison with sibling tools like list_memories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_memoryUpdate MemoryB

Patch an existing memory entry by id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`tags`	No
`type`	No
`scope`	No
`source`	No
`content`	No
`metadata`	No
`namespace`	No
`sensitive`	No
`confidence`	No
`expires_at`	No

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate not read-only, not idempotent, and not destructive. The description adds only 'Patch' which implies mutation, but fails to disclose any behavioral traits such as side effects, permission requirements, or idempotency details. Minimal value beyond annotations.

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 a single concise sentence with no wasted words. However, it is too brief given the tool's complexity (11 parameters, nested objects, enums), resulting in under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and no parameter descriptions, the description fails to provide a complete picture. It omits return values, parameter constraints, and behavioral context, making it insufficient for agent understanding.

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%. With 11 parameters, the description only mentions 'by id' which is trivial given the required id field. No additional meaning is provided for other parameters like tags, content, type, scope, etc.

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 'Patch an existing memory entry by id,' using a specific verb and resource. It clearly distinguishes from sibling tools like remember (create), forget_memory (delete), list_memories, search_memory, and get_memory.

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 modifying an existing memory entry, but provides no explicit guidance on when to use it versus alternatives like remember or direct update. No when-not or exclusion criteria are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jul 30, 2026
- First observedforget_memory
- First observedget_memory
- First observedlist_memories
- First observedmemory_stats
- First observedremember
- First observedsearch_memory
- First observedupdate_memory

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: stats, create, search, list, get, update, delete. No overlaps, and sensitive memory handling is consistently described.

Naming Consistency3/5

Naming is inconsistent: most tools follow verb_noun pattern (search_memory, list_memories, etc.), but 'memory_stats' is noun_verb and 'remember' is just a verb, breaking the pattern.

Tool Count5/5

7 tools cover essential memory operations (CRUD, search, list, stats) without being excessive or insufficient.

Completeness5/5

Full CRUD lifecycle plus search and statistics. Sensitive memory handling is integrated. No obvious gaps for a memory vault.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
19212
OpenAkashic A
io.github.szara7678
Shared long-term memory vault for AI agents with 20 MCP tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
3523
ContextLattice
io.github.sheawinkler
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Knowledge & Memory Agent Orchestration Autonomous Agents
2153
Multinex MemQOAuth
ai.multinex
Persistent memory for AI agents with OAuth-backed hosted MCP access.
Knowledge & Memory AI & Machine Learning
2

Related MCP Servers

CoreMemory-MCP
Knowledge & Memory Autonomous Agents
michaelfeng
A
license
Not graded
quality
C
maintenance
Provides a local, persistent long-term memory service for MCP-compatible AI agents, enabling them to store, search, and recall information across sessions.
Updated a year ago (2025-09-25 23:55 UTC)
1
GPL 3.0
Codex Memory
Knowledge & Memory Search
zhangtian-123
A
license
B
quality
D
maintenance
Local Markdown-backed memory tools for Codex and other MCP-capable agents. Exposes durable agent knowledge via CLI and MCP server.
Updated 3 months ago (2026-06-12 12:50 UTC)
5
MIT
Enigma MCP Serverofficial
Knowledge & Memory Search
Enigma-Memory
A
license
Not graded
quality
A
maintenance
Offers MCP tools for managing a local AI memory vault, including remembering, searching, context packing, deletion, and verification of receipts.
Updated 15 days ago (2026-08-22 00:04 UTC)
206
1
Apache 2.0
mechabrain
Knowledge & Memory Search
bbarrosdavi
A
license
Not graded
quality
B
maintenance
MCP server that provides agentic memory management for markdown vaults, enabling hybrid search, governed writing, and maintenance of episodic, semantic, procedural, and working memories for LLM agents.
Updated a month ago (2026-07-26 16:12 UTC)
MIT

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/yksanjo/unified-memory-mcp'

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

Unified Memory MCP

What It Does

Tools

Memory Shape

Local Usage

Codex Setup

Privacy Notes

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Enigma MCP Serverofficial

Latest Blog Posts

MCP directory API