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., "@blueocean-vector what decisions do we have about the database?"
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.
Shared, persistent memory for coding agents.
The kind of memory that survives switching from Claude Code to Codex to Cursor mid-project — and survives you running out of tokens in one of them.
If you've ever burned through a context window, opened a different tool, and then spent ten minutes re-explaining what you were doing, this is for that problem. BlueOcean Vector runs one small server on your machine. Any MCP-capable agent can read from it and write to it. Whichever tool you open next just asks "what do we know about this project?" and picks up where the last one left off.
Store a decision in Claude Code → open Codex tomorrow → it already knowswhy you chose Postgres over DynamoDB, not just that you did.
Related MCP server: AIVectorMemory
Every agent session starts from zero. You explain the project, the constraints, the "we tried that already, it didn't work" — and then the session ends and it's gone. Multiply that by every tool you use, and you're spending real tokens just re-establishing context that already existed an hour ago.
BlueOcean Vector is a small, boring fix: one shared memory store, one URL, and a common set of tools (memory_store, memory_search, memory_summarize_session, and a few more) that any MCP client can call. It doesn't try to be clever about what to remember — it just gives agents a place to put things down and pick them back up, scoped per project so a search in one codebase doesn't surface noise from another.
There's already a well-populated field of "memory for AI agents" projects. Worth being upfront about where this one actually sits, instead of pretending the space is empty.
Project | How an agent talks to it | Who decides what's remembered | Semantic vector search |
SDK / hosted API | Automatic — an LLM extracts facts on ingest | Yes, wrapped behind the extraction layer | |
SDK, or an official MCP server | Automatic — entities/relationships extracted into a knowledge graph | Secondary to graph traversal | |
Letta (formerly MemGPT) | Full stateful-agent platform, server + SDK | Semi-automatic — the agent's own LLM pages memory in/out | Yes, for archival memory |
MCP-native, no server to run | Explicit — the calling agent writes | Fallback only (~1.8s), keyword search is primary | |
threadctx-mcp | MCP-native | Explicit + optional passive git capture | Paid cloud tier — local mode is keyword-only |
BlueOcean Vector | MCP-native, one shared server | Explicit — the calling agent writes | Primary and always-on |
Two honest takeaways:
The "MCP-native, works with any client" niche isn't empty — Memorix already lives there, with more built-in tools. What's different here is that vector search is the primary retrieval path rather than a fallback or something gated behind a paid tier, the default embedding model is genuinely multilingual (Thai+English tested), and it's built to run as one shared, persistent server rather than a zero-install per-agent tool — bearer-token auth, a documented path to ECS, Kubernetes-ready health probes, and real fixes for the concurrency problems a shared server actually hits.
No automatic extraction or consolidation — unlike mem0, Graphiti, Letta, cognee, or LangMem, nothing here reads your conversation and decides what's worth remembering. That's a deliberate simplicity trade-off, not a missing feature: an agent has to explicitly call memory_store. If you want a system that reasons about what to keep on your behalf, one of the projects above will do that better than this will.
Some projects are a million lines of code. And no memory system — BlueOcean Vector included — should try to store all of it. Storing code is a code-search tool's job, not a memory server's.
BlueOcean's job is narrower and more useful: remember what mattered, and where to find it. It holds the decisions, the architecture, the "we tried that, it didn't work" — the condensed knowledge an agent would otherwise have to rediscover from a million lines — plus just enough context to point the agent back at the real code when it needs details.
The result is that memory grows with what's actually worth remembering, not with the size of the codebase. A million-line project can have a few thousand memory entries. That keeps retrieval cheap no matter how big the project gets.
Reading memory back is where that distinction pays off. The cheapest alternative — a skill or plugin that dumps project notes into a .remember file an agent reads back — works great until the file outgrows the context window, then it silently stops being useful.
BlueOcean caps every search at a token budget (default 2000 tokens, configurable via BLUEOCEAN_MAX_TOKENS). Semantic search pulls only the relevant entries, then splits the budget: ~60% for condensed summaries, ~40% for the full content of the top hits. Entries beyond the budget are truncated, never dumped wholesale.
Approach | Cost per retrieval | Grows with memory size? |
BlueOcean Vector ( | capped at the token budget (default 2000) | No — bounded, regardless of collection size |
| equal to the whole file size | Yes — linear; eventually exceeds the context window |
| equal to that section | Partial — but the agent must guess which section without relevance ranking |
A real search against a small demo project returned 121 tokens for one summary + one full entry — a few percent of the 2000-token budget, and that budget never grows as the project accumulates memory. With a plain file, the same read costs the entire file every time, so a 5k-entry project (hundreds of thousands of tokens) is unreadable in one shot.
┌────────────┐ ┌──────┐ ┌────────┐ ┌───────────────┐ ┌──────┐
│Claude Code │ │Cursor│ │ Codex │ │Gemini/Antigrav│ │ Kiro │ ...any MCP-http tool
└─────┬──────┘ └──┬───┘ └───┬────┘ └───────┬───────┘ └──┬───┘
└───────────┴─────────┴──────────────┴────────────┘
│ http://localhost:8765/mcp
┌───────────────────────────┐
│ blueocean-mcp │ Python MCP server
│ (one shared, persistent │ (docker compose)
│ server, not per-agent) │
└─────────────┬─────────────┘
│
┌───────────────────────────┐
│ Qdrant (vector DB) │ Docker locally → ECS Fargate in the cloud
└───────────────────────────┘A few design choices worth knowing about:
Choice | Why |
One server, reached by URL | Every mainstream MCP client (and plenty of niche ones) has its own "add a remote server" command. Point them all at the same URL and none of them need bespoke config-file editing from us. |
Qdrant underneath, one collection per project | Memory for |
Multilingual by default | Embedding model is |
Token-budgeted reads |
|
stdio transport also works if you'd rather each tool spawn its own local process instead of talking to the shared server — see Alternative: stdio below. The shared HTTP server is still the recommended path; stdio spins up a separate copy of the embedding model per agent.
# 1. Bring up Qdrant + the MCP server (both run in the background via docker compose)
./scripts/setup_local.sh
# 2. Register the URL with whichever agents you use
./scripts/register_mcp.shThat's it. setup_local.sh starts both containers, waits for Qdrant to actually respond (not just "the process started"), copies .env.example to .env on first run, and syncs the Python package. register_mcp.sh then calls each tool's own mcp add CLI (or, for Cursor, edits ~/.cursor/mcp.json directly, since Cursor's CLI only works while the app is open) to point it at http://localhost:8765/mcp.
For any other MCP-http-capable tool, including ones we've never heard of, just give it the same URL through that tool's own "add remote MCP server" feature:
http://localhost:8765/mcpRegistering the server gets the tools available; it doesn't make an agent reach for them on its own. scripts/install_skill.sh installs a small skill — "check memory at the start of a session, write to it before you run low on context" — into whichever agents you use, so the habit is there without you repeating it in every prompt:
./scripts/install_skill.sh # interactive picker
./scripts/install_skill.sh all # install into every supported tool found
./scripts/install_skill.sh --list # see what's installed whereIt's one canonical SKILL.md, symlinked into each tool's own skills directory — edit it once, every tool picks up the change.
No Docker available, or you'd rather not run a shared server? Run:
uv run blueocean-mcp --transport stdio --qdrant-url http://localhost:6333and point the tool's MCP config at the command (see .venv/bin/blueocean-mcp) instead of a url.
Tool | What it does |
| Save an entry — content, a condensed summary, an importance score, and area/module tags |
| Semantic search, token-budgeted: cheap summaries first, full content for what fits |
| Fetch one entry's full content by ID |
| Remove one entry by ID |
| List every project that has a memory collection |
| See what areas/modules exist before searching, so you scope the query sensibly |
| Leave a condensed handoff note for whichever agent picks this up next |
| Counts and distribution, mostly for admin/debugging |
A reasonable agent workflow: call memory_manifest then memory_search at the start of a session to load context cheaply; memory_store real decisions as you go (importance 5 for "why we chose X over Y", importance 3 for routine status); call memory_summarize_session before switching tools or running low on budget.
Everything lives in .env (copy .env.example to start). The defaults work for local, single-machine use; the interesting knobs are:
BLUEOCEAN_EMBEDDING — fastembed (default, local and free), openai, or bedrock. Pin BLUEOCEAN_EMBED_MODEL too: vectors written with one model can't be meaningfully searched with another, so local and cloud need to agree on it.
BLUEOCEAN_QDRANT_URL — where Qdrant lives.
BLUEOCEAN_MAX_TOKENS / BLUEOCEAN_TOP_K — the default search budget.
BLUEOCEAN_AUTH_TOKEN — unset by default (fine for 127.0.0.1-only use). See Security if you're exposing this beyond your own machine.
Transport (streamable-http vs stdio) is a CLI flag, not an env var — it's a "how do I run this" choice made at startup, not a persistent setting.
uv run blueocean-admin stats <project>
uv run blueocean-admin manifest <project>
uv run blueocean-admin list
uv run blueocean-admin export <project>
uv run blueocean-admin prune <project> --older-days 90 --max-importance 2 [--dry-run]
uv run blueocean-admin snapshot <project> [--out ./backups]
uv run blueocean-admin restore <project> <snapshot-file> --yes
uv run blueocean-admin generate-token --write-envIf more than one agent session shares a project,prune doesn't know that. It deletes whatever matches your filters, even entries another session wrote five minutes ago. Run with --dry-run first, and prefer narrow filters over a broad reset.
export only dumps payload as JSON (with_vectors=False) — restoring from it means re-embedding everything from scratch, not a real point-in-time restore. snapshot/restore use Qdrant's own native snapshot mechanism instead: vectors, payload, and index state, captured atomically. snapshot downloads the file to local disk and deletes the server-side copy once the download is confirmed intact (backups living only inside the same Qdrant volume they're backing up out of aren't backups). restore overwrites the project's current data, so it requires --yes.
Project names are validated strictly (^[a-z0-9][a-z0-9_-]*$, matching the directory-name convention this project already recommends) rather than silently normalized — two agents guessing slightly different spellings of the same project ("Team A" vs "team-a") used to merge into one collection with no warning; now the mismatched one is rejected instead.
Test files under tests/ are standalone scripts (if __name__ == "__main__":), not pytest-discovered files — run them as modules:
uv run python -m tests.smoke
uv run python -m tests.auth
uv run python -m tests.mcp_e2e
uv run python -m tests.backup # real snapshot -> delete collection -> restore cycle
uv run python -m tests.health # /health diagnostics + the cloud-provider self-test TTL cachetests/auth.py specifically checks that unauthenticated and wrong-token requests get rejected (401) and that a correct token works via both the header and the ?token= query-param path.
No auth by default — reasonable for 127.0.0.1-only local use, not reasonable the moment this is reachable from anywhere else.
If you expose this server beyond localhost (a shared machine, the cloud), setBLUEOCEAN_AUTH_TOKEN before you do anything else.
uv run blueocean-admin generate-token --write-env
docker compose up -d --force-recreate blueocean-mcp
./scripts/register_mcp.sh # reads the token from .env, re-sends it to every toolNot every tool can set a custom header when registering a remote server by URL, so the server accepts the token two ways and each client uses whichever it supports:
Authorization: Bearer <token> — Claude Code, Gemini/Antigravity
?token=<token> on the URL — Codex, Kiro, Cursor
stdio transport skips this entirely: it's a locally spawned subprocess, already gated by OS process-spawn permissions rather than sitting on the network.
GET /health is deliberately unauthenticated and checks that Qdrant is actually reachable, not just that the process is alive. It's what docker-compose.yml's healthcheck polls. It also reports the active embedding provider/model, and for openai/bedrock (not fastembed, whose model load already gates process startup) validates credentials via a free control-plane call rather than the billed embed endpoint, caching the result for BLUEOCEAN_HEALTH_EMBED_TTL seconds (default 60) so a 10s probe interval doesn't turn into a provider API call on every hit:
{"status": "ok", "qdrant": "reachable", "embedding": {"provider": "fastembed", "model": "intfloat/multilingual-e5-large", "ok": true}}Set the token via BLUEOCEAN_AUTH_TOKEN (env var / .env), not the --auth-token CLI flag — a value passed as a CLI argument is visible to any other local user via ps. Request access logging is also off by default (access_log=False), since three of the five supported clients send the token as ?token=... and a plain access log would put it in plaintext in your logs on every single request.
docker compose up -d runs two long-lived services: qdrant (port 6333) and blueocean-mcp (port 8765). For the cloud, the same two services move to ECS Fargate (or Qdrant Cloud plus a small Fargate/App Runner service for blueocean-mcp) — register the public URL with each tool exactly the way you would locally. The Dockerfile pins the embedding model so vectors produced in the cloud are compatible with ones produced on your laptop.
Kubernetes doesn't read docker-compose.yml's healthcheck: — it needs its own probes in the Pod spec, but they can point at the same path:
readinessProbe:
httpGet: { path: /health, port: 8765 }
livenessProbe:
httpGet: { path: /health, port: 8765 }qdrant-client is pinned to the Qdrant server's exact version (see the image tag in docker-compose.yml). Qdrant versions its client and server in lockstep, and the API has changed between releases — .search() was removed in favor of .query_points() in 1.19. If you bump the server image, bump qdrant-client to match and re-run the test suite; don't jump several versions on real data without a snapshot first.
mcp is pinned >=2.0.0,<3.0.0, tighter than most dependencies here. Its API (mcp.server.mcpserver.MCPServer and friends) has changed shape significantly between releases, and a loose constraint risks a Docker build silently resolving something incompatible — Docker builds don't use uv.lock.
Embedding provider and model are a matched pair. Switch either one and old vectors become unsearchable garbage against new ones. Pin the model in .env rather than trusting a library default that might change out from under you.
MIT — see LICENSE.
Delete a single memory entry by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| point_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It only says 'Delete', which implies irreversibility, but fails to state this explicitly, required auth scopes, or if the deletion is soft or hard. No annotation contradiction.
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?
Single sentence with no filler. Could arguably add 'irreversibly' for transparency, but current length is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required params, 0% coverage, an output schema exists but is not referenced, and 7 siblings. The description is too minimal; it omits return value info, ID source hints, and deletion semantics. Incomplete for reliable agent selection.
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?
With 0% schema description coverage, the description must compensate. It does not explain what 'project' or 'point_id' represent, their formats, or any validation rules. The description adds no paramenter meaning beyond the schema's field names.
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 action ('Delete') and the resource ('a single memory entry'), differentiated from siblings like memory_store or memory_search. The 'by ID' detail specifies the key identifier.
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?
No guidance on when to use vs alternatives (e.g., memory_summarize_session might delete differently), no prerequisites for which IDs are valid, and no consequences like cascading effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content of a single memory entry by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| point_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It states it retrieves content, but it does not disclose any side effects (none expected for get), permissions needed, or error behavior (e.g., what happens if point_id not found). The lack of annotations is mitigated by the read-only nature implied by 'Fetch', but more context on behavior would improve the score.
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?
The description is a single sentence, short and front-loaded with action and object. It contains no redundant information, earning its place. However, it lacks any additional detail that could make it more helpful without expanding much.
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 the tool's simplicity (2 parameters, no output schema, no nested objects), the description is adequate for a basic retrieval. However, it leaves gaps: the 'project' parameter is unexplained, and the response format is not described (no output schema). A more complete description could clarify the project scope or that the full content is returned.
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 0%, so the description must compensate. The description mentions 'by ID' which aligns with 'point_id', but it does not explain the 'project' parameter's role or provide any context beyond what the schema already offers. The description adds minimal value, leaving the agent to infer the purpose of 'project'.
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 ('Fetch'), identifies the resource ('a single memory entry'), and specifies the retrieval mode ('full content by ID'). It clearly distinguishes from sibling tools like memory_search (searches) or memory_list_projects (lists), as it targets a single entry by a unique identifier.
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 is clear but does not provide explicit guidance on when to use this tool vs alternatives. It implies usage for retrieving a known memory entry by ID, but it does not mention when not to use it (e.g., for partial content) or direct the agent to other tools like memory_search for lookup by content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects that have a memory collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'List all projects,' failing to disclose read-only nature, return format, authentication needs, or any side effects. This is insufficient for safe agent usage.
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?
One concise sentence with no unnecessary words. Every part adds value, and it is front-loaded with the action and target.
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 no output schema and low complexity, the description should clarify what is returned (list of project names? IDs?). It is adequate for a simple listing but incomplete for an agent to fully understand the output.
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?
There are zero parameters, so schema coverage is 100% by default. Per guidelines, 0 params yields a baseline of 4. The description adds no param semantics, but none are needed.
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 tool lists 'all projects that have a memory collection,' using a specific verb and resource. It is distinct from sibling tools like memory_store or memory_search, though it does not explicitly differentiate from memory_stats or memory_manifest.
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?
No guidance is provided on when to use this tool vs alternatives (e.g., memory_stats might list stats). The description only states what it does, 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.
Show the areas/modules present in a project's memory.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It does not mention whether the operation is read-only, what happens if the project does not exist, or any side effects (likely none). The verb 'Show' implies a read operation, but this is not explicitly stated.
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?
The description is a single sentence, which is very concise. However, it is somewhat under-specified for a tool with no annotations and no param descriptions, so it leans slightly toward being too brief rather than optimally informative.
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 the tool complexity (1 required param, no annotations, no output schema), the description is incomplete. It does not explain what 'areas/modules' mean, what the output format looks like, or how this differs from memory_stats. An agent would need to infer too much.
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 0%, so the description must compensate for the single parameter 'project'. It does not explain what valid project values are, how to specify them (e.g., name, ID), or whether the parameter is case-sensitive. This leaves the agent guessing.
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 verb 'Show' and the resource 'areas/modules present in a project's memory', which is specific and distinguishes it from siblings like memory_stats (which likely shows statistics) or memory_store (which stores data).
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?
No guidance on when to use this tool versus alternatives such as memory_stats or memory_search. The description does not provide context about what kind of memory overview this offers or when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search a project's memory with token-budgeted return (summary + full layers).
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| query | Yes | ||
| top_k | No | ||
| module | No | ||
| project | Yes | ||
| max_tokens | No | ||
| importance_min | No | ||
| time_range_end | No | ||
| time_range_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It hints at token budgeting and a two-layer result structure, but it doesn't disclose what happens when the token budget is exceeded (truncation? sorting?), whether the tool is idempotent/read-only, or any rate-limit concerns. For a semantic search that returns multiple entries, key behavioral traits like ordering (by relevance?) and result format are underspecified.
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?
The description is a single, front-loaded sentence with no wasted words. It could improve clarity by unpacking jargon like 'full layers' and 'token-budgeted return', but it remains concise and scannable. A small structure improvement would be breaking into two sentences for readability.
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 the high complexity (9 parameters, zero descriptions, no output schema), a one-line description is vastly insufficient. It omits the return format structure, ordering, how filters combine, and the role of the token budget. The agent cannot reliably determine how to craft calls or interpret results from this definition alone.
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 0% for the nine parameters, so the description must compensate. It mentions 'query' and 'token-budgeted' (mapped to max_tokens) but fails to explain area, module, top_k, importance_min, time_range_start, time_range_end, or their interplay. Most parameters remain opaque to the agent, making effective invocation difficult.
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 identifies the tool as performing a semantic search over a project's memory with a token-budgeted return that includes both a summary and full layers. This distnguishes it from siblings like memory_get (exact retrieval) and memory_store (write), but it doesn't explicitly contrast them. The purpose is well-stated but could be strengthened by naming when to prefer this over other memory tools.
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 gives no guidance on when to use semantic search vs. the alternative memory tools like memory_get or memory_list_projects. It doesn't state prerequisites, restrictions (e.g., project must exist), or typical use cases. With seven siblings, explicit 'when to use' advice is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Admin: collection stats (count, importance/area distribution, size).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions the output includes 'count, importance/area distribution, size' but does not explicitly state that the operation is read-only, what permissions are required beyond 'Admin', whether any side effects occur, or if rate limits apply. The safety profile is only implied by the nature of 'stats'.
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?
The description is extremely concise—one short sentence with no filler. It front-loads the key information ('Admin: collection stats') and then lists the statistics provided. However, it could be slightly more informative without losing conciseness (e.g., specifying the parameter). It earns its place but is at the edge of under-specification.
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 the tool's simplicity (one parameter, no output schema), the description covers the high-level output but omits the return format (e.g., object keys, data types) and any explanation of valid values for 'project'. With no output schema, the agent might need to guess the structure. The description is minimally complete for a stats retrieval but lacks enough detail for reliable invocation without domain knowledge.
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 0% for the single required parameter 'project'. The description does not explain what 'project' represents (e.g., project name, ID, or path) or how to use it. The phrase 'collection stats' loosely ties to the parameter, but the agent is left guessing whether 'project' refers to a project identifier or a collection name. The description adds no semantic value beyond the schema's bare type.
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 tool's purpose: it provides admin-level collection statistics including count, importance/area distribution, and size. This distinguishes it from sibling tools like memory_list_projects (which lists projects) and memory_search (which searches within a collection). The verb 'stats' implies retrieval, and the resource is 'collection stats', making the intent unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. The prefix 'Admin:' hints at restricted access, but there is no explicit statement of prerequisites, user roles, or scenarios where other tools (e.g., memory_list_projects, memory_get) would be more appropriate. The agent receives no help in deciding between memory_stats and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a memory entry for a project (content + condensed summary + importance + area/module).
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | ||
| module | Yes | ||
| content | Yes | ||
| project | Yes | ||
| summary | Yes | ||
| metadata | No | ||
| importance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions persistence but does not state whether this is a create or update operation, if it overwrites existing entries, or what idempotency guarantees exist. For a tool that stores data, these details are critical.
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?
The description is a single sentence, concise and front-loaded. It effectively conveys the core action, but could benefit from a second sentence to cover usage guidance or behavioral notes without being overly verbose.
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 7 parameters, 0% schema coverage, no annotations, and an output schema (not described), the description is incomplete. It fails to clarify what the tool returns, how conflicts are handled, or how 'importance' is interpreted. The sibling tools suggest a rich system, but this description lacks enough detail for an agent to use it confidently.
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 0%, so the description needs to compensate. It mentions content, summary, importance, area, and module but adds no extra context (e.g., format, constraints, or relationships). The 'metadata' and 'importance' parameters lack any semantic explanation beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it persists a memory entry and lists the key fields (content, condensed summary, importance, area/module). It distinguishes the tool from siblings like memory_search and memory_get, but could be more explicit about its unique role among the sibling tools.
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 provides no guidance on when to use this tool vs alternatives like memory_summarize_session or memory_manifest. It does not specify prerequisites, when not to use it, or how it fits into the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a condensed summary of a work session for later retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | ||
| project | Yes | ||
| conclusion | Yes | ||
| importance | No | ||
| session_id | Yes | ||
| observations | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'store for later retrieval' without disclosing side effects like overwriting, idempotency, or dependencies. With no annotations, the bare description fails to convey behavioral traits beyond basic write 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?
The description is a single sentence of 10 words, which is very concise. However, it lacks any structure (e.g., bullet points, examples) and does not earn its place by providing sufficient information for a tool with 6 parameters.
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 the 6 parameters (5 required), 0% schema coverage, and no annotations, the description is severely incomplete. It does not explain the purpose of each parameter, expected output, or constraints, making it inadequate for correct tool invocation.
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 0% and the description adds no parameter-level meaning. The agent receives no explanation for fields like project, area, observations, conclusion, session_id, or importance, leaving critical semantics ambiguous.
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 tool stores a condensed summary of a work session, using a specific verb and resource. It distinguishes from generic memory_store by emphasizing session summaries, but does not explicitly differentiate from siblings like memory_store or memory_search.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., memory_store for raw data, memory_search for retrieval). The description lacks context for prerequisites or preferred scenarios.
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.0memory_deletememory_getmemory_list_projectsmemory_manifestmemory_searchmemory_statsmemory_storememory_summarize_sessionEach tool targets a distinct memory operation: stats, store, search, get by ID, delete, list projects, manifest areas, and session summary. No two tools overlap in purpose, ensuring clear differentiation for an agent.
All tools follow the uniform 'memory_<verb>_<noun>' pattern with snake_case. Verbs are descriptive and consistent (stats, store, search, get, delete, list_projects, manifest, summarize_session), making the set predictable and easy to navigate.
With 8 tools, the surface covers the core memory management lifecycle (create, read, delete, search) plus administrative utilities (stats, manifest, project listing, session summary). This is well-scoped without being excessive or sparse.
The tool set covers the fundamental CRUD operations except for an explicit update/modify tool. While search and get provide read access, and store creates new entries, the absence of an update operation is a minor gap that agents may need to work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
An MCP memory server. One memory your agents share — across models, devices and apps.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thammarongg/blueocean-vector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
