OpenExp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QDRANT_HOST | No | Qdrant server host | localhost |
| QDRANT_PORT | No | Qdrant server port | 6333 |
| QDRANT_API_KEY | No | Optional: Qdrant authentication key (also passed to Docker) | |
| OPENEXP_CRM_DIR | No | CRM directory for CRMCSVResolver | |
| OPENEXP_DATA_DIR | No | Directory for Q-cache, predictions, and retrieval logs | ~/.openexp/data |
| ANTHROPIC_API_KEY | No | Optional: enables LLM-based enrichment (type classification, tags, validity windows) | |
| OPENEXP_COLLECTION | No | Qdrant collection name | openexp_memories |
| OPENEXP_EXPERIENCE | No | Domain-specific reward profile to use (e.g., default, sales, dealflow) | |
| OPENEXP_SESSIONS_DIR | No | Directory for session summary files | ~/.openexp/sessions |
| OPENEXP_EMBEDDING_DIM | No | Dimensions of the embedding model | 384 |
| OPENEXP_EMBEDDING_MODEL | No | Embedding model used (local via FastEmbed) | BAAI/bge-small-en-v1.5 |
| OPENEXP_ENRICHMENT_MODEL | No | Model used for auto-enrichment if ANTHROPIC_API_KEY is provided | claude-haiku-4-5-20251001 |
| OPENEXP_OBSERVATIONS_DIR | No | Directory where hooks write observations | ~/.openexp/observations |
| OPENEXP_INGEST_BATCH_SIZE | No | Batch size for ingestion into Qdrant | 50 |
| OPENEXP_OUTCOME_RESOLVERS | No | Outcome resolvers (format: module:Class) |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_memoryA | Search memories with FastEmbed + Qdrant: hybrid semantic + BM25 + recency + importance scoring with lifecycle filtering |
| add_memoryC | Store a new memory with FastEmbed embedding and LLM enrichment |
| log_predictionA | Log a pack-grounded prediction. REQUIRED whenever the assistant cites a specific relative_day of an installed experience pack as the basis for a real-world action recommendation. Captures: which step was cited, which case it applies to, what was recommended (and what was explicitly NOT recommended), the observable signal that resolves the prediction, and the window in days. Returns prediction_id for later log_outcome. |
| log_outcomeA | Resolve a prediction with observed facts: provide actual_signal and days_to_resolve — an interpretation-free record of what happened. Legacy outcome/reward fields are accepted and recorded as data. |
| memory_statsA | Get memory system health: point counts by source/role, pending predictions, date range, Q-cache 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 5 tools
Each tool maps to a distinct concern: memory system health, memory search, memory creation, prediction logging, and outcome resolution. The prediction/outcome pair is clearly separated by their lifecycle roles.
search_memory, add_memory, log_prediction, and log_outcome all follow a verb_noun pattern. memory_stats deviates by starting with a noun, making get_memory_stats the more consistent equivalent.
Five tools is appropriately scoped for a memory plus prediction-logging server. Each tool covers a necessary function without redundancy.
The memory surface covers add, search, and health stats, while predictions cover both logging and outcome resolution. Missing prediction retrieval/listing and memory mutation/deletion are minor gaps rather than critical dead ends.