Skip to main content
Glama
Hebbrix MCP Server

Hebbrix MCP Server

Official
by Hebbrix

Hebbrix MCP Server

PyPI CI Python License: MIT

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"] }
  }
}
NOTE

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.com

Related MCP server: Bi-Temporal Knowledge Graph MCP Server

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@hebbrix

That'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

HEBBRIX_API_KEY

(agent mode mints one)

Your Hebbrix bearer token

HEBBRIX_COLLECTION_ID

(agent mode sets one)

Default collection for writes/reads

HEBBRIX_API_BASE

https://api.hebbrix.com/v1

API endpoint override

HEBBRIX_CONFIG

~/.hebbrix/config.json

Where agent-mode credentials are saved

HEBBRIX_MCP_HOST

127.0.0.1

Bind host (HTTP transports)

HEBBRIX_MCP_PORT

8080

Bind port (HTTP transports)

HEBBRIX_MCP_MULTI_TENANT

off

Hosted mode: per-request Authorization header auth

HEBBRIX_MCP_ACCOUNTLESS

off

Hosted mode: mint a bounded guest identity on unauthenticated initialize

HEBBRIX_MCP_SESSION_SECRET

(required for accountless)

HMAC secret for stateless Secure guest cookies

HEBBRIX_MCP_INTERNAL_SECRET

(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 text

    • tags (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 memories

    • wait_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 call hebbrix_extraction_status with the returned job id.

    • wait_for_index (bool, default true): requests a bounded wait for memory-search availability. Check the returned searchable acknowledgement: if false, the write is durable but indexing is not confirmed; poll hebbrix_get(id) and do not repeat the write. It does not cover asynchronous knowledge-graph enrichment; use hebbrix_graph_status for durable completion. Its related_memory_count counts 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). Pass facts (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=True strengthens it, False weakens 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 from CLAUDE.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 a timestamp for point-in-time truth. Results are trimmed (from/to/type/valid_from), not raw backend payloads. (Free-text questions: use hebbrix_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 as synthesis_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 a hebbrix_confidence check you can log just the outcome — 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 with success, 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/mcp

Hosted — 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-http

Or run the container (multi-tenant by default, GET /healthz for load-balancer probes):

docker build -t hebbrix-mcp . && docker run -p 8080:8080 hebbrix-mcp

In 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-mcp

Common issues:

  • HTTP 401 on every call — the key is wrong or revoked. Unset HEBBRIX_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. Set HEBBRIX_API_KEY instead.

  • claim says EMAIL_IN_USE — claiming needs an email with no existing Hebbrix account. Use a fresh address (a you+agent@gmail.com alias works).

  • A memory isn't searchable immediately — wait_for_index=true requests a bounded wait, not an unconditional guarantee. Check searchable; if false, poll hebbrix_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's graph_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 stdio

See 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:8000

It 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.

Available Tools

33 tools
hebbrix_account_statusA
Read-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_askA
Read-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_startA
Destructive

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_confidenceA
Read-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_contradictionsA
Read-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_procedureA
DestructiveIdempotent

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_timelineA
Read-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_exportA
Read-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_statusA
Read-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_forgetA
DestructiveIdempotent

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_getA
Read-onlyIdempotent

Fetch one memory by id, including its full content and metadata.

Inputs: memory_id (required). Returns: object

hebbrix_get_procedureA
Read-onlyIdempotent

Get one tenant-owned procedure by id.

Inputs: procedure_id (required). Returns: object

hebbrix_graph_queryA
Read-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_statusA
Read-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_historyA
Read-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_insightsA
Read-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_listB
Read-onlyIdempotent

List recent memories in a collection.

Inputs: limit, collection_id. Returns: object

hebbrix_list_collectionsA
Read-onlyIdempotent

List the collections (memory spaces / tenants) available to this API key.

Inputs: no named parameters. Returns: object

hebbrix_list_proceduresB
Read-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_outcomeA
Destructive

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_search_entitiesA
Read-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_updateA
Destructive

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_procedureA
Destructive

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

    A3.6/5.0

    Scored across 33 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count2/5

    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.

    Completeness4/5

    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

    ActivityStale
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      Provides 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
      -
    • F
      license
      Not graded
      quality
      D
      maintenance
      Enables AI assistants to build and query temporally-aware knowledge graphs from conversations and data, maintaining persistent memory of entities, relationships, and facts across interactions.
      -
    • A
      license
      A
      quality
      D
      maintenance
      Provides 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.
      14
      15 npm
      MIT