Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mem.ai MCP Server save 'dentist appointment next Tuesday' to my memory"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for mem.ai API integration. This server enables AI assistants like Claude to interact with your mem.ai memory through a standardized interface.
Complete API Coverage: All 11 mem.ai API endpoints wrapped as MCP tools
TypeScript: Fully typed with strict mode enabled
Easy Integration: Works seamlessly with Claude Desktop and other MCP clients
Error Handling: Comprehensive error handling with detailed messages
Validation: Input validation using Zod schemas
Related MCP server: MCP Server for Mem.ai
No installation required! You can run the server directly using npx (recommended), or install it globally if you prefer.
npx @hskksk/mem-ai-mcp-serverThis automatically downloads and runs the latest version without requiring installation.
npm install -g @hskksk/mem-ai-mcp-serverVisit mem.ai settings
Generate a new API key
Copy the key for configuration
Create a .env file or set environment variables:
MEM_API_KEY=your_api_key_hereOptional configuration:
# Override the default API base URL (default: https://api.mem.ai)
MEM_API_BASE_URL=https://api.mem.aiAdd the following configuration to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"mem-ai": {
"command": "npx",
"args": ["-y", "@hskksk/mem-ai-mcp-server"],
"env": {
"MEM_API_KEY": "your_api_key_here"
}
}
}
}After restarting Claude Desktop, you'll be able to use mem.ai tools in your conversations.
If you've installed the package globally:
{
"mcpServers": {
"mem-ai": {
"command": "mem-ai-mcp-server",
"env": {
"MEM_API_KEY": "your_api_key_here"
}
}
}
}# Using npx (recommended)
MEM_API_KEY=your_api_key_here npx @hskksk/mem-ai-mcp-server
# Or if installed globally
MEM_API_KEY=your_api_key_here mem-ai-mcp-servermem_it - Remember any content intelligently
Primary endpoint for saving information to mem.ai
Supports context and instructions for better processing
Parameters: input (required), instructions, context, timestamp
create_note - Create a new note with markdown content
Parameters: content (required), id, collection_ids, collection_titles, created_at, updated_at
get_note - Retrieve a specific note by ID
Parameters: noteId (required)
delete_note - Delete a note
Parameters: noteId (required)
list_notes - List all notes with advanced filtering and pagination
Supports cursor-based pagination with page and next_page
Parameters:
limit - Maximum number of results (default: 50, max: 100)
page - Cursor for pagination (from previous next_page)
order_by - Sort order: created_at or updated_at (default: updated_at)
collection_id - Filter by collection ID
contains_open_tasks - Filter notes with open tasks
contains_tasks - Filter notes with any tasks
contains_images - Filter notes with images
contains_files - Filter notes with files/attachments
include_note_content - Include full markdown content in response
search_notes - Search across notes with advanced filtering
Parameters:
query - Search query (optional)
filter_by_collection_ids - Filter by collection IDs array
filter_by_contains_open_tasks - Filter notes with open tasks
filter_by_contains_tasks - Filter notes with any tasks
filter_by_contains_images - Filter notes with images
filter_by_contains_files - Filter notes with files
config - Response configuration (include_snippet, include_content)
create_collection - Create a new collection
Parameters: title (required), description
get_collection - Retrieve a specific collection by ID
Parameters: collectionId (required)
delete_collection - Delete a collection
Parameters: collectionId (required)
list_collections - List all collections with pagination
Supports cursor-based pagination with page and next_page
Parameters:
limit - Maximum number of results (default: 50, max: 100)
page - Cursor for pagination (from previous next_page)
order_by - Sort order: created_at or updated_at (default: updated_at)
search_collections - Search across collections
Parameters:
query - Search query (optional)
config - Response configuration (include_description)
Node.js >= 20.0.0
pnpm (recommended) or npm
# Clone the repository
git clone https://github.com/hskksk/mem-ai-mcp-server.git
cd mem-ai-mcp-server
# Install dependencies
pnpm install
# Copy environment template
cp .env.example .env
# Edit .env and add your API key# Run in development mode with auto-reload
pnpm dev
# Build the project
pnpm build
# Run tests
pnpm test
# Type check
pnpm type-check
# Lint
pnpm lintsrc/
├── index.ts # Entry point
├── server.ts # MCP server setup
├── config/
│ └── env.ts # Environment configuration
├── client/
│ └── mem-api-client.ts # mem.ai API client
├── tools/ # MCP tool implementations
│ ├── base-tool.ts
│ ├── mem-it.ts
│ ├── notes/
│ └── collections/
├── types/ # TypeScript type definitions
└── utils/ # Utility functionsFor detailed information about the mem.ai API, visit the official API documentation.
The server provides detailed error messages for common issues:
401 Unauthorized: Invalid API key
404 Not Found: Resource not found
429 Too Many Requests: Rate limit exceeded
500 Server Error: Internal server error
All errors are returned in a structured format for easy debugging.
Contributions are welcome! Please feel free to submit a Pull Request.
This project is licensed under the MIT License - see the LICENSE file for details.
If you encounter any issues or have questions:
Check the GitHub Issues
Create a new issue with detailed information
Refer to the mem.ai API documentation
See CHANGELOG.md for the full version history.
Create a new collection in mem.ai.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Collection title | |
| description | No | Collection description |
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 states a create action, which implies mutation, but provides no additional behavioral details such as authentication requirements, side effects, duplicate handling, or return value. This is minimal and does not enrich the agent's understanding beyond the obvious.
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 a single, concise sentence that directly states the tool's purpose. There is no fluff, and it is appropriately sized for the simplicity of the operation.
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 lack of annotations and output schema, the description is quite sparse. It does not mention return values, potential errors, or any constraints. While the schema covers parameter semantics, the description alone is insufficient for an agent to fully understand the context of a mutating operation, especially without any sibling differentiation.
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 has 100% description coverage for both parameters (title and description), so the baseline is 3. The description itself only says 'Create a new collection' and adds no extra meaning beyond what the schema already provides. It does not compensate for any gaps because there are none.
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 (create) and the resource (collection) within the specific context (mem.ai). It is unambiguous and distinguishes itself from sibling tools like get_collection, delete_collection, and list_collections.
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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conflicts, or when a different tool might be more appropriate. The sibling tools are listed, but the description does not reference them or explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new note in mem.ai with markdown content.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional UUID for the note | |
| content | Yes | Markdown formatted note content | |
| created_at | No | ISO 8601 creation timestamp | |
| updated_at | No | ISO 8601 update timestamp | |
| collection_ids | No | Collection IDs to add the note to | |
| collection_titles | No | Collection titles to add the note to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral implications. It only restates the core action and does not mention side effects, prerequisites, idempotency, what happens if an ID is provided, or what the response looks like.
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 a single sentence of 9 words, direct and front-loaded with the key verb and object. Every word contributes value, with no unnecessary detail or repetition.
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 lack of annotations and output schema, the description is incomplete. It does not explain return values, optional collection behavior, or any edge cases. For a tool with 6 parameters, the description should provide more context about the creation flow and potential outcomes.
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 already provides descriptions for all 6 parameters (100% coverage), so the baseline is 3. The description adds no extra meaning beyond what the schema contains; mentioning 'markdown content' is redundant with the content parameter description.
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 ('Create'), the target resource ('a new note'), the platform ('in mem.ai'), and the content format ('with markdown content'). This specific language distinguishes it from sibling tools like get_note, delete_note, and search_notes.
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 usage for creating notes but does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or when another tool would be more appropriate, such as for updating or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a collection from mem.ai.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | Collection ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether deleting a collection has side effects on contained notes, whether deletion is permanent, or any other non-obvious behavioral traits beyond the literal action.
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 a single clear sentence with no filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a destructive operation. It does not explain what happens to notes in the collection, return values, or any prerequisites, leaving significant gaps for an agent.
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 100% coverage for the single parameter collection_id, which includes a description. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 a specific verb ('Delete') and resource ('collection from mem.ai'), which distinguishes it from sibling tools like delete_note and collection-related operations.
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 use this tool vs alternatives. The description only states what it does and does not mention exclusions or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a note from mem.ai.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Note ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Delete a note from mem.ai.' It fails to disclose whether the deletion is permanent, reversible, or requires confirmation. No side effects or consequences are described, making it insufficient for a destructive action.
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 a single sentence with no redundant words. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description is minimal and omits critical context such as irreversibility or success/failure responses. Given the destructive nature, this is incomplete.
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 100% and the parameter 'note_id' is already described as 'Note ID to delete'. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 specifies the verb 'Delete' and the resource 'a note from mem.ai', making the tool's purpose unambiguous. It distinguishes from sibling tools like get_note or create_note by indicating a destructive action on a 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?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or context. The only usage signal is the verb 'Delete', which is implied but not explicitly framed as a conditional or contrasted with other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific collection by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | Collection ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It tells the agent that the tool retrieves, but it does not specify whether any side effects occur, what happens if the ID does not exist, or whether authentication is required. The verb 'retrieve' implies read-only, but that is not explicitly stated.
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 a single concise sentence that directly states the tool's function. There is no wasted wording.
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 simplicity of the tool (one parameter, no output schema), the description is minimally viable. However, it lacks any mention of return behavior, errors, or permissions, which could be important for the agent to make fully informed decisions. The description is adequate for a simple read operation but not 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?
The input schema covers 100% of the parameter, describing collection_id as 'Collection ID to retrieve' with a uuid format. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Retrieve') and resource ('a specific collection'), with the scope 'by its ID.' This distinguishes it from sibling tools like list_collections or search_collections, which operate 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 description implies usage when you have a collection ID and need the specific collection, but it does not explicitly contrast with sibling tools like list_collections or search_collections. There is no exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific note by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Note ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully carry the burden of behavioral disclosure. It only states the basic action and does not disclose potential side effects, return value details, error behavior, or permission requirements, which are important for a tool with no annotation support.
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 a single, focused sentence that conveys the essential purpose without any fluff or redundant information. It is optimally concise and structurally sound.
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, the description covers the core function, but it omits important context such as what the response contains, error conditions, or whether any special permissions are needed. Since there is no output schema or annotations, these gaps could impact an agent's ability to use 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?
The input schema already describes the sole parameter (note_id) with a clear description. The tool description repeats 'by its ID' but adds no extra semantic information beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (note), and the method (by ID). It distinguishes itself from sibling tools like list_notes and search_notes by specifying the exact retrieval mechanism.
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 that this tool should be used when you have a specific note ID, but it does not explicitly state when to prefer it over search_notes or list_notes, nor does it exclude any scenarios. Usage context is implied rather than explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections in mem.ai with optional sorting and cursor-based pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Cursor for pagination (from previous next_page) | |
| limit | No | Maximum number of results (default: 50) | |
| order_by | No | Sort order (default: updated_at) |
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 disclosing behavioral traits. It does not explicitly state that this is a safe, read-only operation, nor does it mention any side effects, authentication needs, or rate limits. The mention of cursor-based pagination is already captured in the schema, adding no additional transparency.
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 a single, front-loaded sentence that conveys the core function and key options without any wasted words. It is compact and efficient.
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 list tool, the description covers the essential behavior: listing all collections with sorting and pagination. Since there is no output schema, the description does not explain return structure, but the term 'list' implies a collection of results, which is sufficient for most use cases. It also aligns well with the sibling tool set.
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 100%, so the baseline is 3. The description mentions sorting and pagination but does not add any meaning beyond what the schema already provides for each parameter. It does not clarify default values or parameter interactions beyond what is 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 clearly states the tool lists collections in mem.ai, which is a specific verb+resource. It also mentions optional sorting and cursor-based pagination, distinguishing it from single-collection tools like get_collection and search_collections.
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 says 'List all collections' which clearly communicates its primary use case. It does not explicitly exclude alternative tools or mention when not to use it, but the context is clear enough for an agent to select it over get_collection or search_collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all notes in mem.ai with optional filtering, sorting, and cursor-based pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Cursor for pagination (from previous next_page) | |
| limit | No | Maximum number of results (default: 50) | |
| order_by | No | Sort order (default: updated_at) | |
| collection_id | No | Filter by collection ID | |
| contains_files | No | Filter notes containing files | |
| contains_tasks | No | Filter notes containing any tasks | |
| contains_images | No | Filter notes containing images | |
| contains_open_tasks | No | Filter notes containing open tasks | |
| include_note_content | No | Include full markdown content in response |
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 does mention cursor-based pagination and optional filtering/sorting, but it does not disclose default response behavior (e.g., whether note content is included), response shape, or any rate limits. Still, it accurately conveys that this is a read-style listing 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?
The description is a single, well-structured sentence that front-loads the core purpose and packs meaningful capabilities without unnecessary detail. Every word 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?
The tool has 9 parameters and no output schema, so the description needs to provide a useful overview. It does cover the main purpose and capabilities, but it omits guidance on when to choose this over search_notes, and it does not explain return-value structure or pagination mechanics. The schema compensates for parameter details, but the lack of usage alternatives and behavior specifics leaves some 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?
Schema coverage is 100%, so the description does not need to explain individual parameters. It adds only a high-level mention of filtering, sorting, and pagination, which is already reflected by the schema properties. No additional semantic value beyond the schema is provided.
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 ('List') and resource ('all notes in mem.ai'), clearly distinguishing it from siblings like get_note (single note) and search_notes (search). It also communicates the optional filtering, sorting, and pagination capabilities at a high level.
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 clearly implies use for enumerating all notes with optional filters, which is distinct from search or single-note retrieval. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remember any content intelligently. This is the primary endpoint for saving information to mem.ai.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Content to remember (max ~1MB) | |
| context | No | Background context | |
| timestamp | No | ISO 8601 timestamp | |
| instructions | No | Processing instructions |
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 only says 'Remember any content intelligently' and 'saving information,' but does not disclose whether this creates a record, whether it deduplicates, how 'intelligently' manifests, or what side effects may occur. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the primary action ('Remember any content intelligently') and then clarifies the scope ('primary endpoint for saving information to mem.ai'), which is concise and effective.
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?
While the schema fully documents parameters and the purpose is clear, the absence of an output schema and annotations leaves unanswered questions about what the tool returns or any constraints (e.g., rate limits). The description is minimally viable but not rich enough to fully orient an agent for a generic save endpoint with no output schema.
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 100% description coverage for all four parameters, including explanations for 'input', 'context', 'timestamp', and 'instructions'. The description itself adds nothing about parameters, so with the schema already doing the heavy lifting, the baseline of 3 is appropriate.
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 tool's purpose: 'Remember any content intelligently' with the explicit clarification that it is 'the primary endpoint for saving information to mem.ai.' This is a specific verb+resource combination and distinguishes it from sibling tools like get_note and create_note, which operate on notes and collections.
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 explicitly frames this as 'the primary endpoint for saving information to mem.ai,' which implies this is the go-to tool for general saving, as opposed to siblings that handle categories like notes or collections. However, it stops short of saying when not to use it or naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all collections in mem.ai with optional query and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (optional) | |
| config | No | Response configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing behavioral traits. It only says 'Search' and mentions optional query/configuration, without describing read-only nature, return format, pagination, or effects of the config option. This is a minimal, non-disclosing description.
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 a single concise sentence with no filler words, making it easy to parse. However, the term 'configuration' is vague and the description is borderline under-specified, so it is concise but not perfectly crafted.
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?
With no output schema and no annotations, the description needed to explain return values and broader behavior, but it does not. It only states the basic search capability and optional parameters, leaving significant contextual gaps for a tool with a nested config object.
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 100%, with both 'query' and 'config' described in the schema. The description adds no additional meaning beyond restating 'optional query and configuration', so the baseline of 3 applies.
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 the specific verb 'Search' with the resource 'all collections in mem.ai', making the core purpose clear. However, it does not explicitly distinguish this from sibling tools like list_collections or search_notes, so it is clear but not fully differentiating.
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 no guidance on when to use this tool versus alternatives. It only states what the tool does and mentions optional inputs, with no exclusions, prerequisites, or comparison to sibling tools like search_notes or list_collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all notes in mem.ai with optional query and advanced filtering options.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (optional) | |
| config | No | Response configuration | |
| filter_by_collection_ids | No | Filter by collection IDs | |
| filter_by_contains_files | No | Filter notes with files | |
| filter_by_contains_tasks | No | Filter notes with any tasks | |
| filter_by_contains_images | No | Filter notes with images | |
| filter_by_contains_open_tasks | No | Filter notes with open tasks |
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 only states the search capability and mentions 'advanced filtering options' without disclosing behavior such as return format, pagination, result ordering, or any side effects. This is insufficient for a search tool with no output 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?
The description is a single sentence, 13 words, front-loaded with the action and resource, and contains no filler or redundant information. Every word 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?
With 7 parameters, including a nested config object, and no output schema or annotations, the description is too minimal. It does not explain what the search returns, whether results are paginated, or how the advanced filters behave. The schema covers parameters but leaves operational context missing.
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 100%, with each parameter having a description (e.g., query, config, filters). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
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 'Search across all notes in mem.ai', which is a specific verb (Search) and resource (notes), with optional query and advanced filtering. It distinguishes from siblings like get_note (retrieves a single note), list_notes (lists notes without search), and search_collections (searches collections).
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 no guidance on when to use this tool versus alternatives. It does not mention get_note, list_notes, or any exclusions. The word 'Search' implies a distinct use case, but there is no explicit or clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0create_collectioncreate_notedelete_collectiondelete_noteget_collectionget_notelist_collectionslist_notesmem_itsearch_collectionssearch_notesScored across 11 tools
mem_it and create_note both handle saving content, creating ambiguity in which to use. list_notes and search_notes have overlapping filtering and query capabilities, though descriptions help differentiate. Overall, most tools target distinct operations.
Most tools follow a consistent verb_noun pattern with pluralization for listing/searching. The exception is 'mem_it', which breaks the convention and uses an imperative phrase instead of a clear verb_noun structure.
11 tools cover two main resources (notes and collections) with a full set of CRUD-like operations plus search and a special save capability. This is well-scoped and appropriate for the server's purpose.
The tool set provides create, get, delete, list, and search for both notes and collections, but lacks update operations for either resource, which is a notable gap for a note-taking service. This prevents agents from modifying existing notes or collections.
Securely search, create, and organize your Mem notes and collections from AI assistants.
Full-control memory API for AI agents — memories, collections, links, search, and bulk operations.
Shared memory for AI tools — save notes and work records, recall them from any other tool.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
