Engram

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation4/5
Most tools have clearly distinct purposes, but brain_write and brain_edit overlap significantly: both can create or overwrite a note, with the only differentiator being that edit also accepts raw markdown. Other potentially similar tools like brain_supersede vs brain_move and brain_backlinks vs brain_graph are well differentiated by their descriptions.
Naming Consistency4/5
All tool names share the consistent 'brain_' prefix and snake_case style, making them easy to group. However, the second element mixes verb forms (list, append, move, search, read, write, edit, supersede, capture, delete) with noun forms (schema, recent, tree, backlinks, graph), so the pattern is not purely verb_noun.
Tool Count4/5
At 16 tools, the set is slightly above the typical 3-15 range for a well-scoped server, but the rich feature set (CRUD, search, graph, lifecycle operations) justifies the count. Each tool earns its place, including the specialized supersede and capture tools.
Completeness5/5
The tool surface covers the full note lifecycle: create (brain_write, brain_capture), read (brain_read, brain_search, brain_list), update (brain_edit, brain_append, brain_supersede), delete (brain_delete), and organization (brain_move, brain_tree, brain_create_folder). Discovery is also complete with recent, backlinks, graph, and schema. No significant gaps are evident for a personal vault manager.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 88 commits in the last 12 weeks
- Last stable release on August 11, 2026
- 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to 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?
No annotations provided, so description must disclose behavior. It does not state that it is read-only, what happens on missing paths, or any side effects. Agents lack key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short phrase but not a full sentence. It is concise but at the cost of informativeness. Front-loaded but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return format. It only says 'Notes that link to the given note' without describing structure, count, or any metadata. Insufficient for a simple but non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with one parameter described as 'vault-relative path'. Description adds no extra meaning beyond this, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns notes that link to a given note, distinguishing it from siblings like brain_read or brain_graph. However, it omits a verb like 'List' or 'Get', and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., brain_graph, brain_search). The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 discloses it is a knowledge graph (likely read-only) but does not mention performance, limitations, output format, or what 'related:' means. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, front-loaded with the key concept. However, it may be too brief for such a complex tool, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and a single optional parameter. The description fails to explain what nodes and edges look like, how the folder filter works, or what 'related:' entails. Incomplete for a graph-building tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional folder filter. The description repeats 'optional folder filter' without adding any meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a knowledge graph with nodes and edges from wikilinks and related, which is a specific verb+resource. However, it does not explicitly distinguish from sibling tools like brain_tree or brain_list, which might also deal with connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., brain_tree, brain_search). Agent must infer from the concept of 'knowledge graph' without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says 'Return,' which implies read-only, but it does not explicitly confirm the absence of side effects, permissions, or other caveats.
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?
One concise, clear sentence with no filler. It is perfectly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, this is nearly complete. It could add details about the tree structure (e.g., root, depth, whether empty folders are included), but the description is adequate for a simple vault tree.
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 tool has no parameters, so the description does not need to add parameter semantics. Baseline 4 applies.
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?
Clearly states the tool returns the vault's folder/file tree. The term 'tree' distinguishes it from sibling tools like brain_list or brain_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this compared with brain_list, brain_schema, or brain_graph. The description only states what it does, not how to choose 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?
With no annotations, the description bears full responsibility for behavioral disclosure. It discloses the creation-on-missing behavior, which is key. However, it does not mention safety (e.g., non-destructive nature), return values, or any side effects. The disclosure is minimal but not misleading.
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 a single sentence that immediately states the verb and resource, with parenthetical clarification. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the core behavior. However, it omits return value, formatting expectations, and any constraints (e.g., file size). Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented in the schema. The description adds no additional semantic meaning beyond what the schema provides (e.g., path format or text handling). Baseline 3 is appropriate.
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 action 'append' and the resource 'note', and adds the important qualifier that it creates the note if missing. This distinguishes it from sibling tools like 'brain_write' (which likely overwrites) and 'brain_edit' (which may modify existing content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used for appending text, but provides no guidance on when to use alternatives (e.g., brain_write, brain_edit) or when not to use this tool. No explicit context for choosing this over siblings.
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?
Without annotations, the description carries the full burden. It discloses that a '.gitkeep' file is added, which is a useful behavioral detail. However, it does not mention what happens if the path already exists, permission requirements, or error handling, leaving gaps.
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 a single, front-loaded sentence that efficiently conveys the necessary information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description is fairly complete. It includes the .gitkeep detail which is contextually relevant. However, it could mention whether creation is recursive or if the operation is idempotent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description for the single parameter 'path'. The tool description does not add extra semantics beyond the schema, so baseline score of 3 applies.
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 action 'Create' and the resource 'a new folder in the vault', distinguishing it from siblings like brain_delete or brain_write. It also includes a specific detail about '.gitkeep' which adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as brain_write or brain_capture. The description implies it's for folder creation but lacks context about prerequisites or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the ordering ('newest first') and the 'since' parameter, but it does not state whether the tool is read-only, what the output format is, or any other behavioral traits. For a tool with no annotations, this is insufficient.
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 consists of two sentences: the first states what the tool does, and the second gives usage guidance. It is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool is simple (2 optional parameters), the description is fairly complete. It explains the ordering, the purpose, and the usage. However, it lacks details about the output format, which might be important for an agent to process the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the input schema. The description adds no additional semantic meaning beyond the schema's descriptions. The baseline 3 is appropriate.
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 that the tool retrieves notes changed most recently, sorted newest first. It uses a specific verb-resource ('notes changed most recently') and distinguishes itself from siblings like 'brain_search' and 'brain_list' by focusing on recent changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to catch up on what humans or other agents have done since you last looked,' providing clear guidance on when to use the tool. It does not explicitly state when not to use it, but the context is strong enough for an agent to infer appropriate use.
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 discloses that the tool lists all notes with metadata and explains the authority field, but does not mention potential limitations like pagination, rate limits, or performance characteristics.
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?
Very concise: two sentences that front-load the essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose (list all notes), the description is fairly complete. It explains the key metadata and usage. Minor gaps are acceptable.
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 tool has no parameters (input schema is empty). Baseline for 0 parameters is 4, and the description does not need to add parameter information.
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 tool lists every note with specific metadata fields (path, title, folder, type, tags, status, authority), and highlights the authority field's significance. It distinguishes from siblings like brain_search and brain_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to discover what exists,' providing clear context for use. It does not explicitly mention when not to use it or compare to all siblings, but the context is sufficient for basic 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, the description effectively discloses the destructive 'overwrite' behavior and the need for confirmation via the overwrite and allow_conflict fields. It reveals the read-then-write pattern, adding context that the schema alone does not provide.
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?
Two sentences that front-load the purpose ('Overwrite a note') and efficiently cover the two usage modes and workflow. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers the essential behaviors: overwrite, read-first workflow, and conflict handling. It omits details on return values, but given no output schema, this is adequate.
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?
Schema coverage is 100%, but the description adds meaning by explaining that `content` is the full raw markdown from brain_read and that `body`+`frontmatter` follow the brain_write pattern. This clarifies the dual parameter modes beyond the schema descriptions.
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 'Overwrite a note' as the core purpose, with specific verb and resource. It distinguishes from siblings by noting it combines reading and writing, and references alternatives like brain_supersede for near-duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: read first with brain_read, then write the whole file back. It also contrasts with brain_supersede for conflict scenarios. However, it does not explicitly state when to use this tool over brain_write or brain_append beyond the overwrite context.
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 exist, so the description carries full burden. It explains that archived notes are demoted in search and excluded by default, adding useful behavioral context beyond the basic move 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences effectively cover purpose, usage scenario, and a procedural detail (leaving a pointer) with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description adequately covers usage context and behavioral effects. It references conventions and distinguishes from alternatives, though it omits error handling or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context about archive folders but does not significantly enhance parameter meaning beyond the schema.
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 'Move or rename a note' with a specific verb and resource, distinguishing it from sibling tools like brain_delete and brain_edit by emphasizing the archival use case.
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?
Explicitly describes when to use this tool (for retiring notes that are no longer true) and provides guidance on using archive folders and leaving pointers, effectively differentiating from deletion.
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 that deletion is recoverable via git history, that it destroys the reasoning trail, and contrasts with archiving's effect on search. It does not mention permissions or side effects on linked notes, but for a simple delete operation this is substantial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then concise guidance. Every clause earns its place, with no fluff or repetition.
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 tool is simple (one parameter, no output schema), and the description covers the purpose, recoverability, and decision framework for use verses archiving. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'path' parameter already described as 'vault-relative path'. The description does not add any additional parameter semantics, but there is no need to compensate given the schema's clarity.
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 opens with 'Delete a note', a specific verb and resource, and immediately distinguishes itself from brain_move by stating the preferred alternative. It clearly identifies the tool's core function.
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 provides explicit guidance: 'Prefer brain_move into an archive folder' and gives precise criteria: 'Delete when the note is wrong or duplicated, archive when it is merely no longer true.' This directly addresses when to use this tool vs alternatives.
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 takes full responsibility for behavior. It discloses the internal workflow (reads SCHEMA.md, searches, decides), safety guarantees (reads before overwriting, never deletes), and returns a manifest of touched paths. This is thorough and 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core action, the second details the process and safety, and the third gives usage guidance. No redundancy or fluff.
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?
Despite having only one parameter, no annotations, and no output schema, the description provides sufficient context: how it decides, what it returns, its safety behavior, and when to use it. The description compensates for all missing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a description ('the rough note / brain dump to file'). The description adds no new semantic details about the parameter beyond restating the same idea, so the baseline score of 3 is appropriate.
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 states a clear purpose: hand over a rough note and the tool files it, deciding between creating new, appending, or archiving. It distinguishes from siblings by explicitly comparing with brain_write, making the tool's unique role clear.
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?
Explicit guidance is provided: use when you have unstructured input and don't want to choose the path yourself, use brain_write when you do. This directly tells the agent when to choose this tool over an alternative.
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 fully discloses behavior: it returns schema, folders, status values, search ranking, and integrity warnings. It notes that vaults vary, adding context. It could mention that it is read-only and has no side effects, but the description is already informative.
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 concise with three sentences, front-loading the critical directive 'READ THIS FIRST.' Every sentence adds necessary context without redundancy.
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?
For a tool with no parameters and no output schema, the description is remarkably complete. It explains the tool's purpose, content, and the importance of reading it before other operations, covering all essential aspects.
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 input schema has zero parameters, so no parameter details are needed. The description adds value by explaining what the tool returns, achieving baseline 4 for no parameters.
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 it returns the vault's SCHEMA.md and a live description, acting as a meta-tool to be read first. It uses a specific verb ('READ') and resource ('schema'), distinguishing it from sibling tools that perform direct vault operations.
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?
Explicitly instructs 'READ THIS FIRST, before searching or writing,' providing clear timing of use. It explains what the tool returns and warns that vaults differ, implying the need to check conventions before other actions.
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 fully discloses ranking behavior (by relevance, not truth), authority levels, excluded list details, and the need to open authoritative notes for factual claims. It also explains the effect of parameters like includeArchive and includeInvalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and contains many sentences, though it is well-structured with sections. Some repetition could be trimmed (e.g., the authority explanation is given twice). It is informative but not concise.
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?
Given the tool's complexity and lack of output schema, the description fully covers return structure, ranking nuances, authority meanings, excluded list, parameter behavior, and factual verification guidance. It leaves no significant gaps.
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 input schema has 5 parameters with 100% description coverage. The description reinforces their usage (e.g., re-search with includeInvalid if needed), adding context beyond the schema. However, the schema descriptions are already detailed, so the description adds moderate incremental value.
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 it is a keyword search tool across the vault, returning hits and excluded items. It distinguishes from sibling tools like brain_read and brain_list by emphasizing search behavior and authority filtering.
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 provides explicit guidance on when to use the tool (for keyword search), how to interpret results (prefer authoritative notes), and when to use alternatives (re-search with includeInvalid/includeArchive). It also advises on handling stale notes and reporting defects.
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 provided, so description fully bears the burden. It discloses that writes with invalid frontmatter are rejected, and that writing a dated sibling for fact changes is rejected. It explains the reasoning behind rejections. Missing auth or rate limit info, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then provides detailed usage guidance. It is structured clearly with paragraphs for different aspects. Could be slightly shorter, but every sentence adds value.
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?
Given no output schema, description fully covers input semantics, constraints, rejection conditions, and sibling tool differentiation. No gaps remain for an AI agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant meaning beyond schema: explains tradeoffs between body+frontmatter vs content, warns about YAML parsing risks, and clarifies when overwrite and allow_conflict flags are needed.
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 'Create or overwrite a note' with specific verb and resource. It distinguishes from sibling tools like brain_supersede and brain_append by explaining when each is appropriate.
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 explicitly tells when to prefer body+frontmatter over raw content, when to use brain_supersede instead of writing a dated sibling, and how to use allow_conflict. It also references SCHEMA.md for naming conventions.
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 fully handles behavioral transparency. It discloses the authority field can indicate 'archived' or 'superseded' notes, advising caution. It also explains the behavior when a section heading is not found (returns list of available headings), which is critical for agent decision-making.
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?
Three well-crafted sentences with no redundancy. The most critical information (what the tool does, path format, section usage, authority warning) is front-loaded and immediately actionable.
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?
Despite no output schema, the description fully covers return values (markdown, authority, backlinks) and edge cases (missing section). Given the low parameter count (2) and 100% schema coverage, no additional information is needed for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: it clarifies path format with an example, explains that section matching is case-insensitive by prefix, and notes cost implications. This goes well beyond the schema's basic descriptions.
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 'Read a note' and specifies the exact content returned (full markdown, authority, backlinks). It distinguishes itself from siblings like brain_write and brain_edit by focusing on reading, and the section parameter usage is explicitly described, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to check the returned 'authority' before acting, and explains when to use the section parameter (for cheaper reads on long documents). While it doesn't explicitly contrast with all siblings (e.g., brain_search, brain_list), it provides strong contextual guidance for usage.
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 takes full responsibility for behavioral disclosure. It explains atomicity ('single commit'), preserves the old note ('body preserved'), and describes the post-operation effect ('search withholds the old note with the reason "superseded by <to>"'). It also notes the relationship between `from` and `to` and the conditional creation of `to`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long (about 120 words) but every sentence adds value. It front-loads the core action and then explains use cases and parameters. It is well-structured with distinct sections (purpose, parameters, alternatives). It is not as concise as the two-sentence TDQS example, but the added detail is justified for a multi-step atomic operation.
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?
There is no output schema, but the description covers the tool's side effects and behavior thoroughly. It explains what happens to the old note, how search behaves afterward, and how to handle the `to` note creation. Combined with the clear parameter semantics, it is complete for a tool of this complexity.
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 schema already covers all four parameters with 100% coverage, so baseline is 3. The description adds meaning beyond the schema by explaining how `from` and `to` relate, the purpose of `body` as an alternative way to create `to`, and that `reason` is recorded on the old note. This extra context justifies a 4 but not a 5 since the schema already gives basic descriptions.
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 tool's purpose: 'Retire a fact and replace it, atomically.' It uses a specific verb (supersede/retire) and identifies the resource (a fact/note). It explicitly distinguishes itself from a sibling tool: 'Prefer this over brain_move for a value that changed (move is for relocation).'
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?
Provides explicit when-to-use guidance: 'When a fact changes (a price, a term, a decision), DON'T just add a new note...' It also names an alternative (brain_move) and explains why to use this instead. It gives a clear workflow for both cases (to exists or not).
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:

[![engram MCP server](https://glama.ai/mcp/servers/rwnalds/engram/badges/card.svg)](https://glama.ai/mcp/servers/rwnalds/engram)

Score Badge

Copy to your README.md:

[![engram MCP server](https://glama.ai/mcp/servers/rwnalds/engram/badges/score.svg)](https://glama.ai/mcp/servers/rwnalds/engram)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/rwnalds/engram'

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