Your AI never starts from zero again. Astria is a persistent memory layer that works across sessions, tools, and time.
Every insight compounds. Every session builds on the last. Switch between Claude Code, Cursor, Windsurf, or any MCP-compatible client — your memory follows you.
/plugin marketplace add PL-ODIN/astria-plugin
/plugin install astria@astria-marketplace
/astria-setupThat's it. Three commands.
Related MCP server: cogmemai-mcp
Command | What it does |
| Save a fact, decision, preference, or idea to permanent memory |
| Search your memory using natural language |
| Start, resume, or end working sessions for cross-conversation continuity |
| View your memory statistics — how much your AI knows |
Astria runs as an MCP server connected to your own dedicated memory infrastructure. When you save a memory, it's stored in a knowledge graph with semantic embeddings. When you recall, Astria searches by meaning — not just keywords.
Sessions give you continuity across conversations. Start a session today, close Claude Code, come back next week — pick up exactly where you left off.
Facts — things that are true ("our API uses OAuth2")
Decisions — choices you've made ("we chose Postgres over Mongo")
Preferences — how you like to work ("I prefer concise responses")
Ideas — things to explore later ("consider adding WebSocket support")
Projects — ongoing work context ("migrating from v1 to v2 API")
Insights — learned patterns ("when X happens, the cause is usually Y")
While the plugin is optimized for Claude Code, Astria works with any tool that supports MCP over SSE:
Claude Code — Plugin install (recommended)
Claude Desktop — Add MCP server in settings
Cursor — MCP server config
Windsurf — MCP server config
See manual setup instructions after signing up.
$50/month — unlimited memories, unlimited sessions, unlimited recall. One price. No tiers. No metering.
Each subscriber gets their own dedicated, physically isolated memory infrastructure. Your data is never shared or mixed with other users.
Sign up at astriaindex.com
Install the plugin (see above)
Run /astria-setup and paste your endpoint + API key
Start remembering
End a session and record what was accomplished.
Marks the session as completed and optionally saves a summary.
Consider calling promote_session first to save key learnings
as permanent memories before ending.
Use this when:
Work is finished: end_session("s001", summary="Auth migration complete, all tests passing")
Abandoning a session: end_session("s001", summary="Deprioritized — will revisit Q3")
Wrapping up for the day with a status update
The session data is retained for 48 hours after completion, then auto-expires. Promoted memories persist forever.
Args: session_id: The session to complete (e.g., "s001"). summary: Optional final summary of the outcome. If omitted, the session closes without a summary. Include what was accomplished and any follow-up items.
Returns: The final session state with status "completed". Returns an error if the session doesn't exist or was already ended.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| summary | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Remove a specific memory permanently from your knowledge graph.
This action is irreversible — the memory and its embeddings are deleted.
Use recall or list_memories first to find the correct memory_id.
Use this when:
A fact is no longer true: forget("mem_abc123")
A decision was reversed and the old one is misleading
Removing duplicate or incorrect memories
Do NOT use this to "update" a memory — instead, forget the old one
and remember the corrected version.
Args:
memory_id: The unique memory identifier (e.g., "mem_abc123") obtained
from remember, recall, or list_memories results.
Returns: Confirmation that the memory was deleted. Returns an error if the memory_id doesn't exist or has already been deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Retrieve a saved note by its exact name.
Fetches the full content of a note previously created with save_note.
The name must match exactly (case-sensitive).
Use this when:
Retrieving stored data: get_note("api-endpoints")
Checking session-attached notes: get_note("findings", session_id="s001")
Loading a reference document you saved earlier
If you're not sure of the note name, use recall to search by content
or check session context with resume_session.
Args: name: The exact note name used when saving (case-sensitive). session_id: Required if the note was saved with a session_id. Omit for notes saved without a session.
Returns: The full note content. Returns an error if no note exists with that name, or if session_id is required but not provided.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Get the complete Astria operating guide.
Returns a comprehensive guide covering all available tools, recommended workflows, conventions, and best practices for working with persistent memory effectively.
Use this when:
Connecting to Astria for the first time
You need a refresher on available capabilities
Onboarding a new AI platform to your memory
Returns: The full Astria setup and usage guide as formatted text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Browse your stored memories, ordered most recent first.
Unlike recall which searches by meaning, this returns memories
in chronological order — useful for reviewing recent activity.
Use this when:
Browsing recent memories: list_memories(limit=10)
Reviewing all decisions: list_memories(category="decision")
Checking what's been stored: list_memories(category="project", limit=50)
Auditing memory before cleanup
Args: category: Optional filter — only return memories with this tag. One of: preference, fact, decision, idea, project, person, general. Omit to see all categories. limit: How many to return (default 20, max 100).
Returns: A list of memories with IDs, content, category, importance, and timestamps. Returns an empty list if no memories exist (or none match the filter).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Browse your discovered cause-and-effect patterns.
Returns insights ranked by observation frequency — patterns seen multiple times appear first, indicating higher reliability.
Use this when:
Reviewing known patterns before debugging: my_insights(limit=10)
Checking if a similar issue was seen before
Building a knowledge base of recurring problems and solutions
Onboarding someone to a project's known quirks
Args: limit: Maximum insights to return (default 20, max 50).
Returns: A list of insights with pattern, cause, solution, confidence score, and observation count. Returns an empty list if no insights recorded yet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
See a dashboard overview of your entire memory network.
Shows total counts broken down by category, plus active sessions, saved notes, learned insights, and embedding statistics.
Use this when:
Starting a conversation to understand what's in memory
Checking if memory is growing as expected
Reporting on memory utilization: my_memory_stats()
Returns: A statistics object with memory counts by category, session counts (active vs completed), note count, insight count, and embedding count. All counts are zero for a fresh instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
List all active sessions you can resume.
Call this at the start of every new conversation to check for
interrupted work. If sessions exist, use resume_session to
continue where you left off.
Use this when:
Starting any new conversation (first thing to call)
Checking what's in progress: my_sessions()
Deciding whether to start a new session or resume an existing one
Returns: A list of active sessions with IDs, descriptions, status, and last-updated timestamps. Returns an empty list if no active sessions. Completed sessions are not shown (they auto-expire after 48 hours).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Save the most important things from a session as permanent memories.
Session data expires 48 hours after completion. Use this to extract key learnings before ending a session — promoted items become permanent memories that persist forever.
Use this when:
Before calling end_session: promote_session("s001", ["OAuth2 migration requires updating all 3 microservices", "Rate limiter must fail closed for auth endpoints"])
Important decisions were made during the session
You discovered patterns worth remembering long-term
Args: session_id: The session to promote from (e.g., "s001"). Must be an active (not yet completed) session. key_takeaways: List of strings — each becomes a permanent memory. Be specific and include context so they're useful standalone.
Returns: Count of how many takeaways were promoted to permanent memory. Returns an error if the session doesn't exist or key_takeaways is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| key_takeaways | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Search your memories by meaning, not keywords.
Uses semantic similarity to find the most relevant memories you've saved. Results are ranked by how closely they match your query.
Use this when:
Looking up a past decision: recall("what database did we choose?")
Checking what you know about a topic: recall("authentication setup")
Finding a specific fact: recall("API rate limits", category="fact")
Starting a new conversation: recall("current project status") to get context
Args: query: What you're looking for, in natural language. Longer, more specific queries produce better results than single words. limit: Maximum results to return (default 5, max 20). Use higher limits when exploring a broad topic. category: Optional filter — only return memories tagged with this category. One of: preference, fact, decision, idea, project, person, general.
Returns: A ranked list of matching memories with their IDs, content, category, importance, and similarity score. Returns an empty list if no matches found. Returns an error message if the server is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Record a cause-and-effect pattern you've discovered.
Insights are the deepest memory tier — understanding WHY things happen. Over time, your memory builds a library of patterns that surface automatically when similar situations recur. If the same pattern+cause is recorded again, the confidence score increments rather than creating a duplicate.
Use this when:
A recurring bug is explained: record_insight("deploys fail on Fridays", "cache expires weekly", "flush cache before Friday deploys")
A workflow pattern emerges: record_insight("PR reviews take 3+ days", "no reviewer assigned", "auto-assign reviewers on PR creation")
A root cause is found after investigation
Args: pattern: The observable symptom or recurring situation. cause: The root cause — why this happens. solution: How to fix or prevent it. confidence: How certain you are this cause is correct (0.0 to 1.0). Use 0.5 for hypotheses, 0.7 for likely, 1.0 for confirmed.
Returns: The insight ID and how many times this exact pattern has been observed. If this pattern+cause was seen before, returns the updated confidence count.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| cause | Yes | ||
| solution | Yes | ||
| confidence | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Save something to your long-term memory.
Anything you save here persists forever and can be found later with recall
by searching for its meaning — not just exact words. Every memory is stored
in a knowledge graph with semantic embeddings.
Use this when:
You learn a fact worth keeping: remember("Our API uses OAuth2 with PKCE", category="fact")
A decision is made: remember("Chose Postgres over Mongo for ACID compliance", category="decision", importance="high")
You discover a user preference: remember("User prefers concise responses", category="preference")
An idea comes up: remember("Consider adding WebSocket support for real-time sync", category="idea")
Args: content: What to remember — facts, decisions, preferences, ideas, project context. Be specific and include reasoning when possible. category: Tag for organization. One of: preference, fact, decision, idea, project, person, general. If omitted, auto-categorized as "general". importance: Priority level — "low", "normal", or "high". High-importance memories surface first in recall results.
Returns: Confirmation with the assigned memory ID. Returns an error message if the content is empty or the server is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| category | No | ||
| importance | No | normal |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Resume a previous session and get full context to continue working.
Retrieves the session's description, progress, related memories, notes, and any sub-tasks — everything needed to continue where you left off.
Use this when:
Starting a new conversation and my_sessions shows active work: resume_session("s001")
Returning to a task after a break
Checking progress on ongoing work
Always call my_sessions first to find the correct session_id.
Args:
session_id: The session identifier (e.g., "s001") from start_session
or my_sessions results.
Returns: Full session context including description, status, timestamps, related memories, notes, and progress. Returns an error if the session_id doesn't exist or has already been completed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Save a named note for later retrieval.
Notes are stored by name and can be retrieved exactly with get_note.
Unlike memories (which are searched by meaning), notes are accessed
by their exact name — like files in a folder.
Use this when:
Saving structured data: save_note("api-endpoints", "GET /users, POST /auth, ...")
Preserving analysis results: save_note("perf-audit-2024", "P95 latency: 240ms...")
Storing meeting notes: save_note("standup-mar-15", "Discussed auth migration...")
Attaching work to a session: save_note("findings", "...", session_id="s001")
If a note with the same name already exists, it is overwritten.
Args: name: A short, descriptive name (e.g., "api-auth-flow", "meeting-notes-q1"). Use lowercase with hyphens for consistency. content: The note content. Markdown is supported. No size limit, but keep it focused — use multiple notes for different topics. session_id: Optional session to attach this note to. Notes attached to sessions appear when that session is resumed.
Returns: Confirmation that the note was saved. Returns an error if name or content is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | Yes | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
Start a working session for cross-conversation continuity.
Sessions let you pick up exactly where you left off, even days or weeks later in a completely new conversation. A session tracks your goal, progress, and related memories.
Use this when:
Beginning multi-step work: start_session("Migrating auth from JWT to OAuth2")
Starting a research task: start_session("Investigating memory leak in worker service")
Any work that will span multiple conversations
Do NOT start a session for quick, single-conversation tasks.
Call my_sessions first to check for existing sessions to resume.
Args: description: What you're working on — stored verbatim and used to restore context when resuming. Be specific enough that you'll understand the goal when you come back later.
Returns:
A session ID (e.g., "s001") to use with resume_session, end_session,
and promote_session. Returns an error if description is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Is 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.
Given 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.
Does 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.
Does 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.
Does 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.
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.
Mixed 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.
15 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.
Covers 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
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
