blueocean-vector
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLUEOCEAN_TOP_K | No | Default top K for search. | |
| BLUEOCEAN_EMBEDDING | No | Embedding provider: `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. | fastembed |
| BLUEOCEAN_TELEMETRY | No | Turn usage telemetry on/off. On by default; set to 0 to disable. | 1 |
| BLUEOCEAN_AUTH_TOKEN | No | Bearer token for authentication. Unset by default (fine for 127.0.0.1-only use). Set before exposing this server beyond localhost. | |
| BLUEOCEAN_MAX_TOKENS | No | Default search token budget. Entries beyond the budget are truncated, never dumped wholesale. | 2000 |
| BLUEOCEAN_QDRANT_URL | No | Where Qdrant lives. | |
| BLUEOCEAN_EMBED_MODEL | No | Embedding model. Vectors written with one model can't be meaningfully searched with another, so pin this in `.env`. | intfloat/multilingual-e5-large |
| BLUEOCEAN_HEALTH_EMBED_TTL | No | TTL in seconds for caching cloud-provider embedding credential validation in health checks. | 60 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_storeC | Persist a memory entry for a project (content + condensed summary + importance + area/module). |
| memory_searchC | Semantic search a project's memory with token-budgeted return (summary + full layers). |
| memory_getA | Fetch the full content of a single memory entry by ID. |
| memory_deleteC | Delete a single memory entry by ID. |
| memory_list_projectsB | List all projects that have a memory collection. |
| memory_manifestC | Show the areas/modules present in a project's memory. |
| memory_summarize_sessionC | Store a condensed summary of a work session for later retrieval. |
| memory_statsB | Admin: collection stats (count, importance/area distribution, size). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each 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.