Click on "Install 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., "@@memlane/mcp search my saves for 'artificial intelligence'"
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.
Connect Memlane, your personal library of saved links and notes, to AI assistants that support local MCP servers.
Related MCP server: Mem0 MCP Server
This server runs locally via stdio. Most compatible hosts use the same JSON shape:
{
"mcpServers": {
"memlane": {
"command": "npx",
"args": ["-y", "@memlane/mcp"],
"env": {
"MEMLANE_API_KEY": "ml_live_…"
}
}
}
}Variable | Required | Default |
| Yes | n/a |
| No |
|
After npm install -g @memlane/mcp, you can use "command": "memlane-mcp" instead of npx.
Host | Where to add the config |
Settings → MCP, or | |
| |
| |
VS Code + Copilot |
|
|
For ChatGPT and Claude Desktop, use the remote MCP endpoint instead (OAuth, no API key).
Restart the host app after editing config files.
VS Code uses "servers" as the root key (not "mcpServers"):
{
"servers": {
"memlane": {
"command": "npx",
"args": ["-y", "@memlane/mcp"],
"env": {
"MEMLANE_API_KEY": "ml_live_…"
}
}
}
}Enable MCP in VS Code settings: "chat.mcp.enabled": true.
ChatGPT, Claude Desktop, Claude on the web, and other remote MCP clients cannot run npx. Use Memlane's hosted endpoint instead:
URL: https://api.memlane.io/mcp
In your AI app, add a custom MCP connector with that URL.
Complete the OAuth sign-in flow (Memlane account: magic link or future social providers).
Approve access on the consent screen.
No API key required. Disconnect by removing the connector in your AI app's settings.
The local server exposes 10 MCP tools. Full function reference:
docs/TOOLS.md — what each tool does, parameters, return shapes, and workflow tips
docs/API.md — REST mappings, auth scopes, and curl examples
Tool | Description |
| Semantic search over your library |
| Browse saves with filters (project, topic, kind, status) |
| Fetch metadata; optional full markdown body |
| Save a URL (enrichment runs in the background) |
| Create or edit markdown notes |
| List projects and topics |
| Tag or untag a save |
API keys are secrets. Store them in your MCP host's environment config. Never commit them to version control. Revoke a leaked key in Manage → Connections → API keys.
MIT
Attach a topic to a saved link or note
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | ||
| topicId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether the tool is idempotent, what happens if the topic is already attached, or any side effects like overwriting.
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, short and to the point. It could be slightly improved by adding more context without being 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?
Given the lack of output schema and minimal description, there is no info on return values, confirmation, or error cases. The description is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only hints that itemId is a saved link/note and topicId is a topic, but provides no format, constraints, or examples.
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 'Attach' and identifies the resources (topic to saved link/note). It clearly distinguishes from the sibling 'remove_topic_from_save'. However, it could be more explicit that 'itemId' refers to a saved link or 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 on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a URL to Memlane (background enrichment: extract, embed, classify)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| projectId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses background enrichment processing, which adds behavioral context. However, it does not mention idempotency, rate limits, authentication requirements, or whether the operation is synchronous, leaving gaps.
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 that is efficient and front-loaded with the core action. It avoids unnecessary words, though it could be slightly more structured.
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?
No output schema is provided, and the description does not explain return values or side effects. Background enrichment is mentioned but not elaborated (e.g., asynchronous behavior). Parameter descriptions are missing, making it 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 0%, so the description must compensate. It only implies the 'url' parameter via the action 'Save a URL' but does not describe 'projectId' at all. This fails to add meaningful semantics for all parameters.
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: 'Save a URL to Memlane' with a specific verb and resource. It also adds context about background enrichment (extract, embed, classify), distinguishing it from sibling tools like get_save or list_saves.
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 alternatives. Sibling tools like add_topic_to_save or create_note exist, but the description does not explain scenarios for choosing capture_url over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a markdown note in Memlane
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| projectId | No |
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 basic creation action without disclosing side effects, idempotency, authentication needs, or return behavior.
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 extremely concise (one short sentence), which is good, but it sacrifices clarity and completeness. It uses minimal words without being misleading.
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 has 3 parameters, no annotations, and no output schema, the description is incomplete. It does not cover required fields, optional field behavior, or what the tool returns.
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 adds no meaning to the parameters. It does not explain the format of 'title' or 'content', nor the purpose of 'projectId'. The param names alone are insufficient.
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 ('a markdown note in Memlane'), distinguishing it from siblings like update_note. However, it lacks detail about what Memlane is or any nuance.
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 alternatives. While the name implies creation, there are no explicit usage hints, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a saved link or note by id, optionally including full markdown content
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| includeContent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It indicates that the tool reads a single item and optionally includes full content, but omits details on side effects, permissions, rate limits, or return format, which are critical for safe invocation.
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 unnecessary words. It is front-loaded and efficiently conveys the core action and key option.
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 retrieval tool with no output schema, the description should at least mention the return structure or error cases. It only covers the input, leaving the agent uninformed about what to expect, which 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?
The description adds partial meaning to the includeContent parameter by linking it to 'full markdown content', but the id parameter is only described as 'by id' with no further detail. With 0% schema coverage, this provides some compensation but not enough for full clarity.
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 retrieves a saved link or note by ID, which is a specific action on a specific resource. It distinguishes from sibling tools like list_saves (listing all) and search_saves (searching), as it targets a single item by ID.
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 versus alternatives such as list_saves or search_saves. The description does not mention prerequisites or conditions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Memlane projects
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal description with no behavioral details such as pagination, permissions, or data scope. Without annotations, this is insufficient.
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?
Extremely concise single sentence, though it could be slightly more detailed without losing brevity.
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 adequate but lacks detail on return structure or data scope.
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?
No parameters exist, so the baseline of 4 is appropriate; no additional meaning needed.
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 states verb 'list' and resource 'projects', distinguishing it from sibling tools like list_saves and list_topics.
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 explicit guidance on when to use this tool versus alternatives, but the context of sibling tools makes the usage implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved links and notes, newest first
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| projectId | No | ||
| topicName | No | ||
| kind | No | ||
| status | No | ||
| q | No | Filter by title/summary text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions ordering ('newest first') but omits pagination details, response format, or any side effects. This is insufficient for an agent to understand tool behavior.
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, which is concise but lacks structure. It front-loads the purpose but omits critical details, making it too brief for the tool's complexity (7 parameters, no output schema). It could be improved with bullet points or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is far from complete. It does not explain filtering options, pagination via cursor, or the response structure. A more thorough description is needed for effective use.
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 7 parameters, but only 'q' has a description. The tool description does not explain any parameters beyond the schema. Since schema coverage is only 14%, the description fails to add meaning to the majority of parameters.
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 it lists saved links and notes with newest first ordering. However, it does not distinguish this tool from sibling tools like search_saves, list_projects, or list_topics, which could cause confusion for the agent.
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 such as search_saves for filtered searches or get_save for a single item. The description lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Memlane topics (general and project-scoped)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states a read operation (listing), but does not mention whether the result is paginated, ordered, or limited. For a list tool with no parameters, this lack of detail on cardinality or performance implications is a gap.
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 that is clear and to the point. It is appropriately concise for a simple list tool, though it could benefit from slightly more detail on the output.
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 low complexity (no parameters, no output schema, no annotations), the description is minimally adequate. However, it does not explain what constitutes a topic or how the results are structured, leaving some ambiguity for an AI 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 tool has zero parameters, and the schema coverage is 100%, so the description does not need to add parameter-level detail. It implicitly confirms that no parameters are needed to list all topics, which is sufficient.
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 (list) and the resource (Membrane topics) with a specific scope (general and project-scoped). It effectively communicates the tool's purpose, though it does not explicitly differentiate from sibling tools like add_topic_to_save, which are clearly different actions.
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 alternatives. The description does not mention when not to use it or suggest any prerequisites or context for choosing this tool over others like list_saves or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a topic from a saved link or note
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | ||
| topicId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but fails to mention idempotency, side effects, error conditions, or what happens if the topic is not currently attached. The minimal description leaves significant ambiguity.
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, which is concise, but it is too sparse and does not earn its place by providing necessary context. It is adequate in length but poor in informativeness.
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 involves modifying data with two parameters and no output schema, the description is insufficient. It does not mention the type of save (link or note), that the operation is specific to that save's topic list, or any return value after removal.
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 does not explain the meaning of 'itemId' or 'topicId'. The UUID format is present in the schema but no semantic context is added, leaving the agent to infer critical details.
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 'Remove' and clearly identifies the resource 'topic from a saved link or note', distinguishing it from the sibling tool 'add_topic_to_save'.
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 versus alternatives, or on prerequisites such as that the topic must already be attached to the save. The description lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over your saved links and notes in Memlane
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions 'semantic search' but omits details like response format, pagination, sorting, or rate limits. The agent lacks key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified. It is appropriately front-loaded but fails to include necessary details for effective usage.
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 severely incomplete. It does not explain return values, behavior, or edge cases, leaving the agent ill-equipped 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?
Schema coverage is 50% (query described, limit not). The description does not add meaning beyond the schema for limit. It should have explained the undocumented parameter or provided usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search', the resource 'saved links and notes', and the domain 'Memlane'. It distinguishes from sibling tools like list_saves and get_save by specifying semantic search over content.
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 alternatives such as list_saves or get_save. No mention of prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a note's title and/or markdown body
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| title | No | ||
| content | No |
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 does not disclose whether updates are incremental or replace existing fields, whether authorization is required, or what happens to omitted fields. The description only says 'Update' without elaboration.
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?
A single, concise sentence with no extraneous information. Efficiently communicates the core 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 no annotations, no output schema, and triple parameters, the description lacks crucial context: return value, behavior for omitted fields, error handling, and prerequisites. Notable gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds minimal meaning by mapping 'title' and 'markdown body' to the title and content parameters, but it does not explain formats (e.g., markdown syntax) or that 'id' is required. The added value is marginal.
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 states the verb 'Update' and the resource 'note', specifying the fields affected ('title and/or markdown body'). This distinguishes it from sibling tools like create_note (creation) and list_saves (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., create_note for new notes). No exclusion criteria or context hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action (capture, create, update, get, list, search, add/remove topic) on distinct resources (saves, notes, topics, projects). No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., capture_url, list_saves, remove_topic_from_save). No mixing of conventions.
With 10 tools covering core operations for save/note management, topic organization, and project listing, the count is well-scoped and appropriate for the server's purpose.
Notable gaps: no delete tool for saves/notes, no create or update tools for topics or projects. The surface covers basic CRUD for notes and saves but misses lifecycle operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danii1/memlane-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
