Memwyre is an MCP-native persistent memory layer for AI agents, synchronizing context across Claude Code, Cursor, VS Code, and OpenClaw.
Built with a high-precision retrieval architecture (dense vector search, BM25, and cross-encoder reranking), Memwyre achieves a benchmarked 73.1% accuracy on the Long-Context Memory (LoCoMo) benchmark. It provides secure, isolated knowledge vaults with dedicated tools (search_memwyre, save_memory, list_memories) to save and recall structured project decisions.
Approve a pending memory in the Inbox and begin its ingestion process.
Args:
memory_id: The ID of the memory (e.g., 'mem_123').
| 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, the description carries the full behavioral burden. It does disclose a key side effect ('begin its ingestion process') and a prerequisite (the memory must be pending in the Inbox), but it does not mention whether the action is irreversible, whether it removes the memory from the Inbox, or whether approval triggers asynchronous processing.
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 two concise sentences, with the primary action stated first and the parameter explanation kept minimal. No word is wasted.
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?
The tool is simple (one required parameter), an output schema exists, and the description explains the state prerequisite and action. It misses only minor contextual details like how to obtain memory IDs or what an already-approved memory should do, which are not critical for a first correct call.
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 schema provides only the parameter name and type, so schema description coverage is 0%. The description compensates by clearly defining memory_id as the ID of the memory and giving a concrete format example ('mem_123'), which gives the agent enough to construct a valid call.
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 uses a specific verb 'approve' on a clearly identified resource ('pending memory in the Inbox') and states the follow-on effect ('begin its ingestion process'). This distinguishes it from siblings like discard_memory or delete_memory, which handle memories differently.
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 intended context is clear: it is for pending memories in the Inbox that should be accepted. However, it never explicitly contrasts with alternative tools such as discard_memory (the reject path) or update_memory, so the agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory or document by ID from Memwyre.
Args:
memory_id: The ID of the item (e.g., 'mem_1' or 'doc_5').
| 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool deletes an item but does not mention that deletion is irreversible, whether special permissions are needed, or what side effects may occur on associated 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?
The description is short, front-loaded with the action and object, and contains no filler. Every sentence contributes useful information, and the parameter explanation is compact.
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 single-parameter tool, the description covers the core invocation details and examples. However, it lacks behavioral warnings about destructiveness and does not clarify how delete_memory differs from discard_memory, leaving some contextual gaps.
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 schema only defines memory_id as a string, while the description adds concrete meaning by explaining it is an item ID and giving format examples like 'mem_1' or 'doc_5'. This helps an agent form a valid argument despite the 0% schema description coverage.
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 clearly states the action and target: 'Delete a memory or document by ID from Memwyre.' It is specific about the resource and operation, but it does not differentiate the tool from siblings such as discard_memory, which could be confused with deletion.
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?
There is no guidance about when to use this tool versus alternatives like discard_memory, update_memory, or save_memory. The description gives no context about prerequisites, situations suited for deletion, or cases where a sibling should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discard a pending memory in the Inbox, removing it from view and deleting its embeddings.
Args:
memory_id: The ID of the memory (e.g., 'mem_123').
| 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 the full burden of disclosure. It clearly states the destructive side effect of deleting embeddings and that the memory will no longer be visible in the Inbox. It stops short of saying whether the operation is permanent or reversible, but 'discard' and 'deleting' already signal data loss.
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 compact, front-loaded with the core purpose, and spends exactly one line on the parameter. Every sentence contributes information; there is no filler or repetition of schema fields.
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 one-parameter tool with an output schema and low complexity, this description covers what the tool does, what effect it has, and which ID to pass. The main omission is a clearer distinction from delete_memory, but that gap is more about usage routing than about invoking the tool correctly.
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%, so the description must compensate. It identifies memory_id as 'The ID of the memory' and provides a concrete format example ('mem_123'), which is meaningful beyond the schema's bare title 'Memory Id'. For a single simple string parameter, this is adequate guidance.
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 uses a specific verb ('Discard') and identifies a precise resource state ('a pending memory in the Inbox'). It also clarifies the observable effects ('removing it from view and deleting its embeddings'), which sets it apart from sibling tools like approve_memory or delete_memory without requiring schema inspection.
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 intended context is implied: the tool is for pending memories currently in the Inbox. However, it does not explicitly contrast with alternatives such as delete_memory or approve_memory, nor does it state when not to use it. An agent could infer usage, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all tags currently used in Memwyre.
Use this to understand the taxonomy of the user's knowledge.
Args:
workspace_name: Optional name of the workspace directory. Pass this so that tags are filtered by this project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_name | 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 behavioral burden. It indicates a read-only action ('Get a list') and adds that tags are 'currently used' and can be filtered by workspace, which is useful. However, it does not disclose output format, error behavior, or whether unsaved/pending tags are included.
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 short and front-loaded with the core action. The purpose phrase and parameter explanation each add useful information, with no filler or repetition of the schema.
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?
The tool is simple, has a single optional parameter, and an output schema exists. The description plus schema covers the main invocation needs. Still, a brief note on default behavior when workspace_name is absent would make it fully complete.
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 schema only says workspace_name is an optional string with a null default, so description-level meaning is essential. The description compensates well by explaining it is a workspace directory name and that passing it filters tags by a specific project workspace.
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 clear verb and resource: 'Get a list of all tags currently used in Memwyre.' This makes the tool's function immediately obvious and distinguishes it from sibling tools, which all focus on memories or documents rather than tags.
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 provides a clear intended use: 'Use this to understand the taxonomy of the user's knowledge.' It also explains when to pass workspace_name. No explicit alternatives or exclusions are given, but none are needed since no sibling tool directly covers tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full content of a specific document by ID from Memwyre.
Args:
doc_id: The ID of the document.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does reveal that the operation returns the full content and the verb 'Retrieve' implies a read-only action, but it does not mention error handling, permissions, or behavior for missing/deleted documents. Acceptable for a simple getter, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the operation front-loaded and the single argument listed afterward. Every sentence carries necessary information with no filler or redundant restatement.
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 single-parameter getter with an output schema, the description supplies the essential operation and parameter meaning. It lacks sibling-routing guidance and edge-case behavior, but those are minor gaps for this level of complexity.
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%, so the description must compensate. It clarifies that doc_id is the ID of the document, but this largely restates the parameter name and title and adds no details about ID format, how to obtain it, or validation behavior.
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 clearly states the action ('Retrieve'), the resource ('document by ID'), and the scope ('full content' from Memwyre). It is distinguishable from list-oriented siblings, but it does not explicitly differentiate itself from the similarly named get_memory tool.
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?
There is no guidance on when to use get_document versus get_memory, list_memories, or search_memwyre. The only implied usage is that the caller already has a doc_id, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of pending memories in the Memwyre Inbox.
Args:
workspace_name: Optional name of the workspace directory to filter inbox items.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_name | 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 full burden. It indicates a read operation ('Get list') but does not disclose side effects, permission requirements, behavior when inbox is empty, or pagination. The term 'pending' implies state but no detail on how items become pending or what actions affect them.
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?
Very concise, using two lines with an Args section. Every word earns its place, and the main action is front-loaded. Could be slightly more structured with headings, but for a single-parameter tool it's appropriately sized.
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?
Tool is simple (1 optional param) and has an output schema, so description needn't detail return values. However, with no annotations, it lacks behavioral context (e.g., safety, side effects). It covers the main purpose and filter but leaves open questions about what 'pending' means and how the list is ordered. Adequate but not thorough.
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%, but the description compensates by explaining workspace_name: 'Optional name of the workspace directory to filter inbox items.' This adds meaning beyond the bare schema (string/null, default null), clarifying it is a filter and optional. However, it doesn't specify behavior when omitted or provided, but the core semantics are 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?
Description clearly states the verb (Get), resource (list of pending memories), and specific scope (Memwyre Inbox). It distinguishes from broad siblings like list_memories by specifying 'pending memories in the Inbox', though it doesn't explicitly name alternatives. Slight ambiguity remains about what 'pending' means, but purpose is understandable.
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?
No guidance on when to use this tool versus siblings like list_memories or get_memory. It does not mention prerequisites, timing, or exclusions. The only hint is the unique 'Inbox' context, which is implied but not stated as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full, unabridged content of a specific memory by its ID from Memwyre.
Use this when `search_memwyre` returns a snippet with `[ID: mem_XXX]` and you need to read the complete original document, report, or note.
Args:
memory_id: The ID of the memory (e.g., 'mem_73').
| 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 the disclosure burden. It clearly conveys a read-only retrieval by using 'Retrieve' and emphasizes 'full, unabridged content' as opposed to a snippet. It does not explicitly state that no modifications are made or how missing IDs are handled, but for a simple get-by-ID tool the core behavior is sufficiently transparent.
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 main purpose is stated in the first sentence, the usage condition follows immediately, and the parameter line is minimal. Every sentence earns its place; there is no filler or redundant boilerplate.
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 one-parameter get-by-ID tool with an output schema, the description supplies everything needed: how to obtain the ID (from search_memwyre snippets), the fact that it returns the full content, and the parameter format. The reliance on an output schema to explain the return shape is appropriate.
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 provides only the name and type for memory_id, with no description (0% coverage). The description compensates by defining it as 'The ID of the memory' and supplying a concrete example ('mem_73'), and the usage text explains where such IDs come from ([ID: mem_XXX] in search results). This is adequate for a single parameter, though the semantic definition is mostly a restatement of the parameter name.
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 states the specific action ('Retrieve the full, unabridged content'), the resource ('a specific memory by its ID from Memwyre'), and distinguishes it from search_memwyre, which only returns snippets. This leaves no ambiguity about what the tool returns or how it differs from sibling tools.
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?
It gives an explicit trigger condition: use when search_memwyre returns a snippet with [ID: mem_XXX] and you need the complete original document/report/note. This names the upstream tool and the exact condition under which get_memory is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent memories and documents in Memwyre.
Args:
limit: Number of items to return (default 10).
offset: Pagination offset (default 0).
workspace_name: Optional name of the workspace directory. Pass this so that items are filtered by this project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| workspace_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It communicates recency, pagination, and workspace filtering, but it does not clarify the sort semantics of 'recent', whether the operation is read-only, or the default behavior when workspace_name is omitted. These are moderate gaps for a listing tool.
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 appropriately sized: one purpose sentence followed by a clean, concise Args block. Information is front-loaded and every sentence earns its place.
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 low-complexity listing tool with an output schema and three optional parameters, the description covers purpose, filtering, and pagination sufficiently. It leaves 'recent' undefined and does not specify ordering guarantees, but these are minor gaps given the tool's simplicity.
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%, and the description compensates by defining all three parameters. It adds real meaning beyond the schema, especially for workspace_name ('name of the workspace directory', 'filtered by this project workspace'), though limit and offset mostly restate their defaults.
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 names a specific verb ('List') and resource ('recent memories and documents'), making the operation clear. It does not explicitly distinguish itself from sibling search/get tools, so it falls just short of a 5.
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 implies the tool is used to retrieve recent items and explains when workspace_name should be passed for filtering. It does not state when to prefer this tool over search_memwyre/search_by_date or single-item get_memory/get_document, leaving usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new memory or document to the Memwyre Vault.
Supports short notes, conversation facts, or full long-form Markdown documents/reports of any length.
The backend automatically chunks, enriches, and indexes long text into vector and graph storage.
DO NOT summarize long reports, architecture specs, or code snippets — pass the full text directly.
Args:
text: The full content to save. Markdown is fully supported and preserved (tables, code blocks, lists, headers).
title: Optional title for the memory (e.g., 'Production Retrieval Benchmark' or 'System Architecture'). If omitted, one is auto-extracted from the first heading.
source: Source of memory (default 'mcp').
tags: Optional list of tags for categorization (e.g., ['benchmarks', 'architecture', 'database']).
workspace_name: Optional name of the workspace directory to scope this memory.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| text | Yes | ||
| title | No | ||
| source | No | mcp | |
| workspace_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does a solid job: it discloses automatic chunking, enrichment, vector/graph indexing, Markdown preservation, and auto-extracted titles. It does not mention duplicate handling, permissions, or overwrite behavior, but the core side effects are transparent.
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 front-loaded with the purpose, then covers backend behavior, a critical do-not-summarize instruction, and parameter details. Every sentence adds practical value with no filler or redundancy.
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?
The definition covers content formats, long-document handling, title fallback, source default, tags, and workspace scoping, while the output schema covers return values. The only notable omission is explicit guidance for choosing between save_memory and update_memory/upsert_memory for existing content.
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%, but the Args section compensates fully by explaining all five parameters, including defaults, examples, and behavioral details like auto-title extraction and Markdown support. This gives the agent meaning far beyond the raw JSON 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 states a clear verb and resource: saving a new memory or document to the Memwyre Vault, and lists supported content types. It uses 'new memory' to signal creation, which helps separate it from update_memory, though it does not explicitly name sibling tools to fully differentiate them.
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 gives good content-type guidance, including when long documents should be passed in full without summarization. However, it does not explicitly state when save_memory should be preferred over sibling tools like upsert_memory or update_memory for existing content, leaving that routing implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find memories in Memwyre created within a specific date range.
Args:
start_date: Start date in YYYY-MM-DD format.
end_date: End date in YYYY-MM-DD format (optional, defaults to end of start_date).
workspace_name: Optional name of the workspace directory. Pass this so that items are filtered by this project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| start_date | Yes | ||
| workspace_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does convey a read-only lookup by creation date plus optional workspace filtering. It does not discuss edge behavior such as date boundary inclusivity, timezone interpretation, or result ordering, but those are not critical for a basic call.
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 compact and front-loaded with the core purpose before parameter details. Every line adds useful information without repetition or filler.
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?
All parameters are fully documented, and an output schema exists, so the agent can invoke the tool and interpret results. The main missing piece is routing guidance among the many sibling search/list tools, but that is more a usage gap than an invocation-completeness gap.
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 schema has zero description coverage, and the description compensates fully: it provides the YYYY-MM-DD format for start_date, default behavior for end_date, and the purpose of workspace_name for filtering. This adds meaningful semantics beyond the bare schema titles.
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?
States a specific operation and resource: finding memories in Memwyre filtered by creation date, which distinguishes it from sibling tools like list_memories and search_memwyre. However, it doesn't explicitly name or contrast those siblings; the distinction is carried by the date-range phrasing.
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?
No guidance is provided on when to prefer this tool over search_memwyre or list_memories, and no exclusions are stated. The only usage cue is implied by the description and the optional workspace_name filtering note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The PRIMARY tool for searching the user's "Memwyre". Use this to retrieve relevant context, notes, code snippets, or past conversations from the Memwyre Vault.
ALWAYS use this before answering questions that might require personal context or project knowledge.
Results include item IDs (e.g. `[ID: mem_123]` or `[ID: doc_45]`). You can pass these IDs to `get_memory` to read full unchunked text, or to `update_memory` / `delete_memory`.
Args:
query: The semantic search query (e.g., "python fastapi project structure", "notes on meeting with Bob", or "auth system specs").
purpose: Optional hint for context formatting ("general", "code", "summary").
workspace_name: Optional name of the workspace directory. Pass this so that search is scoped strictly to this project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| purpose | No | general | |
| workspace_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explains the semantic nature of search, optional workspace scoping, and that results include item IDs that can be passed to get_memory/update_memory/delete_memory. It stops short of explicitly stating read-only behavior or result limits, but 'retrieve' implies non-mutation.
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 and front-loaded with purpose and usage guidance before the args block. It is slightly repetitive ('PRIMARY', 'ALWAYS use this', 'retrieve...') but each sentence contributes functional value, so only mildly verbose.
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 primary search tool with an output schema and no annotations, the description provides enough context to select and call it correctly: what to search, how to scope, what IDs look like, and what tools consume them. No critical gap is evident.
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%, and the description fully compensates by explaining all three parameters: query with concrete examples, purpose with allowed hint values, and workspace_name with scoping semantics. This goes well beyond the bare schema types and defaults.
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?
Clearly identifies the tool as 'The PRIMARY tool for searching the user's Memwyre' and enumerates the retrievable content types (context, notes, code snippets, past conversations). The 'semantic search query' phrasing distinguishes it from date-oriented siblings like search_by_date.
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 a strong when-to-use directive ('ALWAYS use this before answering questions that might require personal context or project knowledge') and explains downstream ID usage. No explicit when-not-to-use alternatives are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the content of an existing memory in Memwyre.
Requires the memory ID (e.g., 'mem_73'), which can be discovered using `search_memwyre` or `list_memories`.
The new content is completely re-chunked and re-indexed into the vector store.
Full Markdown documents are supported and encouraged — do not truncate.
Args:
memory_id: The ID of the memory (must start with 'mem_').
content: The new, full content (Markdown fully supported).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses an important behavioral trait: content is completely re-chunked and re-indexed into the vector store. It also encourages full Markdown documents and warns not to truncate. It does not mention irreversibility or failure behavior, but the disclosed traits go beyond a basic update statement.
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 compact and well-structured: purpose first, then prerequisite/discovery, then behavioral note, then an Args breakdown. Every sentence earns its place with no filler.
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?
The definition covers purpose, how to obtain the memory ID, what the update does to the vector store, and parameter constraints. With an output schema present, return values need no explanation. Minor gaps remain around invalid IDs or empty content, but for a two-parameter update tool the description is largely complete.
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%, but the description's Args section adds critical semantics: memory_id must start with 'mem_' and serves as the target identifier; content should be the new full content with full Markdown support. This fully compensates for the bare 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 clearly states the verb ('Update') and resource ('existing memory in Memwyre'), making the core purpose unmistakable. However, it does not explicitly differentiate from sibling tools like save_memory or upsert_memory, though 'existing memory' implies a distinction.
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 clear context on prerequisites: requires a memory ID discoverable via search_memwyre or list_memories. It implies this tool is for existing memories, but it does not explicitly state when to avoid it or name alternative tools such as save_memory or upsert_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save or update a living memory/document by title in the Memwyre Vault.
If a memory with a matching title already exists in this workspace, it will be updated in-place with the new text and re-indexed (preventing duplicate entries).
If no existing memory matches the title, a new memory is created.
Use this tool when maintaining living documents (e.g. project architecture, meeting notes, benchmarks, user preferences).
Args:
title: Unique title or topic name (e.g., 'Production Retrieval Benchmark' or 'System Architecture').
text: The full content to save or update (Markdown fully supported, do not summarize).
source: Source of memory (default 'mcp').
tags: Optional list of categorization tags (e.g., ['benchmarks', 'architecture']).
workspace_name: Optional workspace name to scope this memory.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| text | Yes | ||
| title | Yes | ||
| source | No | mcp | |
| workspace_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it discloses important behavioral traits: existing memories are updated in-place, re-indexed, duplicate entries are prevented, and new memories are created when no title matches. It stops short of describing permissions, irreversibility of the old text, or response details, but the core mutation and idempotence behavior is clearly communicated.
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: a focused opening states the core operation, two conditional sentences explain the upsert logic, a usage sentence gives context, and an Args list maps cleanly to the schema. Every sentence adds value; nothing is redundant or wasted.
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 tool with five parameters and an output schema, the description covers the essential context: the update-vs-create decision, the deduplication behavior, appropriate use cases, and parameter semantics. Since an output schema exists, not describing return values is acceptable. The description gives an agent everything needed to invoke this tool correctly.
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 schema has 0% description coverage, so the description must compensate—and it does. Each parameter gets practical guidance: title is described as unique with examples, text instructs the agent not to summarize and notes Markdown support, source gets its default, tags get formatting examples, and workspace_name is explained as a scope. This goes well beyond the bare schema titles.
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 states the exact behavior with a specific verb phrase ('Save or update a living memory/document by title') and explains the upsert mechanics: update-in-place if the title exists, create if it doesn't. This clearly distinguishes it from siblings like save_memory and update_memory by the deduplication and re-indexing behavior.
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?
It explicitly names when to use this tool: 'when maintaining living documents' with helpful examples (project architecture, meeting notes, benchmarks, user preferences). It does not explicitly contrast with save_memory or update_memory or list exclusions, but the provided usage context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools map cleanly to distinct operations such as semantic search, date search, inbox approval/discard, and tag listing. The main ambiguity is between save_memory and upsert_memory, both of which can create memories with similar arguments; get_memory/get_document and delete_memory/discard_memory are also distinguishable mainly by ID prefix or inbox state.
The names are consistently lowercase snake_case and verb-first, which makes the set fairly predictable. Minor deviations include search_by_date breaking the verb_noun pattern, get_inbox/get_all_tags acting as list operations while list_memories uses 'list', and upsert_memory being an unusual verb.
At 13 tools, the surface is well-scoped for a memory/document vault: create, upsert, update, retrieve, list, semantic and date search, tags, and inbox workflow are all represented without excessive granularity or redundant filler.
The toolset covers the core memory lifecycle well, including save, upsert, update, get, search, list, delete, and inbox approval/discard. Minor gaps remain: update_memory only accepts mem_ IDs, so documents found via search have no document-specific update path, and workspace management is only handled through optional name strings.