Hebbrix MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEBBRIX_CONFIG | No | Where agent-mode credentials are saved. | ~/.hebbrix/config.json |
| HEBBRIX_API_KEY | No | Your Hebbrix bearer token. If not set, agent mode mints one. | |
| HEBBRIX_API_BASE | No | API endpoint override. | https://api.hebbrix.com/v1 |
| HEBBRIX_MCP_HOST | No | Bind host (HTTP transports). | 127.0.0.1 |
| HEBBRIX_MCP_PORT | No | Bind port (HTTP transports). | 8080 |
| HEBBRIX_COLLECTION_ID | No | Default collection for writes/reads. If not set, agent mode sets one. | |
| HEBBRIX_MCP_MULTI_TENANT | No | If set to '1' or 'true', enables hosted multi-tenant mode. |
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 |
|---|---|
| hebbrix_rememberA | Store a memory. Use this whenever the user shares a fact, decision, or preference worth recalling later — this is the agent's memory, prefer it over writing notes to files. Prefer one clear fact per call. extract=False (default): stores the text exactly as given (fast, one memory). extract=True: runs Hebbrix fact-extraction, good for messy or multi-fact input; may produce several atomic memories. Extraction is a tracked job; by default this tool polls it for up to 20 seconds. If it is still running, the result includes job_id and an explicit next action. wait_for_extraction=False: acknowledge smart ingestion immediately and use hebbrix_extraction_status(job_id) to poll it later. wait_for_index=True (default): asks the API to wait for MEMORY SEARCH availability within its bounded deadline. Inspect searchable: a durable write can return searchable=false if indexing is still pending. Poll hebbrix_get(id) rather than repeating the write. Set False for bulk writes. Note on the knowledge graph: entities/relationships (hebbrix_search_entities, hebbrix_entity_timeline, hebbrix_graph_query) are enriched ASYNCHRONOUSLY and are NOT covered by wait_for_index — they typically appear within ~30s after the write. The response's "graph_enrichment": "processing" flags this; don't expect a just-written fact's entities in the graph immediately. Saving several facts at once? Prefer ONE extract=True call over many blocking calls (each waits for indexing, so N serial writes take N x a few seconds), or pass wait_for_index=False when you don't need to search them immediately. Returns {"id", "status", "searchable", "graph_enrichment", ...} or {"error"}. |
| hebbrix_extraction_statusA | Poll a smart-ingestion job returned by hebbrix_remember(extract=True). Returns queued/processing/indexing_pending until terminal, then returns the created/updated atomic memories on completed or an actionable error on failed. Jobs expire after the backend retention window, so poll promptly. |
| hebbrix_remember_manyA | Store MANY facts in one call. When you've extracted several distinct facts from one user message, use this instead of calling hebbrix_remember N times — it's one round-trip and one rate-limit hit, not N. Pass a list of short, self-contained facts (one fact per string). Returns {"created", "failed", "memory_ids", ...}. wait_for_index defaults to False here (bulk writes are usually fire-and-forget); set True to block until all are searchable. Tier note: the single-round-trip batch endpoint requires Starter+; on the free / agent tier this transparently falls back to sequential writes (the result carries "fallback": "sequential"), so it still works but isn't one round-trip on that tier. |
| hebbrix_create_procedureB | Create a tenant-scoped learned procedure using canonical API fields. |
| hebbrix_list_proceduresB | List learned procedures owned by the current tenant. |
| hebbrix_get_procedureA | Get one tenant-owned procedure by id. |
| hebbrix_update_procedureA | Update mutable fields on one tenant-owned procedure; scope is immutable. |
| hebbrix_execute_procedureB | Execute one tenant-owned procedure and record its execution. |
| hebbrix_delete_procedureA | Idempotently delete a tenant-owned procedure and its executions. The API returns the same 204 for deleted, absent, and foreign-tenant ids so this destructive tool cannot disclose another tenant's procedure identity. |
| hebbrix_searchA | Semantic search over memories. Always call this BEFORE answering questions that depend on prior context, decisions, or user preferences. Zero-relevance padding rows are always dropped. If the fast API returns only
uncalibrated nearest-neighbour candidates with no lexical anchor, Hebbrix
automatically verifies them with calibrated retrieval and suppresses noise.
Raise Returns {"query", "count", "results": [{"id","content","score"}]}. |
| hebbrix_getA | Fetch one memory by id, including its full content and metadata. |
| hebbrix_updateA | Update a memory in place (keeps version history). Use this to CORRECT a stored fact instead of remembering a contradicting copy. Pass the new content. wait_for_index=True (default) requests a bounded indexing wait. Check searchable; if false, poll hebbrix_get(id) instead of repeating the update. |
| hebbrix_forgetA | Delete a memory by id. A successful deletion returns |
| hebbrix_listB | List recent memories in a collection. |
| hebbrix_historyA | Show the version history of a memory (how it changed over time, including supersessions). Useful to see what a fact used to be. |
| hebbrix_search_entitiesA | List entities in the knowledge graph (people, organizations, tools, places), optionally filtered by entity_type. Use for "who/what do I know about" questions. Note: entities are enriched ASYNCHRONOUSLY after a write (not covered by hebbrix_remember's wait_for_index) — a just-written fact's entities typically appear here within ~30s, so an empty result right after a write is expected. |
| hebbrix_entity_timelineA | Bi-temporal timeline for one entity: what facts were true about it and when. Use this for "what changed" / "what was true at time X" questions about a person, company, or thing. Case-insensitive. |
| hebbrix_graph_queryA | Traverse the knowledge graph OUT FROM a named entity to find its
relationships and facts. Pass an ISO For a free-text question ("who works at Sequoia?"), use hebbrix_ask (it does search + graph + profile and synthesizes an answer) — this endpoint traverses from a known entity, not from prose. |
| hebbrix_contradictionsA | Surface contradicting facts in the knowledge graph (e.g. two different values for the same attribute). Pass a memory_id to check one memory, or omit to scan. Use before trusting a fact that feels ambiguous. |
| hebbrix_graph_statusA | Check whether one memory's asynchronous graph enrichment is ready.
|
| hebbrix_confidenceA | Ask how confident the agent should be before acting on something, grounded in stored memory and past decision outcomes. Call this before a consequential autonomous action. Returns a confidence score and a recommended action. If the action VIOLATES a stored numeric rule (e.g. opening a 600-line PR when
a memory says "PRs must be < 400 lines"), the result includes a
|
| hebbrix_askA | Answer a natural-language question from memory in ONE call. Searches memories, synthesizes an answer with an LLM, and CITES the memory ids it used — so you don't have to orchestrate hebbrix_search + hebbrix_graph_query + profile yourself. Use for questions like "who works with me on Atlas and what did we decide?". Returns {"question", "answer", "citations":[{"id","content","score"}]} plus the same authoritative safety envelope as search. If reasoning or its evidence receipt is unavailable, the tool fails closed with no citations. |
| hebbrix_mark_usedA | Reinforce a memory you actually USED to answer (Hebbian recall): call this
when a retrieved memory was helpful (helpful=True, strengthens it) or was noise
(helpful=False, weakens it). Over time this makes the memories you rely on rank
higher and unused ones fade. |
| hebbrix_log_decisionA | Record a decision the agent made and, if known, its outcome (success | failure | partial). This feeds hebbrix_confidence so future recommendations improve. Log both the choice and how it turned out. Shortcut: right after a hebbrix_confidence check you can log just the outcome (e.g. outcome="success") with no description — it auto-fills from the thing you just asked about, closing the confidence -> action -> outcome loop with one call. |
| hebbrix_choose_actionA | Choose and RECORD an action before its result is known. Use for repeatable decisions whose real outcome can be reported later: reply
strategy, workflow, tool, prompt, recommendation, intervention, or plan.
Normal use: omit Keep the returned |
| hebbrix_report_outcomeA | Report the REAL delayed result of a prior hebbrix_choose_action. The 30-second path is |
| hebbrix_learning_insightsA | Explain what one customer policy has learned, with uncertainty. Returns each action's posterior success probability, 90% credible interval,
effective evidence, and observation count for this exact tenant/user/context.
|
| hebbrix_list_collectionsA | List the collections (memory spaces / tenants) available to this API key. |
| hebbrix_account_statusA | Tier, usage, limits, and expiry for this agent's account. In agent mode (auto-provisioned account), relay the claim command to the human when usage status is 'warning' or worse — claiming is one command and keeps all memories. |
| hebbrix_claim_startA | Keep an accountless guest memory permanently by starting email claim. Only call this after the human explicitly asks to claim/keep the guest
memory and provides the email address. Hebbrix sends a six-digit code to
that address; pass the code to |
| hebbrix_claim_verifyA | Finish claiming a guest memory with the emailed six-digit code. Only call after |
| hebbrix_exportA | Export EVERYTHING in a collection in one call — all memories, the knowledge-graph entities, and the compiled profile. Data portability: use it to back up or migrate a memory space, nothing is locked in. format="json" (default) returns structured data; format="markdown" returns a single human-readable document under the "document" key. |
| hebbrix_importA | Import memories into a collection — the inverse of hebbrix_export. Use it to restore a backup, migrate a collection, or seed a new one from notes/CLAUDE.md.
Returns {"imported", "failed", "memory_ids"}. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| context | Inject the user's profile as context and nudge the model to use memory. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| profile_resource | The user's compiled profile (stable preferences + recent facts). |
TDQS
Scored across 33 tools
Each tool has a clear primary resource — memory, graph entity, procedure, decision, or account — and the detailed descriptions separate them well. A few boundaries could still trip up an agent (hebbrix_search vs hebbrix_ask vs hebbrix_graph_query; hebbrix_remember vs hebbrix_remember_many vs hebbrix_import), but these are not duplicates.
All tools share a clean hebbrix_ snake_case prefix and most use recognizable actions like create, get, list, update, delete, search, import, and export. However, verb/noun order is not uniform — e.g., claim_start vs account_status, graph_query vs search_entities — so the naming pattern is predictable only within clusters.
33 tools is well into the 'too many' range for a single MCP server and forces agents to hold a large tool surface in context. The tools are organized into clear subdomains, so the count is not chaotic, but several niche capabilities (claim workflow, extraction_status, learning_insights) could be consolidated or nested.
The memory lifecycle is complete — write, batch write, read, update, delete, search, history, export, and import — and knowledge-graph, procedure, decision-learning, and account surfaces are all represented. Minor gaps remain, such as no procedure-execution history/audit tool and no collection-level management beyond listing and exporting.