What can you do with this server?

Sharpwave is an MCP server providing AI agents with persistent long-term memory using a graph-based system with forgetting curves, spaced repetition, consolidation, and hybrid retrieval. * Store memories (brain_write) with types (identity, semantic, episodic, pattern, skill, goal, emotion, procedural, schema), importance scores, and emotional weight. New memories are auto-queued for embedding and auto-linking. * Search and recall (brain_query) using hybrid full-text search, vector similarity (optional), and graph spreading activation, with results ranked by retrievability and salience. Filter by memory type. * Link memories (brain_link) with typed directional edges (e.g., caused_by, supports, contradicts, supersedes, instance_of, drives) to build a knowledge graph. * Replace outdated memories (brain_supersede) to supersede stale nodes with updated content, preserving temporal integrity by closing old edges and writing a supersedes link. * Inspect memory details (brain_expand) to view full content, FSRS spaced-repetition metrics, encoding context, and source episodes. * Review memories (brain_review) using FSRS-6 spaced repetition based on recall quality (0–5 scale), updating stability, retrievability, and calibration. * Delete memories (brain_forget) with safe checks that refuse deletion of nodes with active edges unless forced. * Explore connections (brain_edges) to retrieve all active incoming and outgoing edges for a node. * Search episode history (brain_history) by keyword with optional time-range filtering. * Monitor brain statistics (brain_stats) including node/edge/episode counts, neuromodulator state, consolidation status, and embedding coverage. * Consolidate and synthesize memories automatically in the background, promoting patterns, synthesizing schemas, and downscaling noise (generative consolidation requires an LLM). * Isolate agent memories via SHARPWAVE_AGENT_ID for different agents or projects. * Configurable persistence using a local SQLite database, a configurable data directory, and optional remote embedding providers or local Ollama embeddings. * Receive update notifications about new Sharpwave versions (can be disabled).

Which integrations are available for this server?

Provides local embedding generation for semantic similarity searches using models like qwen3-embedding.

How do I use Sharpwave?

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., "@Sharpwave remember that I like rainy days" 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.

Sharpwave

by Enlightened-Republic

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Sharpwave is an MCP server providing AI agents with persistent long-term memory using a graph-based system with forgetting curves, spaced repetition, consolidation, and hybrid retrieval.

Store memories (brain_write) with types (identity, semantic, episodic, pattern, skill, goal, emotion, procedural, schema), importance scores, and emotional weight. New memories are auto-queued for embedding and auto-linking.
Search and recall (brain_query) using hybrid full-text search, vector similarity (optional), and graph spreading activation, with results ranked by retrievability and salience. Filter by memory type.
Link memories (brain_link) with typed directional edges (e.g., caused_by, supports, contradicts, supersedes, instance_of, drives) to build a knowledge graph.
Replace outdated memories (brain_supersede) to supersede stale nodes with updated content, preserving temporal integrity by closing old edges and writing a supersedes link.
Inspect memory details (brain_expand) to view full content, FSRS spaced-repetition metrics, encoding context, and source episodes.
Review memories (brain_review) using FSRS-6 spaced repetition based on recall quality (0–5 scale), updating stability, retrievability, and calibration.
Delete memories (brain_forget) with safe checks that refuse deletion of nodes with active edges unless forced.
Explore connections (brain_edges) to retrieve all active incoming and outgoing edges for a node.
Search episode history (brain_history) by keyword with optional time-range filtering.
Monitor brain statistics (brain_stats) including node/edge/episode counts, neuromodulator state, consolidation status, and embedding coverage.
Consolidate and synthesize memories automatically in the background, promoting patterns, synthesizing schemas, and downscaling noise (generative consolidation requires an LLM).
Isolate agent memories via SHARPWAVE_AGENT_ID for different agents or projects.
Configurable persistence using a local SQLite database, a configurable data directory, and optional remote embedding providers or local Ollama embeddings.
Receive update notifications about new Sharpwave versions (can be disabled).

Sharpwave

A long-term memory MCP server for AI agents. It remembers across sessions, forgets what stops mattering, and consolidates the rest — modeled on how human memory actually works, not a vector store with extra steps.

npx -y sharpwave

Works with Claude Code, Claude Desktop, Cursor, and any other MCP client.

Building on OpenClaw? Use openwave instead — the same engine as a native OpenClaw plugin. It does everything this MCP server does, plus it injects the relevant memories into every agent turn automatically (no tool call) and runs the sleep system in-process. openclaw plugins install npm:openwave

Repository layout

npm-workspaces monorepo, two packages:

packages/core — sharpwave-core, the memory engine (retrieval, consolidation, extraction, the FSRS forgetting curve, the graph). Published to npm as the shared engine behind both the sharpwave MCP server and the openwave OpenClaw plugin.
packages/mcp — sharpwave, the stdio MCP server. This is what npm i sharpwave / npx -y sharpwave installs.

The OpenClaw plugin lives in its own repo: Enlightened-Republic/openwave.

sharpwave-core is bundled into each consumer at build time, so sharpwave and openwave always ship the exact engine they were built against — there is no version-skew path between them. It is a devDependency of both consumers, not a runtime one — esbuild inlines it, and a runtime dep on an unpublished package would break every npm install sharpwave.

npm run test:pack is the pre-publish gate: it packs sharpwave, installs the tarball in a clean workspace-free directory (where a stray runtime dep on sharpwave-core would 404), and drives the installed server over MCP. Run it before every npm publish. It is not part of npm run test:all (slow, and the npm install touches the network).

Related MCP server: elephantasm-mcp

The problem

Your agent forgets everything the moment a session ends. The usual fix is to dump conversation history into a vector store and retrieve the nearest chunks — which works until it doesn't:

It never forgets. Every note lives forever at equal weight, so a throwaway remark from March competes with something that actually matters.
It has no structure. A pile of embeddings can tell you what's similar. It can't tell you what caused what, or that one fact replaced another.
Recall degrades as it grows. More memories means more near-matches, and precision falls off exactly when the memory becomes worth having.

Human memory doesn't work that way. It decays on a curve, strengthens what gets used, consolidates related things into concepts, and lets the rest fade. Sharpwave models that.

The name comes from sharp-wave ripples — the hippocampal events that replay and consolidate memories during rest. That's the mechanism this is built around, not a metaphor bolted on afterward.

What makes it different

A real forgetting curve. Every memory carries FSRS-6 stability and retrievability. Unused memories decay on a power-law curve and drop out of recall; reviewed ones strengthen. Importance and emotional weight scale how durable a memory starts out.

Consolidation, not just storage. A background pass replays recent episodes, promotes recurring patterns into durable semantic nodes, synthesizes clusters into higher-level schemas, and downscales the noise — modeled on slow-wave and REM sleep.

A graph, not a bag. Memories connect through typed edges — caused_by, supports, contradicts, supersedes, instance_of and more. Retrieval spreads activation across those edges, so recalling one thing surfaces what's genuinely related, not merely similar.

Memories can be replaced. brain_supersede closes out a stale memory and links the replacement, so the graph keeps its temporal integrity instead of accumulating contradictions.

Hybrid retrieval. Full-text search fused with vector similarity via reciprocal rank fusion, then spread across the graph. Vector search is optional — full-text and graph retrieval work with no embedding provider at all.

Multi-agent by design. One Sharpwave process can back any number of agents at once. Each agent's memories live in their own database — isolated, never cross-contaminated — under a single config entry.

Install

Sharpwave is a standard stdio MCP server. Point any MCP client at npx -y sharpwave.

Any MCP client

Add to the client's MCP config (claude_desktop_config.json, Cursor's mcp.json, or equivalent):

{
  "mcpServers": {
    "sharpwave": {
      "command": "npx",
      "args": ["-y", "sharpwave"]
    }
  }
}

Claude Code

claude mcp add sharpwave -- npx -y sharpwave

OpenClaw

openclaw mcp add sharpwave --command npx --arg -y --arg sharpwave
openclaw mcp doctor sharpwave --probe

Multi-agent

Leave SHARPWAVE_AGENT_ID unset and one Sharpwave process serves any number of agents: every brain_* call carries the calling agent's own agent id and is routed to its own database at ~/.sharpwave/<agent>/brain.db. SHARPWAVE_AGENTS (comma-separated) restricts which ids are accepted. To pin one server to a single agent, set SHARPWAVE_AGENT_ID=<id> — the agent argument then becomes optional, and if passed it must match.

Memory lands in ~/.sharpwave/ as a SQLite database. Nothing leaves your machine unless you configure a remote embedding provider.

Tools

Tool	What it does
`brain_query`	Search and recall memories using hybrid FTS + vector + spreading activation. Returns ranked nodes with retrievability and salience scores.
`brain_write`	Store a new memory node. Automatically queues for embedding and PRISM/NEXUS auto-linking.
`brain_link`	Create a typed edge between two existing nodes.
`brain_supersede`	Replace an outdated node with updated content. Closes old edges, writes a supersedes edge, preserving the memory graph's temporal integrity.
`brain_stats`	Return brain statistics: node/edge/episode counts, neuromodulator state, consolidation status, embedding coverage, observability counters.
`brain_history`	Search episode history (raw conversation turns) by keyword.
`brain_expand`	Get full detail for a specific node: content, FSRS metrics, encoding context, and source episodes.
`brain_review`	Apply an FSRS-6 spaced-repetition review to a node. Updates stability, retrievability, and SIGMA calibration.
`brain_forget`	Physically delete a node from the brain. Refuses to delete nodes with active edges unless `force=true`.
`brain_edges`	Get all active incoming and outgoing edges for a node.
`brain_reset`	Wipe an agent's brain back to empty (a `.db` backup is taken first). `confirm` must equal the agent id.

In multi-agent mode every tool above also takes a required agent argument.

Memory types

Every node is typed, and the type affects how it's consolidated and retrieved:

identity · semantic · episodic · pattern · skill · goal · emotion · procedural · schema

Configuration

All optional. Sharpwave runs with zero configuration.

Variable	Default	Purpose
`SHARPWAVE_DATA_DIR`	`~/.sharpwave`	Where the databases live
`SHARPWAVE_DB_PATH`	—	Full path to a specific database file, overriding `DATA_DIR`
`SHARPWAVE_AGENT_ID`	—	Pin the server to one agent. Leave unset for multi-agent mode — one server for the whole fleet, each `brain_*` call then requires an `agent` argument routing it to `<DATA_DIR>/<agent>/brain.db`.
`SHARPWAVE_AGENTS`	—	Multi-agent mode only: comma-separated allowlist of accepted `agent` ids
`SHARPWAVE_EMBEDDING_MODEL`	—	e.g. `ollama/qwen3-embedding:0.6b`
`OLLAMA_BASE_URL`	`http://localhost:11434`	Local embedding endpoint
`OPENROUTER_API_KEY`	—	Enables remote embeddings and generative consolidation
`SHARPWAVE_NO_UPDATE_CHECK`	—	Set to disable the update check entirely
`SHARPWAVE_OBSERVABILITY`	—	Set to `1` to enable JSONL event log at `${SHARPWAVE_DATA_DIR}/brain_events.jsonl`. Default OFF — zero overhead when unset.
`SHARPWAVE_EMBEDDING_CACHE_MAXSIZE`	`1024`	Max entries in the embedding LRU cache.
`SHARPWAVE_FTS_OPTIMIZE_EVERY`	`100`	Number of writes between automatic FTS5 `optimize` runs. Set to `0` to disable.

Update notifications

Once a day, Sharpwave asks the npm registry for its own latest version number and prints a single line to stderr if you are behind. It sends no identifiers and uploads nothing, runs after the server is already serving, and stays silent on failure — offline, blocked, or slow all resolve to no output.

To turn it off, set SHARPWAVE_NO_UPDATE_CHECK=1. It is also off automatically when CI or NO_UPDATE_NOTIFIER is set. With any of those, no request is made at all.

Enabling vector search

Full-text and graph retrieval work out of the box. Semantic similarity needs an embedding provider — the local option keeps everything on your machine:

ollama pull qwen3-embedding:0.6b

{
  "mcpServers": {
    "sharpwave": {
      "command": "npx",
      "args": ["-y", "sharpwave"],
      "env": {
        "SHARPWAVE_EMBEDDING_MODEL": "ollama/qwen3-embedding:0.6b",
        "OLLAMA_BASE_URL": "http://localhost:11434"
      }
    }
  }
}

For a cloud provider instead, set OPENROUTER_API_KEY and SHARPWAVE_EMBEDDING_MODEL=openai/text-embedding-3-small. Pick one and stay on it — switching embedding providers on an existing brain changes the vector dimension and needs a re-embed. See SETUP.md for the full walkthrough and verification steps.

Requirements

Node.js 22 or newer
macOS, Linux, or Windows (x64 and arm64; prebuilt native binaries, no compiler needed)

How retrieval works

Seed — full-text search over labels and content. Exact phrase first, then prefix-matched terms.
Fuse — if embeddings are available, vector search runs in parallel and the two rankings merge via reciprocal rank fusion. A 2-second cap means a slow or missing embedding provider degrades to full-text instead of hanging.
Spread — activation propagates across graph edges with lateral inhibition, so strongly-related memories surface and weak associations don't crowd the results.
Rank — final ordering weighs activation, salience, and FSRS retrievability, so a memory that's decayed past usefulness stays out of the way.
Touch — retrieved memories are marked as accessed, which strengthens them. Recall is itself a form of review.

Limitations

Worth knowing before you install:

Generative consolidation needs an LLM. REM-style schema synthesis and contradiction detection call OpenRouter. Without OPENROUTER_API_KEY the deterministic consolidation passes still run, but the generative ones are skipped.
Semantic similarity needs embeddings. Without a provider you get full-text plus graph retrieval — good, but not synonym-aware.
Single-writer per brain. SQLite with WAL. One server process per database; pointing two at the same file is not supported.
Consolidation is time-based. Memory quality improves as passes accumulate. A brand-new database is a plain store until it has history to work with.

Companion tools

The tools/ directory holds standalone Node scripts for memory maintenance and meta-reasoning. They operate on any Sharpwave brain database directly.

Script	Purpose
`tools/fractal-reason.mjs`	4-level reasoning closure (fix → pattern → flaw → meta-rule) over a correction
`tools/brain-link-bridge.mjs`	Turn a reasoning closure into `brain_write` + `brain_link` calls
`tools/memory-tiers.mjs`	5-tier compression lifecycle (full → summary → essence → ghost → metadata) for long-lived notes
`tools/engram-sleep.mjs`	Consolidation digest — pulls carry-closures, lessons and milestones out of daily logs
`tools/context-size.mjs`	Byte-budget dashboard across a memory directory
`tools/silent-failure-audit.mjs`	Lint for silent `catch` blocks
`tools/apply-fork-patch.mjs`	Atomic find/replace patch helper

License

MIT — see LICENSE.

Built by Enlightened Republic.

Available Tools

10 tools

brain_edgesB

Get all active incoming and outgoing edges for a node.

ParametersJSON Schema

Name	Required	Description	Default
`node_id`	Yes	Node ID to inspect

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, description must disclose behavior. 'Get' implies read-only, but no details on error states, performance, or guarantee of completeness (e.g., 'active' is mentioned but not defined). Minimal disclosure.

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, directly informative, no filler. Highly concise.

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?

Return format is not described (no output schema), and the concept of 'edges' should be clearer. However, for a simple one-parameter tool, it is minimally adequate.

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 covers 100% of parameters with a basic description. The tool description does not add extra semantic value beyond what the schema provides.

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 the action ('Get') and the resource ('edges for a node'), and the sibling tools suggest distinct operations, making its purpose unambiguous.

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 siblings like brain_query or brain_link is provided. Description lacks context about prerequisites or exclusions.

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

brain_expandB

Get full detail for a specific node: content, FSRS metrics, encoding context, and source episodes.

ParametersJSON Schema

Name	Required	Description	Default
`node_id`	Yes	Node ID to expand

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It states what data is returned but does not disclose behavioral traits such as read-only nature, error behavior, or performance implications. The description is minimally transparent.

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, focused sentence that front-loads the purpose and lists included details. Every word is necessary; no redundancy.

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

Completeness4/5

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

For a simple tool with one parameter and no annotations, the description is fairly complete. It covers what the tool returns. However, it could note if it is a read-only operation or if there are any side effects, which would improve completeness.

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

Parameters3/5

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

Schema description coverage is 100% for the single parameter node_id. The description adds no additional meaning beyond the schema, which already describes 'Node ID to expand'. 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 retrieves full detail for a specific node, listing specific data types: content, FSRS metrics, encoding context, and source episodes. This distinguishes it from sibling tools like brain_query (querying) and brain_stats (statistics).

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 does not provide guidance on when to use this tool versus alternatives like brain_query, nor does it mention any prerequisites or exclusions. The usage context is implied but not explicit.

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

brain_forgetA

Physically delete a node from the brain. Refuses to delete nodes with active edges unless force=true.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No	If true, also drops active edges (default false)
`node_id`	Yes	ID of the node to delete

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that deletion is physical and that the tool refuses to delete nodes with active edges unless force=true. This gives important behavioral context, though it could mention additional side effects or permissions.

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 sentence, front-loading the action. It is concise and contains no extraneous information.

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 (2 params, no output schema, no annotations), the description covers the core functionality and edge case (active edges). Missing details like error handling or response format, but overall adequate.

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 both parameters described. The description adds minimal extra meaning, merely reinforcing the force parameter's behavior from the schema. No significant new information 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?

The description clearly states the action ('Physically delete a node') and the specific resource (the brain node). It also adds a behavioral nuance about active edges, which helps distinguish it from other sibling tools like brain_link.

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 does not explicitly explain when to use this tool vs alternatives like brain_supersede or brain_write. It implies usage for node deletion but lacks guidance on which tool to choose for related tasks.

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

brain_historyB

Search episode history (raw conversation turns) by keyword.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 10)
`query`	Yes	Search query for episode history
`since`	No	Unix ms timestamp — only return episodes after this
`until`	No	Unix ms timestamp — only return episodes before this

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It states 'Search' implying read-only, but does not disclose whether results are ordered, paginated, or if there are rate limits or data retention implications. The phrase 'raw conversation turns' hints at verbatim content but lacks detail on what constitutes a 'turn'.

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. However, it could be restructured to front-load the core action and add a brief second sentence clarifying the scope (e.g., 'Returns up to `limit` results matching `query`, filtered by time range').

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 no output schema and no annotations, the description is insufficient. It does not describe the return format, ordering (e.g., chronological), or behavior when no results are found. With 4 parameters including time filters, additional context is needed for effective use.

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% (all parameters have schema descriptions). The description adds 'by keyword' which aligns with the 'query' parameter, but does not elaborate on the meaning or interplay of 'limit', 'since', 'until' beyond what the schema already provides. 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 verb 'Search', the resource 'episode history (raw conversation turns)', and the mechanism 'by keyword'. It distinguishes the tool from siblings like brain_query (likely semantic search) by emphasizing raw history and keyword matching.

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 given on when to use this tool versus alternatives (e.g., brain_query for semantic search). It does not specify prerequisites, limitations, or when not to use it. The agent is left to infer usage from the name alone.

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

brain_linkB

Create a typed edge between two existing nodes.

ParametersJSON Schema

Name	Required	Description
`to_id`	Yes	Target node ID
`weight`	No	Edge weight 0.0–1.0 (default 1.0)
`from_id`	Yes	Source node ID
`edge_type`	Yes	Edge type: caused_by\|associates\|supports\|instance_of\|goal_of\|before\|after\|inhibits\|summarizes\|attaches_to\|contradicts\|supersedes\|coreference_of\|drives

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only states 'create a typed edge'. It does not clarify edge uniqueness, whether existing edges are replaced, or error handling for invalid node IDs. The schema covers weight default but the description adds no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the verb and resource. No wasted words; it is as concise as possible while conveying the core action.

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?

Despite a simple interface with 4 parameters and no output schema, the description lacks critical context about side effects (e.g., does linking affect other nodes?), failure modes, and relationship to sibling tools like brain_supersede. A mutation tool needs more guidance for safe use.

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

Parameters3/5

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

Schema description coverage is 100% and each parameter is well described (from_id, to_id, edge_type with enum list, weight with range). The description adds no extra meaning beyond implying the edge_type is the 'typed' aspect, so the baseline score of 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 uses a specific verb ('Create') and resource ('typed edge') and specifies it operates between two existing nodes, making the purpose immediately clear. Among siblings like brain_query (querying) or brain_edges (listing edges), brain_link's purpose is distinct.

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 guidance on when to use this tool versus alternatives such as brain_supersede or brain_edges. There is no mention of prerequisites (e.g., node existence) or exclusions.

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

brain_queryA

Search and recall memories using hybrid FTS + vector + spreading activation. Returns ranked nodes with retrievability and salience scores.

ParametersJSON Schema

Name	Required	Description
`type`	No	Filter by node type: identity\|semantic\|episodic\|pattern\|skill\|goal\|emotion\|procedural\|schema
`limit`	No	Max results to return (default 10)
`query`	Yes	Natural language search query

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses the hybrid search method and output scores, offering useful behavioral insight beyond the schema.

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: two sentences covering purpose and output. No fluff, front-loaded with key information.

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 complexity (hybrid search), the description adequately explains what it does and returns. Some missing details like default limit or ordering are minor given schema coverage.

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 3 applies. The description does not add specific parameter semantics but reiterates the search nature. No contradiction.

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 action (Search and recall memories) and the resource (memories), with specific detail on hybrid retrieval method. It distinguishes from siblings like 'brain_write' and 'brain_link'.

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 implicitly indicates use for memory retrieval but lacks explicit when-not-to-use or alternative mentions. However, sibling naming and the search focus provide adequate context.

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

brain_reviewA

Apply an FSRS-6 spaced-repetition review to a node. Updates stability, retrievability, and SIGMA calibration.

ParametersJSON Schema

Name	Required	Description	Default
`node_id`	Yes	ID of the node to review
`quality`	Yes	Recall quality: 0=blackout, 1=incorrect, 2=incorrect+familiar, 3=hard, 4=correct, 5=perfect

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It accurately discloses that the tool mutates state by updating metrics, but does not mention permissions, reversibility, or side effects. Adequate but not comprehensive.

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 sentence of 15 words, front-loaded with the verb and resource. Every word earns its place; no redundancy or fluff.

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

Completeness4/5

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

The description explains what the tool does and what it updates, which is sufficient given the lack of output schema. However, it could mention whether a return value or confirmation is provided. Sibling tools are diverse, and this description provides enough context to differentiate.

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 both parameters. The description adds no extra meaning beyond the schema, such as explaining the quality scale or node_id format. Baseline score of 3 applies.

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 'apply', the resource 'node', and the specific updates (stability, retrievability, SIGMA calibration). It distinguishes from siblings like brain_query and brain_write.

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 spaced-repetition review but does not explicitly state when to use it versus alternatives like brain_forget or brain_supersede. No when-not-to-use guidance is provided.

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

brain_statsA

Return brain statistics: node/edge/episode counts, neuromodulator state, consolidation status, embedding coverage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description must bear full burden. It lists returned data but does not disclose side effects, authorization needs, or data freshness. For a simple stat retrieval, this is acceptable but not thorough.

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 listing of returned items. No unnecessary words, well-structured.

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 no output schema and no parameters, the description covers the essential return data. Could include format hints but is sufficiently complete for a simple stats tool.

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

Parameters4/5

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

No parameters, baseline 4. Description adds value by specifying exact statistics returned, enhancing understanding beyond empty 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 tool returns brain statistics with specific categories (node/edge/episode counts, neuromodulator state, consolidation status, embedding coverage). This distinguishes it from siblings like brain_query or brain_write.

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?

No explicit when-to-use or when-not-to-use guidance. The purpose is implied as a read-only overview, but alternatives are not mentioned.

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

brain_supersedeA

Replace an outdated node with updated content. Closes old edges, writes a supersedes edge, preserving the memory graph's temporal integrity.

ParametersJSON Schema

Name	Required	Description
`new_label`	No	Updated label (defaults to old label)
`new_content`	Yes	Updated content for the replacement node
`old_node_id`	Yes	ID of the node being superseded

TDQS

A3.9/5.0

Behavior3/5

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

Describes closing old edges and writing a supersedes edge, providing some behavioral context. However, without annotations, it misses disclosure on destructiveness, side effects, or whether the old node remains. No mention of permissions or rate limits.

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, well-structured sentence that front-loads the key action and consequence. No unnecessary words; every part earns its place.

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

Completeness3/5

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

Covers core behavior for a graph update tool, but lacks return value information, reversibility, and whether the operation generates a new node ID. Adequate but with gaps given no output schema or annotations.

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

Parameters4/5

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

Schema coverage is 100%, and the description adds context by explaining the role of each parameter in the supersede operation, e.g., 'old_node_id' and 'new_content' as updated content. 'new_label' defaults to old label, which is helpful.

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 verb 'Replace' and resource 'outdated node', explaining the process of closing old edges and writing a supersedes edge to preserve temporal integrity. This distinguishes it from sibling tools like brain_write or brain_forget.

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?

Implies usage for updating content while maintaining history, but does not explicitly state when not to use or mention alternatives among siblings. Lacks guidance on prerequisites or context.

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

brain_writeA

Store a new memory node. Automatically queues for embedding and PRISM/NEXUS auto-linking.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Node type: identity\|semantic\|episodic\|pattern\|skill\|goal\|emotion\|procedural\|schema
`label`	Yes	Short name for this memory
`content`	Yes	Full content of the memory
`importance`	No	0.0–1.0, default 0.5
`emotional_weight`	No	-1.0 to 1.0 (emotional salience)

TDQS

A3.8/5.0

Behavior3/5

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

Discloses automatic queuing for embedding and auto-linking, providing some insight into side effects. However, with no annotations, it lacks details on synchronization, rate limits, or error behavior.

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 front-load the main action (store new memory) and efficiently convey the key additional behavior (queuing for embedding and linking).

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?

Explains the core operation and background processes, but omits return value information (e.g., whether an ID is returned), which is important for a creation tool. Slightly incomplete but otherwise solid.

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 descriptions cover all parameters, so the description adds minimal extra meaning. Baseline score of 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool stores a new memory node and mentions automatic embedding and linking. This distinguishes it from siblings like brain_query, brain_forget, etc., by specifying the creation action.

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?

Usage is implied for storing new memories, but no explicit when-to-use or when-not-to-use guidance is given. Sibling tools are listed but not compared, leaving the agent to infer context.

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.

10 tool updatesv0.1.0Jul 28, 2026
- First observedbrain_edges
- First observedbrain_expand
- First observedbrain_forget
- First observedbrain_history
- First observedbrain_link
- First observedbrain_query
- First observedbrain_review
- First observedbrain_stats
- First observedbrain_supersede
- First observedbrain_write

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a distinct purpose: querying, writing, linking, superseding, history search, expanding details, reviewing, forgetting, getting edges, and stats. No overlap or ambiguity.

Naming Consistency4/5

All tools use the 'brain_' prefix followed by a verb or noun representing the action. While most are verbs (query, write, etc.), 'brain_history' and 'brain_edges' are nouns, but the pattern is still clear and predictable.

Tool Count5/5

Ten tools is well-scoped for a memory management system, covering essential operations without excess or deficiency.

Completeness5/5

The tool set provides complete lifecycle coverage: create (write), read (query, expand, history, edges, stats), update (supersede, review), delete (forget), and linking (link). No obvious gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

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

Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
BrainboxOAuth
dev.thexi
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Knowledge & Memory AI & Machine Learning
2
Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2

Related MCP Servers

yantrikdb-mcpofficial
Knowledge & Memory AI & Machine Learning
yantrikos
A
license
Not graded
quality
A
maintenance
MCP server providing cognitive memory tools (remember, recall, think, etc.) for AI agents, enabling forgetting, consolidation, and contradiction detection.
Updated 11 days ago (2026-08-26 04:45 UTC)
172
Apache 2.0
elephantasm-mcp
Knowledge & Memory Autonomous Agents
kaminocorp
A
license
A
quality
D
maintenance
MCP server for long-term agent memory, providing persistent memory, searchable knowledge, and evolving identity for AI agents.
Updated 6 months ago (2026-03-19 00:48 UTC)
5
3
Apache 2.0
NeuralVaultCore
Knowledge & Memory Autonomous Agents
getobyte
A
license
Not graded
quality
C
maintenance
An MCP server that provides persistent long-term memory for AI agents via local SQLite storage with low token overhead, enabling memory storage, retrieval, and management across sessions.
Updated 5 months ago (2026-03-27 10:13 UTC)
1
MIT
clude-mcp
Knowledge & Memory Autonomous Agents
Israeltheminer
F
license
Not graded
quality
C
maintenance
A self-hosted MCP server that gives AI agents persistent, searchable memory with importance scoring, knowledge graphs, and autonomous memory consolidation.
Updated 2 months ago (2026-07-09 23:00 UTC)
1
-

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/Enlightened-Republic/sharpwave'

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

Sharpwave

Repository layout

The problem

What makes it different

Install

Any MCP client

Claude Code

OpenClaw

Multi-agent

Tools

Memory types

Configuration

Update notifications

Enabling vector search

Requirements

How retrieval works

Limitations

Companion tools

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

yantrikdb-mcpofficial

Latest Blog Posts

MCP directory API