Hebbrix MCP Server
OfficialServer Quality Checklist
Latest release: v0.5.4
- Disambiguation5/5
Every tool targets a distinct operation: memory CRUD, search, knowledge graph, decision learning, account/claim management, import/export. Even similar tools like hebbrix_remember vs hebbrix_remember_many are clearly differentiated by single vs batch, and hebbrix_search vs hebbrix_ask by raw vs synthesized results.
Naming Consistency4/5All tools share the hebbrix_ prefix and use lowercase snake_case, making them predictable. However, naming style mixes verb-first (hebbrix_search, hebbrix_get) and noun-first (hebbrix_contradictions, hebbrix_confidence), so it is not perfectly uniform verb_noun like the calibration high example.
Tool Count3/5At 26 tools, this exceeds the typical 3-15 well-scoped range and edges into heavy territory. That said, the server covers a broad domain (memory, graph, decision learning, account lifecycle), so each tool earns its place, but the surface is large for an agent to navigate.
Completeness5/5The surface covers the full memory lifecycle: create (remember/remember_many/import), read (get/list/search/ask), update, delete, version history, plus knowledge graph traversal, contradiction detection, confidence scoring, decision logging, and data portability. No obvious dead ends or missing core operations.
Average 4.2/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 38 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation but does not explicitly state non-destructive behavior, rate limits, authentication needs, or how 'recent' is defined. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. However, it could benefit from additional structuring to clarify parameters or use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with two parameters and an output schema. It does not explain return value format, pagination, or handling of null collection_id, leaving gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the parameters. It fails to clarify that collection_id is optional and what the limit parameter controls beyond its default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'memories', and the context 'in a collection'. This distinguishes it from sibling tools like hebbrix_list_collections which lists collections, and hebbrix_search which searches memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other sibling tools such as hebbrix_search or hebbrix_get. There is no mention of conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates it is a read operation showing history, but does not disclose potential limitations (e.g., pagination, performance implications) or require any special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core action. It could be slightly more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and an output schema, the description covers purpose and use case adequately but lacks parameter guidance and some behavioral details, leaving it slightly below complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite only one parameter (memory_id), the schema coverage is 0% and the description does not add any semantic guidance about what memory_id is or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows 'version history of a memory' including supersessions, distinguishing it from siblings like hebbrix_get (current state). However, 'version history' could be more explicit about the structure (e.g., list of snapshots with timestamps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful to see what a fact used to be', providing a use case. However, it does not explicitly compare with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions what is returned (content and metadata) but does not disclose error handling, rate limits, or any side effects. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return value details are not needed. However, description is sparse on parameter details and usage context. For a simple tool it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Merely mentions 'by id' but does not add format, constraints, or examples beyond the schema's field name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (fetch), the resource (memory by id), and what is returned (full content and metadata). Distinguishes from siblings like 'list' and 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., hebbrix_list, hebbrix_search). Does not specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It usefully explains the scanning behavior and optional memory_id, but it does not explicitly state that this is a read-only/no-side-effect operation, nor does it cover behavior related to collection_id or potential limits. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a usage example and a contextual trigger. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and presence of an output schema, the description conveys the core purpose and main usage pattern. However, the omission of collection_id leaves a notable gap in understanding the full scanning/filtering scope. It is serviceable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives meaning to memory_id ('check one memory, or omit to scan'), but collection_id is completely ignored, leaving a required dimension of the tool's filtering behavior unexplained. The compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource ('Surface contradicting facts in the knowledge graph') and gives a concrete example. This makes the tool's purpose unmistakable and clearly distinguishes it from siblings like hebbrix_search or hebbrix_get, which retrieve facts rather than check for contradictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage direction: 'Use before trusting a fact that feels ambiguous' and explains the memory_id behavior ('Pass... or omit to scan'). It lacks explicit when-not-to-use or named alternatives, so it misses the top score but is still well-guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full burden. It discloses success return (deleted=true), the already-absent edge case (404 with already_absent=true), and a stability note about API response shape. This is rich behavioral context beyond a simple 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action followed by response/edge-case details. No fluff, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description is quite complete: it covers success, failure, and idempotent-like behavior, plus a stability note. It lacks usage context and side-effect warnings, but those are less critical given the tool's simplicity and presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It only says 'by id', which is redundant with the parameter name memory_id. It does not explain how to obtain the id, its format, or any constraints, failing to add meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a memory by id' – a specific verb (delete) and resource (memory by id). It clearly distinguishes this tool from siblings like hebbrix_update (modify) and hebbrix_get (read), with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting a memory but provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no caution about irreversibility. It relies on the tool name and general semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: it searches, synthesizes with an LLM, cites memory ids, conditionally returns graph/profile, and falls back to raw search hits if the reasoning backend is unavailable. It does not explicitly state read-only status or potential latency/cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but information-dense, with the primary purpose front-loaded. It efficiently covers motivation, example, return format, and fallback behavior in a few sentences without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description usefully elaborates on return design and fallback behavior. It covers the composite nature and optional outputs, but omits collection_id semantics and explicit read-only clarification, leaving small gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implicitly explains include_graph ('graph (when include_graph)') but never explains collection_id, which is a non-obvious optional parameter. The question parameter is self-explanatory, but the coverage gap hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Answer a natural-language question from memory in ONE call.' It clearly distinguishes itself from sibling tools by stating it replaces orchestrating hebbrix_search + hebbrix_graph_query + profile, and provides a concrete example question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use for natural-language synthesis questions and mentions the orchestration it avoids, naming alternatives. However, it does not give explicit when-not-to-use cases (e.g., simple lookups) or direct comparisons to other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it discloses that the tool returns a confidence score and recommended action, and explains the special `constraint_conflict` behavior with a concrete example (PR line limit). It does not explicitly state whether the tool mutates state, but the 'ask' framing implies a non-destructive read-like operation. The description adds meaningful behavioral context beyond the bare tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, the second gives usage guidance, and the third explains the return. The additional paragraph about numeric rule violations is specific and earns its place. No verbose filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema that likely documents return fields, the description covers purpose, usage, and a key edge case well. However, it omits any explanation of the `collection_id` parameter and does not mention potential side effects or prerequisites. It is adequate but not fully complete for an agent to invoke with full confidence across all optional arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the `query` parameter is a description of the proposed action, but it never explicitly documents either parameter. The optional `collection_id` is completely unexplained, leaving the agent without guidance on when or how to set it. This is a meaningful gap for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Ask how confident the agent should be before acting on something, grounded in stored memory and past decision outcomes.' It specifies the resource (memory and decision outcomes), the action (returns a confidence score and recommended action), and distinguishes this from siblings like hebbrix_search or hebbrix_ask by focusing on pre-action confidence assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: 'Call this before a consequential autonomous action.' It does not name alternatives or exclusions, but the instruction clearly differentiates when this tool is appropriate compared to general memory or search tools. This is strong guidance, though it could be more explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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. It states the action is a List but does not mention authentication requirements, side effects, or constraints beyond the API key. For a simple read operation, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (not shown but noted), the description is sufficient. It explains what the tool does and what it returns (collections), but lacks any mention of return structure or pagination, which is acceptable for a simple list with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% by default. The description adds no parameter detail, but according to the baseline rule for 0 parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'collections', and clarifies with parenthetical synonyms 'memory spaces / tenants' and scope 'available to this API key'. This distinguishes it from siblings like hebbrix_list or hebbrix_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to see available collections. However, no explicit when-not or alternative tools are mentioned, leaving room for ambiguity among list-type tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context: the tool is bi-temporal, operates on a single entity, and is case-insensitive. It doesn't discuss permissions or side effects, but for a read-style timeline query, the provided behavioral details are reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage guidance and a relevant behavioral note (case-insensitivity). Every sentence earns its place, with no wasted words or redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose and an output schema, so the description doesn't need to detail return values. It explains the temporal nature and typical use cases, but it could be more complete by explaining the optional collection_id parameter and what types of entities are supported. Still, for a moderately complex query tool, the coverage is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description implies the entity_name parameter by discussing 'one entity' and 'a person, company, or thing,' but it never explicitly names or explains the parameters, and collection_id is completely unaddressed. The description adds minimal value beyond the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines a bi-temporal timeline for a single entity, using specific verb-like phrasing ('what facts were true about it and when') and distinguishes itself from siblings by focusing on temporal queries about one entity. It addresses 'what changed' and 'what was true at time X' questions, which is uniquely specific among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use this for "what changed" / "what was true at time X" questions'), which provides clear context. However, it does not mention when not to use it or name alternatives, so it misses the full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It explains accepted input formats (list of strings, objects, export JSON, plain/markdown string) and the return shape, but omits critical mutation semantics: whether import merges or replaces existing memories, how collection_id resolves when null, and what 'failed' means. This leaves significant behavioral ambiguity for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary, then use cases, then data formats, then return value. Every sentence adds value; there is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (flexible data input, optional collection, indexing flag) and no annotations. The description covers purpose, usage, and return, but misses side-effect details and optional parameter behavior. It would be more complete with notes on merge-vs-replace and collection defaulting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed meaning for the `data` parameter, enumerating four accepted types and transformation rules. However, it says nothing about `collection_id` or `wait_for_index`, leaving two of three parameters underdocumented. Given schema description coverage is 0%, this incomplete compensation yields below-optimal parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Import memories into a collection — the inverse of hebbrix_export', clearly stating the verb, resource, and scope. It further distinguishes this tool from siblings by framing it as the opposite of export and listing concrete use cases (restore, migrate, seed). This is specific and differentiates from related tools like hebbrix_remember_many.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use it to restore a backup, migrate a collection, or seed a new one from notes/CLAUDE.md', giving clear when-to-use guidance. The 'inverse of hebbrix_export' phrasing also names the alternative tool, satisfying the criterion for explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the behavioral effect on hebbrix_confidence and the auto-fill behavior from the last confidence check. It does not mention side effects like reversibility or permissions, but for a logging tool it provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and includes a useful shortcut in a separate paragraph. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description omits meaning for two optional parameters and does not mention any use-case exclusions. The output schema exists, so return values are covered, yet the missing parameter semantics and limited guidance on when not to use the tool leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'outcome' with allowed values (success | failure | partial) and hints that 'description' is the choice, but it does not explain 'collection_id' or 'decision_type'. This leaves two of four parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource ('Record a decision') and explains its role in feeding hebbrix_confidence. It distinguishes itself from sibling memory tools by focusing on decision logging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use it (right after a hebbrix_confidence check) and describes the shortcut to log just the outcome. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the tool exports everything in a collection, explains the two output formats and the 'document' key for markdown, and assures 'nothing is locked in'. It doesn't explicitly state non-destructive behavior, but the 'export' framing implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, focused sentences: clear action, usage context, and format clarification. No redundant or vague language, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional parameters and an output schema, the description need not spell out return structures. It sufficiently covers purpose, scope, and format variants, though a precise note on collection_id's default behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'format' parameter's values and return types, but does not explain the semantics of 'collection_id' (e.g., what null means). With only one of two parameters clarified, this is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and the resource ('a collection'), and enumerates what is included (memories, knowledge-graph entities, compiled profile). This distinguishes it from sibling tools like hebbrix_get (single item retrieval) and hebbrix_search (query-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'use it to back up or migrate a memory space'. It implies when to use for complete data portability, but does not explicitly mention when not to use or name alternative tools for targeted exports, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds useful behavioral context (bi-temporal querying, graph hops). However, it doesn't mention whether the tool is read-only or if any side effects exist, though the query nature implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core behavior, and contains no redundant information. Every sentence contributes either to what the tool does or how it differs from an alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a graph traversal tool, the description covers the essential behavior, limits, and the main alternative. The presence of an output schema reduces the need to describe return values. It falls short only in not detailing all filter parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains depth and timestamp semantics but leaves collection_id and relation_type unexplained. The 'entity' parameter is self-evident from the tool name and description, but the others are not fully clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Traverse the knowledge graph OUT FROM a named entity to find its relationships and facts.' It also distinguishes itself from the sibling tool hebbrix_ask, which answers prose questions, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to hebbrix_ask for free-text questions and clarifies that this endpoint is for known entities. It also gives usage constraints like depth range (1-5) and timestamp use, providing clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses the tool's main behavior: returning posterior probabilities, credible intervals, evidence metrics, and observation counts. It also explicitly describes the conditional 'evaluate_readiness' mode with its refusal criteria, which is valuable behavioral detail. However, it does not explicitly state whether the tool has side effects (e.g., if it only reads data), though this is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently structured. The first sentence states the core purpose, and the second sentence lists specific outputs and conditional behavior. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, conditional mode, output schema), the description provides a solid level of completeness. It describes the returned values, the evaluate_readiness behavior, and refusal criteria. The main gap is missing explanations for 'actions' and 'collection_id', but the output schema and the rest of the description cover most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for policy_key ('one customer policy'), user_id/context ('this exact tenant/user/context'), and evaluate_readiness (with detailed behavior). However, it does not explain the 'actions' parameter or 'collection_id', leaving two parameters with only their titles for interpretation. This is a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Explain what one customer policy has learned, with uncertainty,' which uses a specific verb and resource. It clearly distinguishes itself from sibling tools by focusing on learning insights for a single policy, complete with uncertainty quantification. The detail about posterior probabilities and credible intervals confirms the tool's specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting the learning state of a specific policy in the context of a tenant/user/context. It clarifies the evaluate_readiness flag's conditional behavior. However, it does not explicitly state when to use this tool over alternatives like 'hebbrix_confidence' or 'hebbrix_ask', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and delivers: it discloses that zero-relevance padding rows are dropped, that uncalibrated candidates are auto-verified, and that noise is suppressed. It also states the return format. It does not mention auth or rate limits, but for a read-only search tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: the critical usage directive is front-loaded, followed by behavioral details and a return format snippet. Every sentence adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage context, key parameter semantics, behavioral details, and return format. With the output schema available, the omission of limit/collection_id explanations is a minor gap. It is complete enough for an agent to invoke the tool correctly, though more parameter guidance would elevate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains min_score's purpose ('explicit absolute relevance floor') and range (0.0-1.0), which adds value beyond the schema. However, it says nothing about query, limit, or collection_id; those rely solely on schema titles and defaults. Since schema coverage is low, the description only partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Semantic search over memories' with a clear verb and resource, and the instruction to 'Always call this BEFORE answering questions...' provides strong context. It distinguishes itself from siblings by positioning itself as the memory-search step prior to answering, which is distinct from hebbrix_ask or hebbrix_search_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Always call this BEFORE answering questions that depend on prior context, decisions, or user preferences.' It also offers a conditional instruction for raising min_score. However, it does not name alternative tools or explicitly state when not to use it, so it falls short of full differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical asynchronous behavior: entities are enriched asynchronously after a write, not covered by wait_for_index, with a ~30s delay and expected empty results. This is valuable behavioral context beyond any annotation, which is especially important since no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs, first sentence states purpose, second gives usage, and the note adds essential behavioral information. Every sentence earns its place without redundancy or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, and a key behavioral caveat, but leaves two of three parameter semantics unexplained and doesn't mention ordering or pagination. The existence of an output schema offsets return-format details, yet the missing parameter info makes it incomplete for full agent self-sufficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters. It only mentions the optional filter on entity_type (the parameter is mentioned by name), but limit and collection_id are completely unexplained. This is a significant gap for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific verb+resource: 'List entities in the knowledge graph' with example entity types. It also differentiates from siblings by targeting entity listing specifically ('who/what do I know about' questions), which is distinct from search, timeline, or graph query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use for "who/what do I know about" questions.' This gives clear guidance on when to use the tool. However, it does not explicitly name alternatives or state when not to use it, missing the 'when-not' component for a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description thoroughly discloses the polling lifecycle: transient statuses (queued/processing/indexing_pending), terminal outcomes (completed with memories, failed with error), and expiration after retention window. This is valuable behavioral context beyond any structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, return behavior, and expiration warning. Every sentence contributes distinct information, and the most important fact (polling) is front-loaded. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although it lacks parameter details, the output schema exists to cover return values. The description covers the polling behavior, terminal states, error cases, and job expiration, making it sufficiently complete for a status-polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain job_id or collection_id at all. The parameter names are only mildly self-explanatory, and the description fails to clarify how collection_id is used. It does not add meaningful value beyond the schema's basic type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls a smart-ingestion job, with a specific verb ('Poll') and resource. It further distinguishes itself by referencing that the job comes from hebbrix_remember(extract=True), making it unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly says when to use the tool (after hebbrix_remember with extract=True) and gives operational guidance (poll promptly). It does not explicitly mention alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries the load. It discloses non-destructive behavior via version history, read-after-write guarantees, and the ability to opt out with wait_for_index=False. This is valuable context beyond the schema. Could mention more about importance but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then flag explanation. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, usage, key behavioral nuances, and enough parameter context for a simple update tool. Output schema covers return values, so no need to explain that. Lacks only the importance parameter documentation, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain params. It explains content ('pass the new content') and wait_for_index in detail, but memory_id is implied by the tool name and importance is entirely undocumented. This is a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates an existing memory in place, preserves version history, and explicitly distinguishes from remembering a contradicting copy. The verb 'update' specifies the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use for correcting a stored fact rather than creating a duplicate memory, also explains the wait_for_index flag for synchronous vs fire-and-forget behavior. This gives clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description transparently describes what the tool provides and the intended agent behavior in auto-provisioned mode. Does not mention authentication or non-destructive nature, but the behavioral guidance is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose, second provides actionable guidance. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description sufficiently covers what the tool returns and the appropriate action. Complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds meaning by specifying the output content (tier, usage, limits, expiry) beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns account details (tier, usage, limits, expiry) for the agent's account, distinguishing it from sibling tools that handle memory or data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to relay the claim command to the human when usage status is 'warning' or worse, providing clear context for using the tool and acting on results. Lacks explicit 'when not to use' but is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key success behavior: memories remain available and guest expiry/caps are replaced by the normal claimed-account tier. It does not cover failure cases or invalid codes, but the main side effect is clearly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences/paragraphs, front-loads the purpose, and every sentence adds value—first the action, then the prerequisite and outcome. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and the presence of an output schema, the description covers purpose, preconditions, and success behavior adequately. It omits edge cases like an invalid code, but the output schema likely handles error reporting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'code' is a string, but the description explains it is the 'emailed six-digit code' that the human supplies, providing format, source, and context. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Finish claiming') and identifies the resource ('a guest memory') and method ('emailed six-digit code'). It clearly distinguishes this from the prerequisite hebbrix_claim_start, making the tool's role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the only valid calling context: after hebbrix_claim_start and after the human supplies the code. This is a strong precondition and exclusion, though it does not mention alternative tools for verification beyond the implicit sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden and does so well: it defines the standard success/reward path, requires custom metrics to be pre-defined via the Outcome Memory REST API, explains early vs settled signals, explains correction replaces evidence without double-counting, and discloses idempotency conflict behavior. This goes well beyond a bare 'report' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the purpose, and each additional sentence earns its place by explaining the 30-second path, metrics requirement, and special flags. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter reporting tool with no annotations, the description is largely complete: it covers the workflow, key parameter semantics, and idempotency/correction safeguards. The output schema covers return values, and the required decision_id is obvious. It is slightly incomplete in not describing the confidence parameter or explicitly contrasting with sibling tools, but is still highly usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It explains success/reward, metrics, final, correction, and idempotency_key, covering most inputs. It does not explain the confidence parameter or decision_id (though decision_id is required and self-explanatory), leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Report the REAL delayed result of a prior hebbrix_choose_action.' This clearly distinguishes it from siblings like hebbrix_choose_action (which chooses/asks) and hebbrix_mark_used (which marks used), and anchors its role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for reporting delayed results of a prior hebbrix_choose_action, and provides conditional guidance for final=false, correction=true, and idempotency_key conflicts. However, it does not explicitly contrast with sibling tools or state when not to use it, so it lacks explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that a six-digit code is sent to the email, that the code is passed to hebbrix_claim_verify, and that memory, collection, and guest credential carry over with no migration or reset. It could mention side effects like sending an email or potential rate limits, but the disclosed traits are meaningful and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded with the main purpose. Every sentence adds value: the precondition, the code flow, the continuation tool, and the guarantee about preserved data. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple structure (one required parameter, no nested objects, and an output schema present), the description fully covers the essential context: what the tool does, when to call it, what the user must have already done, what happens next, and what remains unchanged. The output schema covers return details, so the description doesn't need to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so by explaining that the email is the destination for the six-digit code and is provided by the human as part of the claim request. While it doesn't specify format or validation, the single 'email' parameter's purpose is clearly contextualized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: starting an email claim process to keep an accountless guest memory permanently. It uses a specific verb ('starting') and resource ('email claim'), and distinguishes itself from the sibling 'hebbrix_claim_verify' by describing the start step that precedes verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Only call this after the human explicitly asks to claim/keep the guest memory and provides the email address.' It also names the next step and points to the alternative sibling tool, 'hebbrix_claim_verify', clarifying the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the core behavioral effect: helpful=True strengthens the memory, helpful=False weakens it, and over time this affects ranking ('makes the memories you rely on rank higher and unused ones fade'). This clearly explains the mutation and its consequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action and purpose. The first sentence packs the core function and usage, the second adds long-term context, and the third explains a parameter. No excessive or redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential dimensions: what it does, when to call, how parameters affect behavior, and the long-term effect. No major gaps are apparent for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must add meaning. It explains the `helpful` parameter's boolean effect (strengthens/weakens) and clarifies `query` as 'the question it helped answer, if handy'. `memory_id` is not explicitly described, but its role is self-evident from the tool name and schema requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reinforce') and clearly identifies the resource ('a memory you actually USED to answer'). It explicitly frames the tool as a feedback mechanism for Hebbian recall, distinguishing it from sibling tools like hebbrix_search, hebbrix_remember, and hebbrix_forget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'call this when a retrieved memory was helpful... or was noise'. It clearly indicates the tool is for post-retrieval reinforcement, but does not mention alternative tools for other operations or provide explicit when-not-to-use exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It reveals that the first action is the safe baseline, that only authorized actions are allowed, that exploration_rate is capped at 0.2, that missing outcomes are censored rather than counted as failures, and that action_probability is required with multiple actions. These are meaningful behavioral traits not obvious from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately so for a complex 10-parameter tool. It is front-loaded with the core purpose, then organized into usage modes, parameter semantics, and the required outcome-reporting follow-up. Every sentence provides operational value; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, an output schema, and rich parameter/behavioral details, the description is complete. It explains the full decision lifecycle—record, perform, report—and covers safety constraints, exploration, and outcome censoring. Optional parameters like user_id and collection_id are conventional and don't need elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by defining the key parameters: policy_key identifies the decision type, actions are stable machine keys, context should only contain factors that affect the decision, baseline_action overrides the first action default, and chosen_action/action_probability/exploration_rate are explained with usage rules. The remaining optional parameters (user_id, collection_id, idempotency_key) are conventional and self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, non-tautological statement: 'Choose and RECORD an action before its result is known.' It clearly identifies the resource (an action decision) and distinguishes the tool's role from the outcome-reporting sibling by instructing the caller to later call hebbrix_report_outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context: 'Use for repeatable decisions whose real outcome can be reported later,' and it contrasts normal use (omit chosen_action) with logging an external choice (pass chosen_action). It also sets an explicit constraint on exploration_rate. However, it does not explicitly name alternative tools or state when not to use this tool versus siblings like hebbrix_log_decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so admirably. It discloses the return structure (created/failed/memory_ids), the default of wait_for_index=False, the option to block for searchability, and the transparent fallback to sequential writes on lower tiers with a 'fallback' field. This goes far beyond a simple mutation statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than minimal, every sentence provides essential information: purpose, usage, parameter behavior, return values, and tier caveats. It is front-loaded with the core purpose and gracefully flows into details, making the length justified and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, usage, parameters, returns, and edge cases (free-tier fallback). An output schema exists, so the description doesn't need to enumerate returns, but it still provides key fields. For a batch tool with nuances, this is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining 'facts' as 'a list of short, self-contained facts (one fact per string)' and clarifying 'wait_for_index' with its default and effect. However, it does not explain 'collection_id' at all; while the name and default null make it self-evident, full compensation would require at least a brief mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Store MANY facts in one call,' using a specific verb and resource while explicitly distinguishing this from hebbrix_remember by stating 'use this instead of calling hebbrix_remember N times.' This clearly identifies the tool's batch purpose and differentiates it from its primary sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'When you've extracted several distinct facts from one user message, use this instead of calling hebbrix_remember N times.' It also explains the benefit (one round-trip, one rate-limit hit) and notes the free-tier fallback behavior, offering a complete decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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