Skip to main content
Glama
Hebbrix

Hebbrix MCP Server

Official
by Hebbrix

hebbrix_remember

Save a fact, decision, or preference for later recall. Optionally extract atomic facts from messy input and make them immediately searchable.

Instructions

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): guarantees MEMORY SEARCH availability — the memory is returned by hebbrix_search the moment this call returns (read-after-write). Set False for fire-and-forget 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"}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
contentYes
extractNo
collection_idNo
wait_for_indexNo
wait_for_extractionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly explains defaults, async extraction behavior (20s polling, job_id), read-after-write guarantees with wait_for_index, and asynchronous graph enrichment with the 'graph_enrichment': 'processing' flag. It also discloses the return shape (including an error case).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured, starting with the core purpose and then logically covering parameters, graph enrichment, bulk-write guidance, and return format. Every sentence adds actionable detail, and the use of paragraphs and bullet-like lines makes it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive for the tool's complexity: it covers async jobs, polling, indexing guarantees, graph enrichment timing, error returns, and gives practical bulk-write tips. The output schema fills in the full return structure, so the description appropriately focuses on behavioral and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the schema for content, extract, wait_for_index, and wait_for_extraction, explaining their behavior and defaults. However, it does not mention tags or collection_id, leaving a minor gap given the schema itself has no descriptions (0% coverage).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb+resource ('Store a memory') and specifies the exact use case: 'whenever the user shares a fact, decision, or preference worth recalling later.' It also distinguishes this tool from file-based notes and mentions related tools like hebbrix_search and hebbrix_extraction_status, providing context beyond the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Use this whenever...' and 'prefer it over writing notes to files.' It also provides alternatives, such as using hebbrix_extraction_status for polling and choosing between extract=True, wait_for_index=False, and bulk-write strategies. The 'Saving several facts at once?' paragraph clearly explains trade-offs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hebbrix/hebbrix-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server