The agentram-mcp server provides persistent, cloud-backed memory for AI agents via the AgentRAM API. It offers the following capabilities:
Personal Agent Memory
Store a memory: Save a key-value pair for a specific agent, with an optional expiry (ttl_days). Overwrites existing keys without duplicates.
Retrieve a memory: Fetch a stored value by agent ID and key.
List memories: Get all memories for an agent, sorted newest first (up to 200), with expired entries excluded.
Search memories: Perform a case-insensitive text search across both keys and values — no embeddings or vector setup required.
Delete a memory: Permanently remove a specific memory by agent ID and key.
Shared Multi-Agent Memory
Create a namespace: Create a shared memory pool (free) that multiple agents can read from and write to.
Store shared memory: Write a key-value pair into a shared namespace, accessible by any agent with the namespace key.
Retrieve shared memory: Read a value from a shared namespace by key.
List shared memories: List all entries in a shared namespace, sorted by most recent.
Utility
Check credits: View your current AgentRAM account balance. This call is free.
Most operations cost 1 credit each.
Click on "Install 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., "@agentram-mcp Store that my favorite color is blue"
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.
MCP server for AgentRAM. It gives your AI agents persistent memory through a set of tools, with no vector database and no embedding pipeline to set up. Get a key, paste the config below, and you're running in about a minute.
Works with any MCP client: Claude Desktop, Claude Code, Cline, Cursor, Windsurf, and others.
Every agent session starts with amnesia. AgentRAM is a plain HTTP memory store built for agents: one call to save something, one call to read it back. No infra to stand up, no vectors to babysit. This package wraps that API as MCP tools so your agent can just use it.
Related MCP server: Librarian
You need an API key first. Register at agentram.dev and it gets emailed to you. New accounts start with 1,000 credits and no card is required.
Then add this to your client's MCP config. For Claude Desktop that file is claude_desktop_config.json (on macOS it lives at ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"agentram": {
"command": "npx",
"args": ["-y", "agentram-mcp"],
"env": {
"AGENTRAM_API_KEY": "agentram_your_key_here"
}
}
}
}Restart the client and the tools show up. Most clients let you mark them "always allow" so you're not clicking approve on every call.
One gotcha on macOS: Claude Desktop doesn't ship with Node, so install Node 18 or newer first or the server won't start.
Fifteen tools. Ten for flat memory, five for temporal memory (facts that change over time).
Flat memory:
store_memory: save a value under a key for an agent
retrieve_memory: read one back by key
list_memories: list everything stored for an agent
search_memories: text search across keys and values, no embeddings needed
delete_memory: remove one
check_credits: current balance, free to call
Shared memory, for when more than one agent needs the same pool:
create_namespace: make a shared space, free to call
store_shared_memory: write into it
retrieve_shared_memory: read from it
list_shared_memories: list what's in it
Temporal memory (assertions):
store_assertion: record a fact that can change, like a plan, a status, or a preference
retire_assertion: mark a fact as no longer true while keeping the history
get_assertion: what's currently true for a key
list_assertions: all the current facts for an agent
get_assertion_history: the full chain of what a key has been over time
Flat memory overwrites. Temporal memory keeps the trail. When a fact changes you supersede the old value, and the previous values stick around so you can see how you got to the current one.
The part worth knowing: if two different values land on the same key and neither one supersedes the other, get_assertion will not quietly pick a winner. It tells you the key is contested and returns both values, so your agent can decide instead of running on a guess. list_assertions flags which keys are in that state.
Flat and temporal are separate keyspaces. A key called plan in store_memory and a key called plan in store_assertion have nothing to do with each other. Use flat memory for stuff you just overwrite, and assertions for facts you want a record of.
Reads and writes cost 1 credit each. check_credits and create_namespace are free. A read that finds nothing (a 404) refunds the credit. Most responses include your credits_remaining so you can watch the balance.
AGENTRAM_API_KEY (required): your key, starts with agentram_
AGENTRAM_API_BASE (optional): defaults to https://api.agentram.dev
Site: https://agentram.dev
MIT
Create a shared memory namespace that multiple agents can read from and write to. Returns a namespace_key to share with each agent. Free to call (no credit deducted).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional human-readable name. Max 100 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the call is free and returns a key, but does not mention potential limits, permissions, or side effects. Adequate but not rich.
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?
Three concise sentences: purpose, return value, cost. Each sentence adds distinct value with no redundancies or fluff.
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?
For a simple tool with no required parameters and no output schema, the description explains creation and return of namespace_key. It lacks a hint on how to use the key with sibling tools, but overall sufficient for basic understanding.
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 description coverage is 100% for the single optional parameter 'label'. The description does not add further meaning beyond what the schema already provides, meeting baseline.
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 uses a specific verb (create) and resource (shared memory namespace), and clearly states the return value (namespace_key). It distinguishes from siblings like store_memory or list_memories, which operate on memories within a namespace.
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?
The description implies usage for multi-agent shared memory but does not explicitly state when to use this tool versus alternatives (e.g., store_memory to write, retrieve_memory to read). No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a stored memory. Cannot be undone. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The memory label to delete. | |
| agent_id | Yes | The agent identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds critical behavioral context: 'Cannot be undone' (destructiveness) and 'Costs 1 credit' (cost). This goes beyond the basic delete action, though it doesn't detail permissions or side effects.
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 concise sentences with no fluff; front-loaded with the key action and constraints.
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?
For a simple delete operation, the description covers permanence and cost. No output schema exists, but the description does not need to explain return values. It could mention that the memory must exist, but it is adequate.
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% with clear descriptions for both parameters. The tool description does not add extra meaning beyond the schema, so baseline score applies.
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 the specific action ('Permanently delete a stored memory') and the resource ('memory'), which distinguishes it from sibling tools like store_memory, retrieve_memory, etc.
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?
The description implies usage for deletion but does not specify when to use vs. alternatives like update or disable, nor does it mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all memories stored under an agent ID, ordered by most recently written. Expired memories are excluded. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. Default 50, max 200. | |
| agent_id | Yes | The agent identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses ordering, expiry exclusion, and credit cost. Does not mention authentication or response format, but acceptable for a simple read operation.
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?
Three sentences, no redundancy, front-loaded with key information. Every sentence adds value.
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 tool simplicity (2 params, no output schema), description sufficiently covers core behavior and constraints. Minor lack of response format detail but not critical.
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 baseline is 3. Description adds value by explaining ordering and expiry behavior beyond schema descriptions, and mentions cost.
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 the tool lists memories under an agent ID with ordering and expiry. Distinguishes from siblings like list_shared_memories (shared vs own) and retrieve_memory (single vs list).
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?
Provides clear usage context: lists all memories for an agent, ordered, excluding expired, and costs 1 credit. Lacks explicit when-not-to-use but siblings offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a stored memory by agent ID and key. Returns 404 (and refunds the credit) if the memory does not exist. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The memory label to retrieve. | |
| agent_id | Yes | The agent identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully bears burden. Discloses cost, credit refund on 404, and read-only nature implicitly. Missing details on idempotency but adequate for a simple retrieval.
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?
Three focused sentences: purpose, error handling, cost. No waste, front-loaded with essential info.
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?
Lacks description of successful return format (e.g., the memory value). No output schema to compensate, leaving agents to infer structure. Otherwise covers key aspects.
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 baseline 3. Description adds no additional meaning beyond schema descriptions for agent_id and key.
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 'Retrieve a stored memory by agent ID and key' with specific verb and resource. Distinguishes from siblings like retrieve_shared_memory and search_memories.
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?
Provides explicit behavior on missing memory (404 and credit refund) and states cost of 1 credit, helping agents decide when to call. No explicit when-not-to-use but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a value under a key for a given AI agent. Writing to an existing key updates the value (no duplicates created). Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory label. Max 200 characters. | |
| value | Yes | What to remember. Max 5,000 characters. | |
| agent_id | Yes | Unique identifier for the agent. Max 100 characters. | |
| ttl_days | No | Optional. Days until this memory expires automatically. Omit for permanent memories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that writing updates existing values (no duplicates) and costs 1 credit, but lacks details on side effects, rate limits, or authentication requirements.
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 key action, zero wasted words. Each sentence adds value: first states purpose, second clarifies update behavior and cost.
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?
No output schema and description omits return value, error conditions, or prerequisites. For a mutation tool, expected to at least hint at response, but none provided.
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 documents all parameters. The tool description adds no additional semantic meaning beyond what's in the schema properties.
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?
Description clearly states verb 'store' and resource 'value under a key for a given AI agent'. It distinguishes from sibling tools by specifying that writing to an existing key updates the value (no duplicates), which differentiates it from retrieval operations like retrieve_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?
The description implies usage for creating or updating memories but does not explicitly state when to use this vs alternatives like retrieve_memory or delete_memory. No guidance on prerequisites or when not to use.
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. Dates show when Glama detected each change.
v0.1.1check_creditslist_shared_memoriesretrieve_shared_memorysearch_memoriesv0.1.0check_creditscreate_namespacedelete_memorylist_memorieslist_shared_memoriesretrieve_memoryretrieve_shared_memorysearch_memoriesstore_memorystore_shared_memoryTools are clearly separated into personal memory operations and shared namespace operations, with distinct prefixes. No overlapping purposes; each tool targets a unique action-resource combination.
All tool names follow a consistent snake_case verb_noun pattern (e.g., store_memory, list_shared_memories), making them predictable and easy to group.
10 tools is well-scoped for a memory management system covering both personal and shared memory CRUD plus credits and namespace creation. It feels complete without being overwhelming.
CRUD is fully covered for personal memories (store, retrieve, list, search, delete). Shared memories have store, retrieve, and list but lack a delete operation, which is a minor gap.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Shared long-term memory vault for AI agents with 20 MCP tools.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seanmarkwei/agentram-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
