Nexus Memory MCP

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Each tool has a distinct purpose, but recall, context, and awaken all involve retrieving information from memory, which could be confused. Descriptions help clarify that recall is semantic search, context is a session summary, and awaken restores identity.
Naming Consistency2/5
Names mix single verbs (remember, recall, connect, forget, awaken, hibernate), nouns (stats, context), and verb_noun compounds (wear_hat, list_hats) with no consistent pattern. A uniform verb_noun convention would be more predictable.
Tool Count5/5
10 tools is well within the ideal range for a memory server covering storage, retrieval, relationships, session persistence, and domain packs. Each tool earns its place for the server's purpose.
Completeness4/5
The tool set covers core memory lifecycle (create, read, delete), relationships, stats, session context, and identity persistence. Missing an explicit update operation and a list-all-memories tool, but agents can work around these gaps.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.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 are present, so the description carries full burden. It implies destructiveness via 'Remove' and 'Use sparingly,' but doesn't disclose irreversibility, cascade side effects, or permissions. This is inadequate for a destructive tool.
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 short sentences with no waste. 'Remove a memory' is front-loaded, and 'Use sparingly' contributes a warning. It is appropriately concise.
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 moderate complexity with a destructive action, no output schema, and no annotations. The description only states the basic removal and a vague warning, omitting essential details like cascade behavior, reversibility, or return values. This is under-specified.
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 descriptions cover both parameters (memory_id and cascade) at 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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 says 'Remove a memory' – a specific verb and resource. It clearly distinguishes from sibling tools like remember (add) and recall (retrieve).
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?
The only usage guidance is 'Use sparingly,' which is a vague caution rather than an explanation of when to use this tool or when to prefer alternatives. No prerequisites or exclusions are mentioned.
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, the description carries the burden of behavioral disclosure, but it only says 'create a relationship.' It does not mention whether the tool validates memory IDs, how it handles existing relationships, whether relationships are directional, or any side effects. The lack of detail leaves significant behavioral questions unanswered.
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 two sentences, front-loaded with the core action, followed by a brief illustrative example. Every sentence earns its place without fluff, and it is appropriately sized for the tool's simplicity.
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?
The description covers the basic purpose and example usage, and the schema fully documents parameters. However, the tool has no annotations or output schema, and the description omits important behavioral details like return values, error conditions, and the directional nature of relationships. It is adequate but leaves several gaps for an agent to infer.
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 baseline is 3. The description adds context for using the relationship concept ('linking decisions to rationale') but does not provide additional semantics for individual parameters beyond what the schema already specifies. It does not explain when to use different relationship types or how notes are formatted.
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 a relationship between two memories,' which is a specific verb and resource. It distinguishes itself from siblings by focusing on linking existing memories rather than adding, recalling, or managing them, and provides concrete examples to illustrate its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('Build knowledge graphs by linking decisions to rationale, patterns to examples, etc.'), giving context for the type of relationships to create. It does not explicitly mention when not to use it, but the examples and sibling set make the intended use clear.
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 does disclose the tool's function ('Get a session context summary') and its content ('preferences, decisions, patterns'), but it doesn't explicitly state whether it's read-only, has side effects, or what the return format looks like. The word 'load' could imply state changes, which is ambiguous. This is acceptable but not fully 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every word contributes value. It efficiently states what the tool does and when to use it without redundancy.
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 low complexity (2 optional params, no output schema), the description sufficiently covers the 'what', 'when', and 'content of the summary'. It could be slightly more explicit about the return value's structure, but it names the key contents, making it mostly complete for a simple 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 description coverage is 100% and both parameters have descriptions in the input schema. The tool description adds no extra parameter information, but the baseline of 3 applies when the schema already adequately explains all parameters.
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 uses a specific verb ('Get') and resource ('session context summary'), clearly stating what the tool does. It doesn't explicitly distinguish from sibling tools like 'remember' or 'recall', but the scope ('preferences, decisions, patterns') is specific enough. This is clear but lacks explicit sibling differentiation.
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 'Call at the START of conversations to load preferences, decisions, patterns.' This gives clear contextual guidance on when to use the tool. However, it doesn't mention when not to use it or alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the core behavior (persisting data) but does not mention return values, overwrite behavior, deduplication, or any side effects, leaving the agent without important behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the action front-loaded ('Store a memory.') followed by a useful elaboration on what kinds of memories to store. No filler or redundant information.
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 simple store operation, the description plus fully described schema provides enough information for an agent to invoke it. It lacks an explicit note about the return value or storage behavior, but the tool's simplicity keeps the gap small.
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 input schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds general examples of content but does not augment the schema's per-parameter semantics.
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 uses the specific verb 'Store' with the resource 'memory', and lists example content types (decisions, preferences, architecture, patterns). This clearly distinguishes it from sibling tools like recall (retrieve) and forget (delete), making the 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 explicitly states when to use it: to persist anything that should survive across sessions. It does not explicitly name alternatives or exclusions, so it meets the 'clear context, no exclusions' bar.
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 the full burden. It discloses that activating a pack imports expert knowledge and that existing memories layer on top, which implies non-destructiveness. However, it omits details about persistence, reversibility, or any side effects on existing memory, leaving gaps for a state-changing tool.
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 two sentences with no redundancy. The first sentence is an immediate, clear action statement, and the second adds essential behavioral context. Every word earns its place.
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 simple single-parameter schema and no output schema, the description sufficiently explains what happens on invocation (imports knowledge, layers memories). It could be improved by referencing how to discover hat_id (e.g., via 'list_hats'), but the core functionality is clear for a basic interaction.
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 already fully describes the only parameter (hat_id) with 100% coverage. The description adds the phrase 'Intelligence Pack' which aligns with the schema but provides no additional semantics about where to find the ID or formatting rules, so the baseline score 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 with a specific verb ('Activate') and resource ('Intelligence Pack'). It is distinct from sibling tools like 'list_hats' (listing) and 'remember'/'recall' (memory operations), making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to import expert knowledge, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The sibling tool names suggest some context, but the description itself lacks direct 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 carries the burden of behavioral disclosure. It explains that matching is semantic rather than keyword-based, which is a key behavioral trait. However, it does not explicitly state whether the operation is read-only, what happens with empty results, or any side effects. The verb 'search' implies non-mutating, but more detail would be safer.
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 composed of three short, information-dense sentences. The main verb and resource are front-loaded, and each sentence adds value: the semantic nature, the distinction from keyword search, and a usage recommendation. There is no clutter or repetition.
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 straightforward retrieval tool, the description covers the purpose, a key behavioral nuance, and a specific usage scenario. Since there is no output schema, it might be helpful to mention the return format or ranking, but the tool's purpose implies the results are memories. This is largely complete given the tool's simplicity.
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 input schema already provides descriptions for all three parameters, so the schema coverage is 100%. The description does not add any additional parameter-specific meaning; it only implies the query should be natural language, which the schema already states. Thus the 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 specifies a search action over memories, and the phrase 'by MEANING, not keywords' distinguishes it from a simple keyword lookup. The sibling tools (remember, forget) confirm this is the retrieval counterpart, so the purpose is 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 gives a concrete use case: 'Use at the start of sessions to restore context.' This tells the agent when to invoke the tool, but it does not explicitly state when not to use it or mention alternative tools. Still, the recommendation is actionable and clear.
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 clearly indicates a read-only operation ('Get') and lists the specific stats, but does not disclose any additional behavioral traits such as return format, performance characteristics, or side effects. Given the simple nature of the tool, this is adequate but not exceptional.
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. It starts with the verb 'Get' and immediately conveys the core purpose. Every word adds value, listing specific statistics without any filler or redundancy.
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, no-annotation, no-output-schema tool, the description is sufficiently complete. It clearly states what the tool returns (the key statistics), which is the essential information an agent needs. It could mention return format, but for a simple stats snapshot, the listed items are 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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description adequately describes what the output includes, which is more relevant than 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 uses a specific verb ('Get') and resource ('memory statistics'), and enumerates the specific statistics (total memories, relationships, vectors, patterns learned). This clearly distinguishes it from sibling tools like remember, recall, and connect, which perform different actions.
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 use case—checking overall memory health or statistics—but does not explicitly state when to prefer this over alternatives. There is no mention of exclusions or when not to use it, though the purpose is clear enough for an agent to infer.
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 what the tool does (restores identity, work-in-progress, and learned information) but does not mention potential side effects, safety characteristics, failure modes, or behavior when no previous session exists. This is adequate but lacks depth.
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 concise sentences, front-loaded with the core purpose and immediately followed by the usage directive. Every word contributes value; no filler or redundant phrasing.
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, no-output-schema tool, the description is nearly complete. It explains the purpose, the timing, and what is restored. It could mention prerequisites or edge cases, but given the simplicity, it covers the essential context well.
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 zero parameters, so the baseline is 4. The description adds no parameter semantics since none are needed, and the schema confirms an empty object. No further explanation required.
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 with a specific verb 'restore' and resource 'agent identity from previous sessions'. It distinguishes itself from sibling tools like remember/recall by focusing on session-level restoration rather than specific memory operations, and it explicitly says when to call it (at the START of every session).
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 an explicit usage context: 'Call at the START of every session'. This gives clear when-to-use guidance. However, it does not mention alternatives or when not to use it, so it stops short of full exclusionary 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 carry the full burden. It discloses the core behavior (saving state for future restoration) and what data is preserved. However, it does not explain whether calling it overwrites existing saved state, whether it can be called multiple times, or any side effects like ending the session. This is not misleading, but a bit minimal for a state-saving tool.
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 (~25 words) that front-loads the action, states the trigger ('end of every session'), and lists the key content. Every clause earns its place; there is no fluff or redundancy.
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 simple 3-parameter tool with no output schema and no annotations, the description covers when (end of session), what (session state with three components), and why (preserve for next awakening). It doesn't explain the restore mechanism or potential overwrite behavior, but those are arguably covered by sibling tools and schema. Overall, it is fairly 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly mentioning 'what you were working on, what you learned, and next steps,' directly corresponding to the three parameters (working_on, learnings, next_steps). This reinforces the schema and helps the agent know exactly what to populate.
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 ('Save current session state') and the resource ('session state') with a specific purpose ('for next awakening'). This distinguishes it from siblings like 'awaken' (which likely restores state) and 'remember' (which may store general memories), making the tool's role 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?
Provides explicit timing: 'Call at the END of every session.' This is strong usage guidance. It does not explicitly mention alternatives or exclusions (e.g., when not to use it), but the end-of-session instruction creates clear context, and the mapping to preservation of work, learnings, and next steps implies appropriate use cases.
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. 'Browse' implies a read-only operation, but it does not detail what the response contains, whether any side effects exist, or any authentication requirements. It covers the basic safety profile but lacks richer 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main action front-loaded in the first sentence. The second sentence adds value by explaining the purpose of the hats. No redundant or 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 low complexity (zero parameters, no output schema), the description provides sufficient context for an agent to know when to call the tool and what it accomplishes. It indirectly indicates that a list of hats will be returned via 'Browse available'. It could explicitly state the output format, but for a simple list tool, 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?
The tool has zero parameters, and the input schema is empty (100% coverage). Per rubric, a baseline of 4 applies when there are no parameters, and the description does not need to explain parameter semantics. It appropriately focuses on the action and resource.
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 verb 'Browse' and a specific resource: 'Intelligence Packs (Specialist Hats)'. It also explains their purpose ('domain expertise you can activate'), which distinguishes it from the sibling tool 'wear_hat' that likely activates hats. The purpose is specific and 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 implies the tool is for discovering available hats before activating them, referencing activation directly. It does not explicitly name alternatives or exclusions, but the context of 'available' and 'you can activate' conveys a clear usage scenario alongside sibling 'wear_hat'.
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:

[![nexus-memory-mcp MCP server](https://glama.ai/mcp/servers/KairosMobius/nexus-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/KairosMobius/nexus-memory-mcp)

Score Badge

Copy to your README.md:

[![nexus-memory-mcp MCP server](https://glama.ai/mcp/servers/KairosMobius/nexus-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/KairosMobius/nexus-memory-mcp)

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/KairosMobius/nexus-memory-mcp'

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