Hebbrix MCP Server
OfficialThe Hebbrix MCP Server provides AI agents with persistent long-term memory, a temporal knowledge graph, and reasoning capabilities. You can:
Manage memories: Store facts, decisions, or preferences (
remember), batch-store multiple at once (remember_many), perform hybrid semantic search (vector + BM25 + graph) with optional score filtering (search), retrieve by ID (get), update with version history (update), delete (forget), list recent (list), view change history (history), reinforce recall (mark_used), and export/import data in JSON or Markdown (export,import).Leverage the knowledge graph: List known entities (
search_entities), view bi-temporal entity timelines (entity_timeline), traverse relationships with point-in-time queries (graph_query), and detect contradictions (contradictions).Reason and decide: Answer natural-language questions with cited answers via GraphRAG (
ask), assess confidence for actions based on past outcomes (confidence), and log decisions to improve future assessments (log_decision).Manage account and collections: List available memory collections (
list_collections) and check account status, usage, and limits (account_status).
Click on "Deploy 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., "@Hebbrix MCP Serverremember that the meeting is at 3pm"
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.
Hebbrix MCP Server
A Model Context Protocol server that gives any AI agent persistent memory, a temporal knowledge graph, and outcome-based learning, backed by Hebbrix.
This repository is the MIT-licensed MCP adapter. Durable storage, retrieval, graph processing, reasoning, and Outcome Memory are provided by the Hebbrix cloud API; this repository does not claim that the backend is self-hostable or open source.
Your agent forgets everything when the session ends. This fixes that, and goes further than a plain memory store:
Memory — store, search, correct, and version facts across sessions
Knowledge graph — entities, relationships, timelines, and "what was true at time X"
Reasoning — ask how confident the agent should be before acting, and log outcomes so it improves
Outcome Memory — learn which action works for each customer and context from delayed results, with safe baselines and inspectable uncertainty
Works with Claude Desktop, Claude Code, Cursor, Cline, Continue, and any other MCP client.
Release compatibility
MCP package | Hosted/API contract | Tool surface | Migration |
0.5.11 | Hebbrix API 1.1.3 / search-safety-v1 / claim-grounding-v28 | 33 | Consistent evidence verification, failure categories, request diagnostics |
0.5.8 | Hebbrix API 1.0.0 / search-safety-v1 | 32 | Adds procedure lifecycle tools |
Version 0.5.10 preserves upstream indexing receipts across writes, updates, and polling. Graph status distinguishes related memories from entity relationships. The companion API's claim-grounding-v28 contract verifies named-subject evidence consistently across cold and cached retrieval and preserves purpose and direction; the adapter never bypasses upstream grounding to manufacture an answer.
Version 0.5.11 adds response-local diagnostics (request ID, build, grounding and
safety versions, and search cache path). An ask fallback includes separate
reasoning and retrieval diagnostics. No credentials or memory content are
included in diagnostics. synthesis_status distinguishes synthesized,
retrieval_only, and abstained. failure_category distinguishes unknown facts,
unverified candidates, unavailable verification, service failures, quota
exhaustion, and malformed evidence receipts. Legitimate abstention is not a
transport error. These labels do not weaken the evidence gate.
Reproduce the full customer set and additional distractor checks with
python scripts/verify_recall.py --require-graph against a local API first;
use --mcp http://localhost:8099/mcp for HTTP. Remote fixture writes require
--allow-remote. The verifier creates isolated guests, tests both result limits
before and after asynchronous processing, then deletes its collections.
This targeted regression suite is not a representative accuracy benchmark;
conservative abstentions and probabilistic synthesis remain possible.
Version 0.5.9 makes structured failures real MCP errors over both stdio and hosted HTTP, preserves authoritative recall when GraphRAG abstains by returning an explicitly retrieval-only result, and adds bounded graph-enrichment status polling. Version 0.5.8 added the complete tenant-scoped procedure lifecycle (including idempotent deletion), and preserves authoritative batch readiness receipts. It also retains 0.5.7's API-owned grounding and abstention envelope: missing, malformed, degraded, or ungrounded receipts fail closed with empty evidence.
The hosted server and PyPI package expose their exact package version during
MCP initialization. The API exposes its immutable deployment build through
X-Hebbrix-Build and GET /v1/health/build; OpenAPI info.version identifies
the stable HTTP contract rather than a mutable deployment.
Fastest setup: hosted, no account
For an HTTP-capable MCP client, this is the entire setup:
{ "mcpServers": { "hebbrix": { "url": "https://mcp.hebbrix.com/mcp" } } }On the first MCP handshake, Hebbrix creates an isolated free guest memory and keeps its credential in a Secure, HttpOnly session cookie. There is no signup, email, dashboard, local process, or API key to paste. A compatible MCP HTTP client automatically sends that cookie on later requests. Add your own bearer key at any time if you want to use an existing Hebbrix account instead.
Quick start (no account needed)
Add this to your MCP client config. On first run with no API key, the server mints a free agent account automatically (no email, no dashboard, ~2-4 seconds via proof-of-work) and saves it to ~/.hebbrix/config.json.
{
"mcpServers": {
"hebbrix": { "command": "uvx", "args": ["hebbrix-mcp"] }
}
}uvx (from uv) runs the server with no install step. If you prefer, pip install hebbrix-mcp and use "command": "hebbrix-mcp" instead.
Restart the client. Done — your agent now has persistent memory.
The free agent account includes 300 learning events and 2,000 retrievals, and expires 14 days after last use if unclaimed. The first tool result, material quota/status changes, and every constrained-state result carry a hebbrix_usage block; hebbrix_account_status returns it on demand at any time.
Keep it forever (same key, all memories carry over, unlocks the free monthly tier):
uvx hebbrix-mcp claim --email you@example.comRelated MCP server: Bi-Temporal Knowledge Graph MCP Server
Claude Code plugin (recommended)
Install as a Claude Code plugin and Claude starts every session already
knowing you — a SessionStart hook auto-loads your compiled Hebbrix profile
into context, and the memory tools are wired up in one step:
/plugin marketplace add Hebbrix/hebbrix-mcp
/plugin install hebbrix@hebbrixThat's it. No account needed (agent mode mints one on first run); set your
api_key in the plugin config to use your own account instead. The hook degrades
gracefully — a brand-new profile just shows (none yet) until you've saved a few
facts, and it never blocks a session.
Configuration
Get an API key at hebbrix.com/dashboard/api-keys to use your own account instead of agent mode.
{
"mcpServers": {
"hebbrix": {
"command": "uvx",
"args": ["hebbrix-mcp"],
"env": {
"HEBBRIX_API_KEY": "mem_sk_...",
"HEBBRIX_COLLECTION_ID": "your-default-collection-uuid"
}
}
}
}claude mcp add hebbrix -- uvx hebbrix-mcp{
"mcpServers": {
"hebbrix": { "command": "uvx", "args": ["hebbrix-mcp"] }
}
}Point your MCP servers config at the uvx hebbrix-mcp command (stdio). Same shape as above. Set HEBBRIX_API_KEY in env to skip agent mode.
The env var always wins over saved agent-mode credentials.
Environment variables
All optional. With nothing set, the server starts in agent mode.
Variable | Default | Purpose |
| (agent mode mints one) | Your Hebbrix bearer token |
| (agent mode sets one) | Default collection for writes/reads |
|
| API endpoint override |
|
| Where agent-mode credentials are saved |
|
| Bind host (HTTP transports) |
|
| Bind port (HTTP transports) |
| off | Hosted mode: per-request |
| off | Hosted mode: mint a bounded guest identity on unauthenticated |
| (required for accountless) | HMAC secret for stateless Secure guest cookies |
| (required for accountless) | HMAC trust bridge for original-client signup throttling |
Available Tools
A server-level instruction block teaches the model when to reach for each tool, so a well-behaved agent searches before answering and remembers what matters without being told.
Memory
hebbrix_remember- Store a fact, decision, or preference.content(string, required): the memory texttags(list, optional),collection_id(string, optional)extract(bool, default false): false stores the text exactly (one memory); true starts a tracked fact-extraction job and may create several atomic memorieswait_for_extraction(bool, default true): for smart ingestion, poll for up to 20 seconds and return normalized atomic memories. Set false for immediate acknowledgement, then callhebbrix_extraction_statuswith the returned job id.wait_for_index(bool, default true): requests a bounded wait for memory-search availability. Check the returnedsearchableacknowledgement: if false, the write is durable but indexing is not confirmed; pollhebbrix_get(id)and do not repeat the write. It does not cover asynchronous knowledge-graph enrichment; usehebbrix_graph_statusfor durable completion. Itsrelated_memory_countcounts neighboring memories, not entity relationships; zero neighbors does not mean zero extracted edges.
hebbrix_extraction_status- Poll a smart-ingestion job until its created/updated memories or terminal error are available.hebbrix_remember_many- Store many facts in one call (one round-trip, one rate-limit hit). Passfacts(list of strings). Falls back to sequential writes on free/agent tiers.hebbrix_search- Semantic search (hybrid vector + BM25 + graph retrieval).query(string, required),limit(int, optional),collection_id(string, optional)min_score(float, default 0.0): drop weak matches — zero-relevance padding is always dropped; raise this to filter noise so you don't pay tokens for it.
hebbrix_get- Fetch one memory by id, with metadata.hebbrix_update- Correct a memory in place (old versions are kept).hebbrix_forget- Delete a memory by id.hebbrix_list- List recent memories.hebbrix_history- See how a memory changed over time.hebbrix_mark_used- Reinforce a memory you actually used (helpful=Truestrengthens it,Falseweakens it) so recall improves over time.hebbrix_export- Export a whole collection (memories + graph entities + profile) as JSON or Markdown, in one call.hebbrix_import- The inverse of export: import a list of facts, an export JSON, or notes/markdown into a collection (restore a backup, migrate, or seed fromCLAUDE.md).
Knowledge graph — Hebbrix automatically extracts entities and relationships from the memories you write, on every tier including agent mode, so all the graph reads below (entities, timelines, traversal, contradictions) work in agent mode too. Only explicit graph write / inference operations require a Pro plan.
hebbrix_search_entities- List known entities (people, orgs, tools, places).hebbrix_entity_timeline- What was true about an entity, and when.hebbrix_graph_query- Traverse relationships out from a named entity; pass atimestampfor point-in-time truth. Results are trimmed (from/to/type/valid_from), not raw backend payloads. (Free-text questions: usehebbrix_ask.)hebbrix_graph_status- Check one memory's asynchronous graph readiness, optionally polling for up to 30 seconds. Readiness comes from durable, source-revision-bound delivery acknowledgements—not elapsed time, search readiness, or an empty graph query. It distinguishes successful enrichment with no related facts from a still-processing, failed, or temporarily unreadable graph.hebbrix_contradictions- Surface facts that conflict with each other.
Procedural memory
hebbrix_create_procedure- Store a scoped condition/action procedure.hebbrix_list_procedures/hebbrix_get_procedure- Inspect owned procedures.hebbrix_update_procedure- Update mutable fields; ownership scope is immutable.hebbrix_execute_procedure- Execute a procedure and record the execution.hebbrix_delete_procedure- Idempotently delete a procedure and its executions. The API returns the same 204 for deleted, absent, and foreign-tenant IDs so the tool cannot reveal another tenant's identifier.
Reasoning & account
hebbrix_ask- One-call GraphRAG. Ask a natural-language question; it searches memory, synthesizes an answer with an LLM, and cites the memory ids it used. If synthesis abstains while authoritative search has grounded evidence, it returns that evidence assynthesis_status: "retrieval_only"instead of silently losing recall or pretending synthesis succeeded.hebbrix_confidence- How confident should the agent be before acting? Grounded in memory + past outcomes.hebbrix_log_decision- Record a decision and its outcome; feeds future confidence. Right after ahebbrix_confidencecheck you can log just theoutcome— the description auto-fills from what you asked.hebbrix_choose_action- Safely choose among repeatable strategies and create a causal decision receipt before acting. Supports per-user/context policies and explicitly bounded exploration.hebbrix_report_outcome- Close that decision loop later withsuccess, a bounded reward, or configured business metrics. Corrections replace prior evidence instead of double-counting it.hebbrix_learning_insights- Inspect posterior probabilities, credible intervals, effective evidence, and optional chronological-holdout policy readiness checks for one customer policy.hebbrix_list_collections- List the memory spaces this key can use.hebbrix_account_status- Tier, usage, limits, and expiry.hebbrix_claim_start/hebbrix_claim_verify- Optionally keep an accountless guest memory permanently, without changing its collection or losing data.
Every tool publishes explicit MCP safety annotations. hebbrix_claim_start is
marked as an external side effect because it sends email; deletion is marked
destructive; reads are marked read-only. The six-digit claim code is declared
as a write-only password field and is never logged or returned by this server.
MCP hosts still control their own tool-call history, so configure the host to
redact secret inputs if it persists conversation or tracing data.
The server also exposes a hebbrix://profile resource and a context prompt that inject the user's compiled profile.
Make Hebbrix the agent's memory
The server ships an instruction block telling the model to use Hebbrix for anything it would "remember." But some hosts (notably Claude Code) have their own file-based memory whose instructions live at the system-prompt level and can outrank an MCP server's instructions — so the agent may quietly write notes to a local file instead of Hebbrix.
The reliable fix is one line in your project's CLAUDE.md (or your assistant's system prompt / rules file):
## Memory
Use the Hebbrix MCP server as the single source of truth for long-term memory.
When you would remember, note, or save anything durable, call `hebbrix_remember`
(and `hebbrix_search` to recall). Do not write memory to local files or the
host's built-in memory.Cursor users: add the same to .cursorrules. This puts the preference at the level the host respects, so Hebbrix wins consistently.
Running modes
Local (default) — stdio. What the quick start does: one process per client.
Self-hosted HTTP — one instance, your machines:
HEBBRIX_API_KEY=mem_sk_... uvx hebbrix-mcp --transport streamable-http
# serves http://127.0.0.1:8080/mcpHosted — nothing to run and no account required. Point any HTTP-capable MCP client at the official hosted endpoint. The first handshake creates an isolated guest memory and a Secure, HttpOnly session cookie automatically:
{ "mcpServers": { "hebbrix": {
"url": "https://mcp.hebbrix.com/mcp"
}}}To use an existing Hebbrix account instead, add its API key (get one at hebbrix.com/dashboard/api-keys):
{ "mcpServers": { "hebbrix": {
"url": "https://mcp.hebbrix.com/mcp",
"headers": { "Authorization": "Bearer mem_sk_..." }
}}}Self-hosted multi-tenant — one instance, many users. Same shape on your own
infra. By default every request authenticates with its own Authorization
header:
HEBBRIX_MCP_MULTI_TENANT=1 HEBBRIX_MCP_HOST=0.0.0.0 uvx hebbrix-mcp --transport streamable-httpOr run the container (multi-tenant by default, GET /healthz for load-balancer probes):
docker build -t hebbrix-mcp . && docker run -p 8080:8080 hebbrix-mcpIn multi-tenant mode, the server resolves each authenticated key's default
collection automatically. An explicit collection_id still overrides it.
How it works
┌──────────────────┐ MCP (stdio or HTTP) ┌─────────────┐ HTTPS ┌──────────┐
│ Claude / Cursor / │ ───────────────────────→│ hebbrix-mcp │─────────────→│ Hebbrix │
│ Cline / any agent │ tool calls │ (this) │ REST API │ cloud │
└──────────────────┘ └─────────────┘ └──────────┘This package owns no durable memory state. Tool calls become REST calls against your Hebbrix tenant; memories, embeddings, the knowledge graph, and retrieval all live in the Hebbrix backend. The hosted accountless path keeps only a signed identity cookie in the MCP client so multiple stateless replicas can serve it. Delete the local package and your backend memories are still there.
Agent-mode accounts never break mid-task: when a limit is reached you get a structured error with a resolve field, not a failure. Writes stop before reads; reads keep working; the account goes read-only before it expires.
Debugging
Inspect the server with the MCP Inspector:
npx @modelcontextprotocol/inspector uvx hebbrix-mcpCommon issues:
HTTP 401on every call — the key is wrong or revoked. UnsetHEBBRIX_API_KEY, delete~/.hebbrix/config.json, and restart to re-provision, or paste a fresh key from the dashboard.Agent mode won't start (
auto-signup unavailable) — signup may be at daily capacity or your network blocks the API. SetHEBBRIX_API_KEYinstead.claimsaysEMAIL_IN_USE— claiming needs an email with no existing Hebbrix account. Use a fresh address (ayou+agent@gmail.comalias works).A memory isn't searchable immediately —
wait_for_index=truerequests a bounded wait, not an unconditional guarantee. Checksearchable; if false, pollhebbrix_get(id)and preserve the receipt. Do not repeat an accepted write.A just-written fact's entities aren't in the graph yet — knowledge-graph enrichment (entities, timelines, graph queries) runs asynchronously after the write and is not covered by
wait_for_index. It typically lands within ~30s; the write response'sgraph_enrichment: "processing"signals it's still in flight.
Development
git clone https://github.com/Hebbrix/hebbrix-mcp
cd hebbrix-mcp
python -m pip install uv==0.8.4
uv sync --frozen --extra dev
uv run --frozen pytest tests/ -q -W error # offline; no network or key needed
hebbrix-mcp # starts in agent mode on stdioSee CONTRIBUTING.md and CHANGELOG.md.
An opt-in integration check reproduces conversational recall, corrections, fresh-process retrieval, abstention, isolation, and disposable collection cleanup:
uv run --frozen python scripts/verify_recall.py --api http://localhost:8000It creates synthetic data in two new guest collections and deletes them in a
cleanup block. Remote targets require --allow-remote; --mcp URL selects the
hosted transport and --require-graph checks asynchronous graph enrichment too.
License
MIT — see LICENSE.
Links
Available Tools
33 toolshebbrix_account_statusARead-onlyIdempotent
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.
Inputs: no named parameters. Returns: object
hebbrix_askARead-onlyIdempotent
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.
Inputs: question (required), collection_id, include_graph. Returns: object
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.
policy_key identifies that decision type (for example support.reply).
actions are stable machine keys. context contains only factors that may
change which action works. The first action is the safe baseline unless
baseline_action is supplied. Only offer actions already authorized by the
host agent; learning optimizes among candidates and never grants permission.
Normal use: omit chosen_action; Hebbrix recommends conservatively. To log a
choice made elsewhere, pass chosen_action and its exact behavior-policy
action_probability (required with multiple actions). Set exploration_rate
to at most 0.2 only when controlled randomized learning is acceptable.
Keep the returned decision_id, perform chosen_action_key, then call
hebbrix_report_outcome when the real result arrives—even minutes or days
later. Missing outcomes are censored, never counted as failures.
Inputs: actions (required), policy_key (required), context, user_id, +6 more. Returns: object
hebbrix_claim_startADestructive
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_verify. The same memory,
collection, and guest credential carry over—nothing is migrated or reset.
Inputs: email (required). Returns: object
hebbrix_claim_verifyA
Finish claiming a guest memory with the emailed six-digit code.
Only call after hebbrix_claim_start and after the human supplies the
code. On success the same memories remain available and guest expiry/caps
are replaced by the normal claimed-account tier.
Inputs: code (required). Returns: object
hebbrix_confidenceARead-onlyIdempotent
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
constraint_conflict block and recommended_action is do_not_act.
Inputs: query (required), collection_id. Returns: object
hebbrix_contradictionsARead-onlyIdempotent
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.
Inputs: memory_id, collection_id. Returns: object
hebbrix_create_procedureB
Create a tenant-scoped learned procedure using canonical API fields.
Inputs: name (required), action (required), condition (required), run_id, +6 more. Returns: object
hebbrix_delete_procedureADestructiveIdempotent
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.
Inputs: procedure_id (required). Returns: object
hebbrix_entity_timelineARead-onlyIdempotent
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.
Inputs: entity_name (required), collection_id. Returns: object
hebbrix_execute_procedureB
Execute one tenant-owned procedure and record its execution.
Inputs: procedure_id (required), parameters, input_state. Returns: object
hebbrix_exportARead-onlyIdempotent
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.
Inputs: format, collection_id. Returns: object
hebbrix_extraction_statusARead-onlyIdempotent
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.
Inputs: job_id (required), collection_id. Returns: object
hebbrix_forgetADestructiveIdempotent
Delete a memory by id.
A successful deletion returns deleted=true and the requested memory id;
an already-absent id retains the structured 404 error and adds
already_absent=true. This stable tool shape does not depend on whether
the API's successful DELETE response has a JSON body.
Inputs: memory_id (required). Returns: object
hebbrix_getARead-onlyIdempotent
Fetch one memory by id, including its full content and metadata.
Inputs: memory_id (required). Returns: object
hebbrix_get_procedureARead-onlyIdempotent
Get one tenant-owned procedure by id.
Inputs: procedure_id (required). Returns: object
hebbrix_graph_queryARead-onlyIdempotent
Traverse the knowledge graph OUT FROM a named entity to find its
relationships and facts. Pass an ISO timestamp to ask what was true at
that point in time (bi-temporal). depth = graph hops (1-5).
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.
Inputs: entity (required), depth, timestamp, collection_id, +1 more. Returns: object
hebbrix_graph_statusARead-onlyIdempotent
Check whether one memory's asynchronous graph enrichment is ready.
wait_seconds optionally performs bounded polling (maximum 30 seconds).
ready means durable enrichment completed and the graph read succeeded.
graph_check.related_memory_count counts neighboring memories, NOT extracted
entity relationships. A zero count does not mean no edges were extracted.
This tool never fabricates edges from spelling conventions.
Inputs: memory_id (required), wait_seconds. Returns: object
hebbrix_historyARead-onlyIdempotent
Show the version history of a memory (how it changed over time, including supersessions). Useful to see what a fact used to be.
Inputs: memory_id (required). Returns: object
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.
data may be: a list of fact strings; a list of {"content": ...} objects; a
hebbrix_export JSON object (its "memories" are imported); or a plain/markdown
string (each non-empty, non-heading line becomes a memory, bullets stripped).
Returns {"imported", "failed", "memory_ids"}.
Inputs: data (required), collection_id, wait_for_index. Returns: object
hebbrix_learning_insightsARead-onlyIdempotent
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.
evaluate_readiness=true additionally runs chronological-holdout doubly
robust checks and refuses promotion when samples, randomized overlap, or
effective sample size are inadequate.
Inputs: policy_key (required), actions, context, user_id, +2 more. Returns: object
hebbrix_listBRead-onlyIdempotent
List recent memories in a collection.
Inputs: limit, collection_id. Returns: object
hebbrix_list_collectionsARead-onlyIdempotent
List the collections (memory spaces / tenants) available to this API key.
Inputs: no named parameters. Returns: object
hebbrix_list_proceduresBRead-onlyIdempotent
List learned procedures owned by the current tenant.
Inputs: skip, limit, category, active_only, +1 more. Returns: object
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.
Inputs: outcome, description, collection_id, decision_type. Returns: object
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. query is the question it helped answer, if handy.
Inputs: memory_id (required), query, helpful. Returns: object
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"}.
Inputs: content (required), tags, extract, collection_id, +2 more. Returns: object
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.
Inputs: facts (required), collection_id, wait_for_index. Returns: object
hebbrix_report_outcomeADestructive
Report the REAL delayed result of a prior hebbrix_choose_action.
The 30-second path is success=true/false, or reward in [-1, 1]. Custom
metrics must first be defined through the Outcome Memory REST API so their
direction and scale are explicit. Set final=false for an early signal and
report the settled value later. Set correction=true to replace previously
learned evidence without double-counting it. Reusing an idempotency_key is
safe; conflicting reuse is rejected.
Inputs: decision_id (required), final, reward, metrics, +4 more. Returns: object
hebbrix_searchARead-onlyIdempotent
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 min_score (0.0-1.0) to request an explicit absolute relevance floor.
Returns {"query", "count", "results": [{"id","content","score"}]}.
Inputs: query (required), limit, min_score, collection_id. Returns: object
hebbrix_search_entitiesARead-onlyIdempotent
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.
Inputs: limit, entity_type, collection_id. Returns: object
hebbrix_updateADestructive
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.
Inputs: memory_id (required), content, importance, wait_for_index. Returns: object
hebbrix_update_procedureADestructive
Update mutable fields on one tenant-owned procedure; scope is immutable.
Inputs: procedure_id (required), name, action, category, +4 more. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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.
Maintenance
Related MCP Connectors
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides AI agents with persistent, searchable memory that survives across conversations using semantic search, temporal versioning, and smart organization. Enables long-term context retention and cross-session continuity for AI assistants.14-
- FlicenseNot gradedqualityNot gradedmaintenanceGives AI agents persistent memory with bi-temporal tracking, automatically extracting entities from natural language and enabling time-travel queries to understand facts as they existed at any point in history.2-
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to build and query temporally-aware knowledge graphs from conversations and data, maintaining persistent memory of entities, relationships, and facts across interactions.-

Memsolus MCP Serverofficial
AlicenseAqualityDmaintenanceProvides persistent long-term memory for AI agents through semantic search and automated knowledge graph extraction. It enables agents to store, recall, and reason over facts, preferences, and relationships across multiple conversations and sessions.1415 npmMIT