Astria-Index
Server Quality Checklist
- Disambiguation4/5
Tools are mostly distinct with clear boundaries between semantic memory (remember/recall/forget), exact-access notes (save_note/get_note), structured insights (record_insight/my_insights), and session lifecycle (start/resume/end/promote_session). Minor potential confusion between promote_session and remember (both persist information), but descriptions clarify the session-specific context for promotion.
Naming Consistency3/5Mixed conventions exist: verb_noun pattern (save_note, start_session), bare verbs (remember, recall, forget), possessive prefix (my_sessions, my_insights, my_memory_stats), and gerund phrase (getting_started). While subsystems are internally consistent (my_* for introspection, *_session for sessions), the server lacks a unified naming pattern across all 15 tools.
Tool Count5/515 tools is well-scoped for a comprehensive memory and session management system. The count covers semantic memory CRUD, named note storage, insight tracking, full session lifecycle, and utility functions without bloat. Each tool earns its place in the knowledge management workflow.
Completeness4/5Covers the full lifecycle for sessions and semantic memories adequately. Minor gaps exist: no explicit delete for notes or insights (only overwrite), and no update operation for existing memories (requires forget+remember sequence). However, agents can work around these gaps, and core persistent memory workflows are fully supported.
Average 4.8/5 across 15 of 15 tools scored.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.1.4
Tools from this server were used 15 times in the last 30 days.
This repository includes a glama.json configuration file.
- This server provides 15 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Add related servers to improve discoverability.
Tool Scores
- 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 of behavioral disclosure. It effectively documents the return structure (counts by category, sessions, notes, insights, embeddings) and provides crucial edge-case information that all counts are zero for fresh instances, though it omits explicit mention of the read-only nature.
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 employs clear structural sections ('Use this when:', 'Returns:') and front-loads the core purpose. Every sentence provides distinct value, from the overview definition to usage scenarios to return value specifications and edge-case behavior.
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 (zero parameters) and existence of an output schema, the description provides comprehensive coverage by detailing the return object structure and the fresh-instance edge case. The coverage is sufficient for an agent to understand both invocation and expected results.
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 input schema contains zero parameters, establishing a baseline score of 4. The description reinforces this by including an example invocation `my_memory_stats()` with empty parentheses, confirming no arguments are required.
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 'See a dashboard overview of your entire memory network,' providing a specific verb and resource. It clearly positions the tool as an aggregate statistics function, distinguishing it from siblings like `get_note`, `my_insights`, and `list_memories` which handle specific retrieval rather than overview metrics.
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 includes an explicit 'Use this when:' section listing three specific scenarios (starting conversations, checking growth, reporting utilization). While it provides excellent contextual guidance for appropriate usage, it does not explicitly name alternative tools or provide negative constraints (when not to use).
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 carries full burden. Discloses case-sensitive matching, exact name requirements, error conditions ('Returns an error if no note exists'), and session attachment logic. Would be perfect with explicit statement about read-only nature or side effects, though 'Retrieve' and 'Fetches' imply this.
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?
Front-loaded with clear one-line summary. Uses structured Args/Returns sections which adds slight verbosity but maintains clarity. Every sentence provides value—examples are concrete, constraints are explicit, and no filler text present. Efficient for the amount of information conveyed.
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?
For a 2-parameter tool with flat schema and existing output schema, description is exceptionally complete. Covers success behavior, error states, sibling relationships, session management, and parameter semantics. Exceeds requirements by documenting return values even though output schema exists.
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 has 0% description coverage. Description compensates via Args section explaining 'name' (case-sensitive, exact match) and 'session_id' (conditional requirement based on save context). Deducting one point only because it uses structured docstring format rather than integrated prose, but semantics are fully covered.
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?
Opens with specific verb ('Retrieve') + resource ('saved note') + constraint ('exact name'). Explicitly distinguishes from sibling `save_note` ('previously created with') and contrasts with `recall` ('search by content') and `resume_session` ('check session context'), making selection unambiguous.
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 'Use this when:' section with three concrete code examples. Directly addresses uncertainty scenarios ('If you're not sure of the note name') and routes to correct alternative (`recall`). Also specifies prerequisite conditions (session_id requirements) for successful invocation.
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 disclosure burden. It successfully documents the 48-hour auto-expiration of completed sessions, the empty-list behavior when no sessions exist, and the specific fields returned (IDs, descriptions, status, timestamps). Minor gap: does not mention ordering (e.g., by recency) or potential rate limits.
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?
Well-structured with clear sections for purpose, usage scenarios (bullet points), and return values. The 'Use this when' section is slightly verbose with three bullet points, but each provides distinct context (timing, status-checking, decision-making). Front-loaded with the core action statement.
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?
Despite the existence of an output schema (not shown), the description provides valuable semantic context about the returned data structure and session lifecycle. Combined with comprehensive usage guidelines and zero parameters requiring documentation, the description is complete for this tool's complexity level.
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?
Input schema contains zero parameters. Per scoring rules, 0 params warrants a baseline score of 4. The description correctly implies the parameterless invocation pattern with `my_sessions()` in the usage example, adding no confusion.
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 the specific verb 'List' and resource 'active sessions', explicitly stating the scope (sessions 'you can resume'). It clearly distinguishes from siblings by referencing `resume_session` as the follow-up action and implying contrast with `start_session` for new work.
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 temporal guidance ('at the start of every new conversation', 'first thing to call') and decision-making criteria ('Deciding whether to start a new session or resume'). It explicitly names the sibling alternative (`resume_session`) for the continuation workflow, leaving no ambiguity about tool selection.
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 carries full burden. It discloses that the tool returns 'formatted text' and details the guide contents (workflows, conventions, best practices). However, it doesn't explicitly state idempotency or safety characteristics, though these are implied by the 'Get' verb and zero-parameter 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?
Well-structured with clear sections: purpose declaration, content details, usage conditions, and return value specification. No redundant text; every sentence provides distinct value regarding functionality or usage context.
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?
For a zero-parameter documentation tool, the description is complete. It covers purpose, usage triggers, and output format. The presence of output schema information in the description ('Returns:...') satisfies completeness requirements without needing external schema documentation.
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?
Input schema contains zero parameters, establishing baseline 4. Description correctly implies no configuration is needed to retrieve the complete guide, consistent with the empty 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?
Description opens with specific verb 'Get' and clear resource 'Astria operating guide'. It inherently distinguishes from operational siblings (remember/recall/etc.) by describing a documentation retrieval function that 'covers all available tools' rather than manipulating memory data.
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?
Contains explicit 'Use this when:' section with three specific scenarios: connecting for the first time, needing a refresher, and onboarding new AI platforms. This provides clear guidance on when to invoke this meta-tool versus operational memory 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?
No annotations provided, so description carries full burden. Discloses ranking algorithm (frequency-based), reliability interpretation, and empty state behavior ('Returns an empty list if no insights recorded yet'). Minor gap: doesn't explicitly declare read-only/safety characteristics, though implied by 'browse'.
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?
Well-structured with clear sections (opening statement, ranking logic, usage bullets, Args, Returns). Content is dense and relevant. Slightly verbose with four usage examples when two might suffice, but each adds distinct context (debugging vs onboarding).
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?
For a simple 1-parameter tool, description is complete. Documents return structure (pattern, cause, solution, confidence, count) despite lack of structured output schema. Behavioral expectations (ranking, empty state) are covered.
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 coverage is 0% (limit parameter has no description field). Description fully compensates by defining limit as 'Maximum insights to return', confirming default (20), and crucially specifying max constraint (50) absent from 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?
Opens with specific verb 'Browse' and clear resource 'discovered cause-and-effect patterns'. Distinct from sibling 'record_insight' (implied write counterpart) and 'list_memories' (raw vs processed insights) by specifying these are ranked, reliability-indicating patterns.
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?
Explicit 'Use this when:' section lists four specific scenarios including debugging prep, similarity checking, knowledge base building, and onboarding. Includes concrete example invocation `my_insights(limit=10)` demonstrating intended usage pattern.
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 carries full burden. Discloses ranking behavior (similarity score), return structure (IDs, content, category, etc.), empty result handling, and error conditions (server unreachable). Minor gap: doesn't explicitly confirm read-only nature, though implied by 'search'.
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?
Well-structured with clear sections (tagline, mechanism, usage cases, args, returns). Front-loaded with key differentiator ('meaning, not keywords'). Information-dense though slightly verbose; the four example use cases could potentially be condensed without loss.
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?
Comprehensive coverage for a semantic search tool. Despite presence of output schema (per context signals), description helpfully previews return structure. Explains parameter validation (max 20), category constraints, and result ranking. No significant gaps for this complexity level.
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?
With 0% schema coverage, description fully compensates via detailed Args section. Query explains natural language input and length guidance. Limit specifies bounds (default 5, max 20) and usage context. Category enumerates all valid enum values (preference, fact, decision, idea, project, person, general) and filter 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?
Opens with specific verb+resource ('Search your memories') and immediately distinguishes the mechanism ('by meaning, not keywords'). Clearly differentiates from siblings like list_memories (which would scan) or remember (which creates) by emphasizing semantic similarity search.
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?
Explicit 'Use this when:' section with four concrete scenarios including example query strings. Covers distinct use cases (decision lookup, topic check, fact finding, conversation startup) that clearly guide selection over alternatives like get_note or list_memories.
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 what gets retrieved ('description, progress, related memories, notes, and any sub-tasks') and error conditions ('Returns an error if the session_id doesn't exist or has already been completed'). Could clarify if this updates session status/timestamps, but error disclosure adds significant value.
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?
Appropriately structured with clear visual sections (description, use cases, args, returns) that front-load critical information. No redundant sentences, though the multi-section format makes it longer than minimalist definitions. Given the 0% schema coverage and need for usage guidance, the length is justified.
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?
Comprehensive for a single-parameter tool: covers prerequisites, three distinct usage scenarios, parameter provenance, error states, and return value summary. Since an output schema exists, the description appropriately summarizes rather than duplicates the full return structure.
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?
Despite 0% schema description coverage, the Args section fully compensates by providing the parameter's semantic source ('from `start_session` or `my_sessions` results'), format example ('e.g., "s001"'), and clear identifier semantics. This prevents agents from inventing session IDs.
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 combination ('Resume a previous session') and clarifies the outcome ('get full context to continue working'). It distinguishes from sibling 'start_session' by emphasizing retrieval of existing state versus creating new work, and from 'my_sessions' by focusing on single-session deep retrieval versus listing.
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 'Use this when' bullet points covering cold-start scenarios, break resumption, and progress checking. Critically, it mandates the prerequisite workflow: 'Always call `my_sessions` first to find the correct session_id,' preventing agents from guessing IDs. Also distinguishes when to use versus starting fresh.
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, description carries full burden and discloses: ordering behavior (chronological), filtering logic (category tag matching), pagination constraints (default 20, max 100), and empty state handling. Lacks explicit safety declaration (read-only) but implies it via 'Browse' and return value documentation.
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?
Well-structured with clear sections (purpose, differentiation, usage guidelines, Args, Returns). Every sentence earns its place; examples are specific and front-loaded with the primary action. No redundant or filler text.
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?
Despite having an output schema (per context signals), description proactively documents return structure (IDs, content, category, importance, timestamps) and empty list behavior. For a 2-parameter list operation with no annotations, coverage is comprehensive.
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 has 0% description coverage (no parameter descriptions in JSON), but the tool description fully compensates by documenting both parameters in the Args section, including the enum values for category (preference, fact, decision, etc.) and limit constraints (max 100).
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?
Opens with specific verb ('Browse') + resource ('stored memories') + ordering constraint ('most recent first'). Explicitly differentiates from sibling tool `recall` by contrasting chronological vs. semantic search, clearly delineating scope.
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 'Use this when:' section with four concrete scenarios including parameter examples. Explicitly names alternative tool (`recall`) and explains when to use each, satisfying the 'when/when-not' requirement.
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 successfully discloses key behaviors: idempotent recording (confidence increments on duplicates), automatic surfacing of patterns, and return value structure (insight ID and observation count). It could further improve by mentioning persistence scope or deletion capabilities (given the 'forget' sibling exists).
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 well-structured with clear sections (concept, usage guidelines, arguments, returns). Every sentence adds value—conceptual framing establishes purpose, examples clarify boundaries, and argument descriptions enable correct invocation. No redundancy or filler text despite the length.
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 (semantic triple storage with deduplication logic) and the presence of an output schema, the description is complete. It explains the return values meaningfully and differentiates the tool's role within the broader memory ecosystem of siblings without needing to duplicate schema specifications.
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%, requiring the description to fully compensate. The Args section provides rich semantic meaning for all four parameters, including the confidence scale's interpretation (0.5 for hypotheses, 0.7 for likely, 1.0 for confirmed) which is critical for correct usage and not inferable from the schema types alone.
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 opening sentence 'Record a cause-and-effect pattern you've discovered' uses a specific verb and resource. It clearly distinguishes from sibling tools like 'remember' or 'save_note' by framing insights as 'the deepest memory tier — understanding WHY things happen,' establishing a clear conceptual hierarchy.
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 'Use this when:' section provides three concrete, contextualized examples (recurring bugs, workflow patterns, root cause investigation) that explicitly bound when to invoke this tool versus simpler memory storage. The examples include realistic parameter values, making the activation conditions unambiguous.
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, disclosing overwrite semantics, session attachment behavior, supported markdown formatting, and error conditions (empty name/content). Could be improved by explicitly stating idempotency or persistence guarantees, but covers primary behavioral traits well.
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?
Perfectly structured with progressive disclosure: summary → conceptual model → usage scenarios → constraints → detailed parameter specs → returns. Every sentence provides unique value; examples are concrete and immediately illustrative without verbosity.
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 0% schema coverage and medium complexity (distinction from memory system), the description is comprehensive: covers purpose, sibling differentiation, parameter documentation (compensating for schema), return value summary (sufficient since output schema exists), and error cases. No significant gaps remain.
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?
Critical compensation for 0% schema description coverage: the Args section provides rich semantics for all three parameters including naming conventions (lowercase-hyphens), format support (markdown), size guidance, and functional behavior (session attachment). Effectively documents what the schema omits entirely.
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 specific verb+resource ('Save a named note') and immediately distinguishes from siblings by contrasting notes (exact name access) with memories (semantic search), explicitly naming `get_note` as the retrieval counterpart.
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?
Contains an explicit 'Use this when:' section with four concrete scenarios including code examples, clarifies the overwrite behavior ('If a note with the same name already exists, it is overwritten'), and contrasts with memory-based tools (remember/recall) in the sibling set.
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 provided, so description carries full burden. Discloses 48-hour retention policy, auto-expiry behavior, error conditions (session doesn't exist/already ended), and persistence guarantees for promoted memories vs session data.
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?
Appropriately structured with front-loaded purpose, followed by behavioral notes, usage guidelines, and technical specs. Length is justified by zero schema documentation and lack of annotations, though multi-paragraph format is denser than minimal examples.
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?
Despite 0% schema coverage and no annotations, description achieves full coverage: parameter semantics, return value behavior, error states, lifecycle policy (48hr expiry), and sibling interactions. Output schema exists but description still clarifies return value meaning.
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 has 0% description coverage. Description fully compensates with rich semantics: session_id includes format example ('s001'), summary explains optional nature and content guidance ('what was accomplished and any follow-up items').
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?
Opens with specific verb+resource ('End a session and record what was accomplished') and distinguishes from sibling `promote_session` by clarifying that ending marks completion while promotion saves permanent memories.
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?
Explicit 'Use this when:' section with three concrete scenarios (finishing, abandoning, wrapping up) including code examples. Explicitly recommends calling `promote_session` first as an alternative path, creating clear decision boundaries.
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 full burden: discloses 48-hour session expiration, permanent persistence of promoted items, requires active (not completed) session, and specifies error conditions (empty takeaways, non-existent session).
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?
Well-structured with clear Args/Returns sections and front-loaded purpose. Length is justified by zero schema coverage, though slightly verbose relative to the minimal structured data available.
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?
Comprehensive for a 2-parameter tool: explains return value semantics (count promoted), error states, sibling relationships, and the critical business logic of temporary vs permanent storage despite output schema being present.
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?
Despite 0% schema description coverage, the Args section fully compensates: session_id includes format example ('s001') and state constraint ('active'), while key_takeaways explains content requirements ('Be specific and include context').
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 ('Save the most important things from a session as permanent memories') and clearly distinguishes from siblings by explaining the 48-hour expiration constraint and the relationship to end_session.
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 this when:' followed by three concrete scenarios, including the specific temporal constraint 'Before calling `end_session`' and a complete code example showing exact parameter 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?
With no annotations provided, the description carries full burden and excels: it discloses irreversibility ('the memory and its embeddings are deleted'), error conditions ('Returns an error if the memory_id doesn't exist'), and return values ('Confirmation that the memory was deleted'). This provides critical safety context for a destructive 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?
Despite length, every sentence serves a critical purpose for a destructive tool: irreversibility warning is front-loaded, prerequisite steps are explicit, usage scenarios are bulleted for scanability, and Args/Returns sections compensate for schema gaps. No redundancy exists; structure enhances clarity.
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 high complexity (irreversible deletion, prerequisite lookups needed) and 0% schema coverage, the description is remarkably complete. It covers the action, safety implications, prerequisite workflow, usage scenarios, anti-patterns, parameter semantics, and return behavior—sufficient for safe autonomous operation.
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% (memory_id lacks description field), but the description fully compensates: it explains the parameter represents 'The unique memory identifier', provides format example ('mem_abc123'), and specifies provenance ('obtained from `remember`, `recall`, or `list_memories` results'), giving the agent complete semantic context.
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 ('Remove') + resource ('memory') + scope ('permanently from your knowledge graph'). It clearly distinguishes from siblings by contrasting with `remember` (for creating/updating) and `recall`/`list_memories` (for retrieving), establishing its unique place in the CRUD lifecycle.
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 prerequisites ('Use `recall` or `list_memories` first'), three specific 'Use this when' scenarios with examples, and a clear anti-pattern ('Do NOT use this to "update" a memory') with the correct alternative workflow. This covers when-to-use, when-not-to-use, and alternatives comprehensively.
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 full behavioral disclosure: it explains persistence ('persists forever'), retrieval mechanics ('searching for its meaning — not just exact words'), storage architecture ('knowledge graph with semantic embeddings'), auto-categorization behavior ('If omitted, auto-categorized'), and error conditions ('Returns an error message if the content is empty').
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 uses a standard docstring structure (summary, technical context, usage examples, Args, Returns) with zero redundant sentences. Technical details about semantic embeddings are essential for correct usage, and the examples are concise yet concrete. Front-loaded with the core action in the first sentence.
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 complexity of the memory system and complete lack of schema descriptions, the description is comprehensive: it covers input parameters with examples, explains the output ('Confirmation with the assigned memory ID'), documents error states, and establishes the relationship with sibling tool `recall`. No gaps remain for an agent to use this tool effectively.
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?
Despite 0% schema description coverage, the Args section fully compensates by documenting all three parameters: `content` (semantics and best practices), `category` (explicit enum values: preference, fact, decision, idea, project, person, general), and `importance` (enum values and ranking behavior). The description adds critical constraints not present in the 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?
The description opens with a specific verb ('Save') and resource ('long-term memory'), then distinguishes from sibling tool `recall` by stating saved items 'can be found later with `recall`'. It further clarifies the unique semantic storage mechanism ('knowledge graph with semantic embeddings') that differentiates this from simple note-taking tools like `save_note`.
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?
Contains an explicit 'Use this when:' section with four concrete scenarios (facts, decisions, preferences, ideas), each including realistic code examples. This provides clear guidance on when to select this tool over siblings like `save_note` (for general notes) or `record_insight` (for analytics).
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. It comprehensively discloses behavioral traits: persistence ('days or weeks later'), tracking scope ('goal, progress, and related memories'), storage semantics ('stored verbatim'), return format ('session ID e.g., s001'), error conditions ('Returns an error if description is empty'), and side effects (creates resumable state usable by named siblings).
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?
Despite being multi-paragraph, every section earns its place. Information is front-loaded with the core purpose, followed by usage heuristics, constraints, and technical details. The structure uses clear headers ('Use this when:', 'Args:', 'Returns:') that improve scannability. No tautology or repetition of the tool name.
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 single parameter and simple schema, the description is exceptionally complete. It covers invocation triggers, prerequisites (checking `my_sessions`), parameter semantics, return value format, error states, and sibling tool relationships. Even though an output schema exists, the additional return value description provides necessary context about ID format and error handling.
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% (only type: string provided), requiring the description to compensate fully. The 'Args:' section adds essential semantics: the purpose ('What you're working on'), persistence behavior ('stored verbatim'), consumption context ('used to restore context when resuming'), and quality guidelines ('Be specific enough that you'll understand the goal when you come back later'). Without this, the agent would lack critical usage context.
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 ('Start') and resource ('working session') and clearly defines the unique value proposition ('cross-conversation continuity'). It effectively distinguishes from siblings like `resume_session` (continuing existing) and `end_session` (terminating) by emphasizing the creation of new persistent state.
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 positive conditions ('Use this when:') with concrete examples including exact syntax, negative conditions ('Do NOT start a session for quick, single-conversation tasks'), and explicit alternative workflow ('Call `my_sessions` first to check for existing sessions to resume'). This leaves no ambiguity about tool selection.
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:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
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.
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PL-ODIN/astria-plugin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server