The NoteDiscovery MCP server enables AI assistants to fully manage a self-hosted knowledge base across several capability areas:
Search & Discovery
Full-text search across all notes with snippet previews and pagination
List all notes with metadata (title, path, last modified, size)
Get recently modified notes within a configurable time window
List all tags with note counts; filter notes by a specific tag
Reading & Navigation
Read the full markdown content and metadata of any specific note
Retrieve the knowledge graph (nodes + edges) showing note interconnections
Find all backlinks (notes that link to a specific note)
Creating & Editing
Create new notes or overwrite existing ones with markdown content
Append content to an existing note (with optional timestamp)
Move/rename notes to reorganize the knowledge base
Delete notes permanently
Create folders to structure the knowledge base
Templates
List available templates and preview their content
Create new notes from a template with automatic placeholder substitution (title, date, folder, etc.)
Server Management
Health check to verify server connectivity
Retrieve server configuration (app name, version, auth mode, enabled features)
NoteDiscovery is a lightweight, self-hosted note-taking application that puts you in complete control of your knowledge base. Write, organize, and discover your notes with a beautiful, modern interface—all running on your own server.
Related MCP server: brainMD
Privacy-conscious users who want complete control over their data
Developers who prefer markdown and local file storage
Knowledge workers building a personal wiki or second brain
Teams looking for a self-hosted alternative to commercial apps
Anyone who values simplicity, speed, and ownership
Feature | NoteDiscovery | Commercial Apps |
Cost | 100% Free | $xxx/month/year |
Privacy | Your server, your data | Their servers, their terms |
Speed | Lightning fast | Depends on internet |
Offline | Always works | Limited or requires sync |
Customization | Full control | Limited options |
No Lock-in | Plain markdown files | Proprietary formats |
🔒 Total Privacy - Your notes never leave your server
📴 No CDN Required - The app and its shared links serve every browser library locally, so they work on air-gapped networks — see documentation/THIRD_PARTY.md
🔐 Optional Authentication - Simple password protection for self-hosted deployments
💰 Zero Cost - No subscriptions, no hidden fees
🚀 Fast & Lightweight - Instant search and navigation
🎨 Beautiful Themes - Multiple themes, easy to customize
🔌 Extensible - Plugin system for custom features
📱 Responsive - Works on desktop, tablet, and mobile
📂 Simple Storage - Plain markdown files in folders
🧮 Math Support - LaTeX/MathJax for beautiful equations
📄 HTML Export & Print - Export notes as standalone HTML or print
🕸️ Graph View - Interactive visualization of connected notes
✏️ Drawing editor - In-app sketches as drawing-*.png next to your notes — see documentation/DRAWING.md
⭐ Favorites - Star your most-used notes for instant access
📑 Outline Panel - Navigate headings with click-to-jump TOC
🤖 AI Assistant Ready - MCP integration for Claude, Cursor & more
NoteDiscovery includes a built-in Model Context Protocol (MCP) server, letting AI assistants directly interact with your notes:
What AI Can Do | Example |
🔍 Search & Discover | "Find all my notes about Docker deployment" |
📝 Create & Edit | "Create a meeting notes template for tomorrow" |
📁 Organize | "Move all project notes to the archive folder" |
🏷️ Tag & Categorize | "List all notes tagged with #urgent" |
📊 Explore Connections | "Show me the knowledge graph of my notes" |
✍️ Append Ideas | "Add this thought to my daily journal" |
One-line setup for Cursor, Claude Desktop, and other MCP-compatible tools:
{
"mcpServers": {
"notediscovery": {
"command": "docker",
"args": ["run", "--rm", "-i", "-e", "NOTEDISCOVERY_URL=http://host.docker.internal:8000", "ghcr.io/gamosoft/notediscovery:latest", "python", "-m", "mcp_server"]
}
}
}💡 See MCP.md for complete setup instructions and all available tools.
🧪 Want a fully local setup with a bundled LLM? OLLAMA-STACK.md spins up NoteDiscovery + Ollama + Open WebUI with one command.
Linux/macOS:
mkdir -p notediscovery/data && cd notediscovery
docker run -d --name notediscovery -p 8000:8000 \
-v $(pwd)/data:/app/data \
ghcr.io/gamosoft/notediscovery:latestWindows (PowerShell):
mkdir notediscovery\data; cd notediscovery
docker run -d --name notediscovery -p 8000:8000 `
-v ${PWD}/data:/app/data `
ghcr.io/gamosoft/notediscovery:latestOpen http://localhost:8000 — done! 🎉
💡 Your notes are saved in
./data/. Themes, plugins, locales and default configuration values are included in the image.
Two docker-compose files are provided:
File | Use Case |
| Recommended - Uses pre-built image from GitHub Container Registry |
| For development - Builds from local source |
| Bundled local AI stack (NoteDiscovery + Ollama + Open WebUI) — see OLLAMA-STACK.md |
Option 1: Pre-built image (fastest)
Linux/macOS:
mkdir -p notediscovery/data && cd notediscovery
curl -O https://raw.githubusercontent.com/gamosoft/notediscovery/main/docker-compose.ghcr.yml
docker-compose -f docker-compose.ghcr.yml up -dWindows (PowerShell):
mkdir notediscovery\data; cd notediscovery
Invoke-WebRequest -Uri https://raw.githubusercontent.com/gamosoft/notediscovery/main/docker-compose.ghcr.yml -OutFile docker-compose.ghcr.yml
docker-compose -f docker-compose.ghcr.yml up -dOption 2: Build from source (for development)
git clone https://github.com/gamosoft/notediscovery.git
cd notediscovery
docker-compose up -dSee Advanced Docker Setup for volume details.
For development or if you prefer running directly:
# Clone the repository
git clone https://github.com/gamosoft/notediscovery.git
cd notediscovery
# Install dependencies
pip install -r requirements.txt
# Run the application
python run.py
# Access at http://localhost:8000Requirements:
Python 3.8 or higher
pip (Python package manager)
Modern Linux distributions enforce PEP 668, which prevents system-wide pip installs. Use a virtual environment instead:
# Clone the repository
git clone https://github.com/gamosoft/notediscovery.git
cd notediscovery
# Create a virtual environment
python -m venv venv
# Activate it (choose your shell):
source venv/bin/activate # Bash/Zsh (most Linux distros)
source venv/bin/activate.fish # Fish (CachyOS, etc.)
source venv/bin/activate.csh # Csh/Tcsh
.\venv\Scripts\activate # Windows PowerShell
# Install dependencies and run
pip install -r requirements.txt
python run.py⚠️ Warning
You'll need to activate the virtual environment (source venv/bin/activate) each time you open a new terminal before running the app
The image includes bundled config, themes, plugins, and locales. To customize, you must:
Map the volume in your docker-compose or docker run command
Provide content - the file/folder must exist with valid content (empty = app might break!)
Volume | Purpose | Bundled? |
| Your notes | ❌ You must create |
| App settings | ✅ Yes |
| Custom themes | ✅ Yes |
| Custom plugins | ✅ Yes |
| Translations | ✅ Yes |
An official icon for NoteDiscovery is now available on Dashboard Icons!
Use it in your self-hosted dashboards like Homepage, Homarr, Dashy, Heimdall, etc...
Want to learn more?
🎨 THEMES.md - Theme customization and creating custom themes
✨ FEATURES.md - Complete feature list and keyboard shortcuts
✏️ DRAWING.md - Built-in drawing editor (drawing-*.png), save behavior, and API notes
🏷️ TAGS.md - Organize notes with tags and combined filtering
📋 TEMPLATES.md - Create notes from reusable templates with dynamic placeholders
🧮 MATHJAX.md - LaTeX/Math notation examples and syntax reference
📊 MERMAID.md - Diagram creation with Mermaid (flowcharts, sequence diagrams, and more)
🔌 PLUGINS.md - Plugin system and available plugins
🧩 plugins/contrib/ - Optional community plugins and how to install them
🌐 API.md - REST API documentation and examples
🤖 MCP.md - AI assistant integration (Claude, Cursor, and more)
🔐 AUTHENTICATION.md - Enable password protection for your instance
🔧 ENVIRONMENT_VARIABLES.md - Configure settings via environment variables
📦 THIRD_PARTY.md - Locally hosted browser libraries, licences, and how to update them
NoteDiscovery supports multiple interface languages via JSON locale files in locales/. Open Settings (gear icon) → Language to choose one; the list reflects whatever locales are installed (bundled files, mounts, or your own additions).
To add your own language: See the Contributing Guidelines for instructions on creating translation files.
Docker users: Mount your custom locales folder to add or override translations:
volumes:
- ./locales:/app/locales # Custom translations💡 Pro Tip: If you clone this repository, you can mount the documentation/ folder to view these docs inside the app:
# In your docker-compose.yml
volumes:
- ./data:/app/data # Your personal notes
- ./documentation:/app/data/docs:ro # Mount docs subfolder inside the data folder (read-only)Then access them at http://localhost:8000 - the docs will appear as a docs/ folder in the file browser!
Before submitting a pull request, especially for major changes, please:
Read our Contributing Guidelines
Open an issue first to discuss major features or significant changes
Ensure your code follows the project's style and philosophy
NoteDiscovery is designed for self-hosted, private use. Please keep these security considerations in mind:
⚠️ Do NOT expose directly to the internet without additional security measures
Run behind a reverse proxy (nginx, Caddy) with HTTPS for production use
Keep it on your local network or use a VPN for remote access
By default, the app listens on 0.0.0.0:8000 (all network interfaces)
Password protection is DISABLED by default (default password: admin)
⚠️ ENABLE AUTHENTICATION AND CHANGE THE DEFAULT PASSWORD if exposing to a network!
See AUTHENTICATION.md for complete setup instructions
To disable auth, set authentication.enabled: false in config.yaml
Perfect for single-user or small team deployments
For multi-user setups, consider a reverse proxy with OAuth/SSO
Your notes are stored as plain text markdown files in the data/ folder
No data is sent to external services
Regular backups are recommended
Run on localhost or a private network only
Use Docker for isolation and easier security management
Keep your system and dependencies updated
Review and audit any plugins you install
Set appropriate file permissions on the data/ directory
TL;DR: Perfect for personal use on your local machine or home network. Enable built-in password protection if needed, or use a reverse proxy with authentication if exposing to wider networks.
MIT License - Free to use, modify, and distribute.
Made with ❤️ for the self-hosting community
Append content to an existing note without overwriting. Perfect for journals, logs, meeting notes, or collecting ideas incrementally.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the existing note | |
| content | Yes | Content to append to the note | |
| add_timestamp | No | Whether to add a timestamp header before the appended content (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'without overwriting' as a key behavior, but lacks details on error handling (e.g., if path doesn't exist), return value, and does not elaborate on the add_timestamp parameter beyond the schema. Without annotations, more behavioral context would be helpful.
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?
Two sentences, front-loaded with the core action and purpose, no unnecessary words 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 simplicity of the tool (3 params, no output schema), the description covers the main use and behavior. It could mention success/error responses but is largely sufficient.
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 parameters are well-documented in the schema. The description adds minimal extra meaning beyond 'without overwriting' and the use cases.
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 (append), resource (note), and key behavior (without overwriting). It distinguishes from siblings like create_note and delete_note, and provides specific use cases (journals, logs, meeting 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?
It provides context by listing ideal use cases (journals, logs, etc.), implying when to use. However, it lacks explicit when-not-to-use instructions or alternatives for overwriting, which could be inferred from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new folder for organizing notes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path for the new folder (e.g., 'projects/2024') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as whether the folder can overwrite existing structures, required permissions, or side effects. The description is too brief to inform the agent of potential impacts.
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 with no wasted words. It is appropriately concise for a simple tool, though could benefit from slight elaboration without becoming 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 simplicity of the tool (one parameter, no output schema, no annotations), the description is incomplete. It fails to address behavior on duplicate paths, return value, or success/failure conditions, which are needed for a creation action.
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 100% coverage with a description for the 'path' parameter. The tool description adds no additional meaning beyond what the schema already states, so it meets the baseline but does not enhance understanding.
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 (folder), with a specific purpose (organizing notes). It distinguishes from sibling tools like create_note or create_note_from_template, which operate on notes rather than folders.
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 create_note or get_backlinks. The description lacks context for decision-making, like prerequisites or scenarios where folder creation is appropriate.
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 or update an existing one. The note will be saved as a markdown file. Use this to save new information or update existing notes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path for the note (e.g., 'folder/new-note.md'). Include .md extension. | |
| content | Yes | Markdown content for the note |
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 discloses that notes are saved as markdown files, but lacks details on idempotency, side effects (e.g., overwriting existing files), or prerequisites. For a tool that can both create and update, more behavioral context is needed.
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?
Two sentences with no redundancy. Front-loaded with the core action and format, then usage guidance. Every sentence contributes value without waste.
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 low complexity (2 simple parameters, no output schema, no nested objects), the description sufficiently covers its purpose and format. However, it could mention the return value or confirmation behavior for completeness.
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?
Although schema coverage is 100%, the description adds value by specifying the path pattern (including .md extension) and that the content is markdown. This extra context helps the agent understand parameter expectations beyond 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 'Create a new note or update an existing one,' specifying the verb (create/update) and resource (note). It distinguishes from siblings like append_to_note and create_note_from_template by mentioning both actions, though it could be more explicit about when to use each.
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 'Use this to save new information or update existing notes,' which implies usage but does not provide explicit when-not-to-use or alternatives. With siblings like append_to_note, more guidance on choosing between create/update vs append would improve clarity.
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 from a template. Built-in placeholders like {{title}}, {{date}}, {{datetime}}, {{folder}}, {{date:FMT}} are substituted automatically (FMT is a Python strftime string). Use update_note afterwards if you need to inject custom content.
| Name | Required | Description | Default |
|---|---|---|---|
| note_path | Yes | Path for the new note (e.g., 'meetings/2024-03-13.md') | |
| template_name | Yes | Name of the template to use (e.g., 'meeting-notes', 'daily-journal') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the placeholder substitution behavior and the syntax for custom date formats. It doesn't mention error handling (e.g., if template doesn't exist) or output details, but the core behavior is well-covered.
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?
Two sentences, front-loaded with the purpose, and every sentence provides useful information. No unnecessary words 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?
The description covers the main functionality but lacks details about the return value (path of created note?), what happens if the template doesn't exist, or whether the note path must not already exist. With no output schema, these gaps reduce completeness.
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% with descriptions for both parameters. The description adds value by explaining the automatic placeholder substitution and the '{{date:FMT}}' syntax, which goes beyond 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 'Create a new note from a template' with a specific verb and resource. It distinguishes from siblings like 'create_note' and 'update_note' by highlighting the template-based creation and the follow-up step for custom 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?
The description provides guidance on when to use this tool (for template-based creation) and when to use 'update_note' for custom content. However, it doesn't explicitly mention alternatives like 'list_templates' for finding available templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a note permanently. Use with caution - this cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the note to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses irreversibility, which is key, but does not mention error handling (e.g., if note doesn't exist) or required permissions. Acceptable for a simple 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?
Two concise sentences with zero fluff. The warning is front-loaded and effective. Every word serves a purpose.
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 only one parameter, no output schema, and a simple operation, the description is mostly complete. It could mention idempotency or behavior on missing path, but the warning suffices for core usage.
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% and the parameter 'path' is described as 'Path to the note to delete' in the schema. The description adds no extra meaning beyond that, so baseline score of 3.
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 'Delete a note permanently' with a specific verb and resource. Distinguishes from siblings like move_note or create_note by emphasizing permanence and irreversibility.
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?
Includes the warning 'Use with caution - this cannot be undone', advising caution but not explicitly contrasting with alternatives (e.g., moving to trash). For a permanent delete, the warning is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all notes that link TO a specific note (backlinks/reverse links). Use this to discover what other notes reference the current note, helping understand its importance and connections in the knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the note to find backlinks for (e.g., 'folder/note.md' or 'note.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only nature, pagination, rate limits, or response format. Only states the basic 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?
Two sentences with no wasted words. Front-loaded with purpose, followed by usage guidance. Optimal length for a simple tool.
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 (one parameter, no output schema), the description adequately explains what it does and when to use it. Lacks detail on return format but is sufficient for an agent to select and invoke.
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 one parameter 'path' already described well. The tool description does not add any additional meaning beyond the schema for this parameter.
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 'Get all notes that link TO a specific note (backlinks/reverse links)' with specific verb and resource. It distinguishes from sibling tools like get_note or search_notes by focusing on backlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this to discover what other notes reference the current note, helping understand its importance and connections.' No exclusions or alternatives mentioned, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NoteDiscovery server configuration: app name, version, whether search is enabled, authentication mode, autosave delay. Useful for confirming what server you're connected to and what features are available before calling other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the returned fields (app name, version, etc.), implying a read-only operation. No side effects are mentioned, which is acceptable for a getter. The description is transparent about the data returned.
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 long, with the first listing the tool's purpose and the second providing usage guidance. It is concise, front-loaded, and contains no unnecessary words.
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 zero parameters and no output schema, the description is complete: it states what the tool does and when to use it. It could mention that no parameters are needed, but the empty schema makes that obvious.
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 is empty, so schema coverage is 100%. The description adds value by listing the specific configuration fields returned, which goes beyond the schema's minimal information.
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 that the tool retrieves the server configuration with specific fields like app name, version, and search status. It distinguishes itself from sibling tools, which are all about notes and folders, making it the only config-related 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?
The description provides clear context: use this tool to confirm the server and available features before calling other tools. It does not explicitly state when not to use it, but the guidance is straightforward for a simple configuration retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the knowledge graph showing relationships between notes. Returns nodes (notes) and edges (links between them). Use this to understand how notes connect to each other.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return structure (nodes and edges), but with no annotations, the description carries full burden. Does not mention performance implications, read-only nature, or scope of the graph (e.g., all notes or active note). Adequate for a simple read 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?
Two sentences, no wasted words. Action verb 'Get' front-loaded, directly followed by return description and usage guidance. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema or annotations, the description covers the key purpose and return format. Could mention scope (e.g., 'for all notes') but not required. Adequately 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?
No parameters exist, and schema coverage is 100%. Description adds no parameter info, but baseline for 0 params is 4. No further semantic value 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 the tool retrieves the knowledge graph showing relationships between notes, specifying return of nodes and edges. Distinguishes from siblings like get_backlinks (which gives backlinks) and search_notes (search functionality).
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?
Implies usage ('Use this to understand how notes connect to each other') but lacks explicit when-to-use vs alternatives, such as when get_backlinks or search_notes would be more appropriate. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content of a specific note by its path. Returns the complete markdown content along with metadata. Use this after finding a note via search or list to read its contents.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the note (e.g., 'folder/note.md' or 'note.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it reads content and returns markdown with metadata (non-destructive), but does not mention error handling or permissions, which is adequate for a simple read 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?
Two concise sentences, no fluff, front-loaded with the core action. Efficient and easy to parse.
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 read tool with no output schema, the description fully covers purpose, usage, and return type. No 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% with a clear description for the 'path' parameter. The description adds no extra semantics beyond the schema, earning a baseline score of 3.
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 it reads a note's full content and metadata by path. It distinguishes itself from sibling tools like search_notes and list_notes by specifying it is used after finding 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?
Explicitly advises to use this tool after finding a note via search or list, providing clear when-to-use guidance and implying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all notes that have a specific tag. Use this to find related notes on a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name (without the # symbol) | |
| limit | No | Maximum number of notes to return. Useful for large vaults. If not specified, returns all matches. | |
| offset | No | Number of notes to skip. Use with limit for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the purpose. It fails to disclose behavioral traits such as whether notes are returned sorted, performance implications, or any side effects.
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 no redundant information. It is front-loaded with the core purpose and usage suggestion, making it easy to parse.
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 that there is no output schema and the tool returns notes, the description should have explained what fields are returned or how results are ordered. It lacks these details, leaving the agent with incomplete expectations.
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 schema already documents all parameters. The description adds no additional meaning beyond restating the purpose, 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 the verb 'Get' and resource 'notes by tag', distinguishing it from sibling tools like search_notes and list_notes. It specifically filters by tag, which is unique among siblings.
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 'Use this to find related notes on a topic' which implies a usage scenario, but it does not provide explicit guidance on when not to use it or compare it with alternatives like search_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently modified notes. Useful for finding what you were working on recently.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Get notes modified in the last N days (default: 7) | |
| limit | No | Maximum number of notes to return (default: 10) |
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 read operation ('Get...') but does not disclose ordering (e.g., by modification time descending), return format fields, or any side effects. The behavior is simple but could be more explicit.
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 at two sentences with no wasted words. It is front-loaded with the core function and immediately gives a usage hint.
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 and good schema coverage, the description is nearly complete, but it lacks details about the return format (e.g., fields, sorting). This is a minor gap for a list tool without an 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?
Schema coverage is 100% with descriptions for both 'days' and 'limit' parameters. The description adds no extra meaning 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 'Get recently modified notes', specifying a distinct verb and resource. Compared to sibling tools like get_note (single note), get_notes_by_tag, and search_notes, this tool's purpose is uniquely identified by the recency criterion.
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 usage context: 'Useful for finding what you were working on recently.' It implies appropriate use cases but does not explicitly mention when not to use or suggest alternatives like get_notes_by_tag for tag-based queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the content of a specific template. Use this to see what a template contains before using it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with no side effects, which is appropriate for a getter. Given no annotations, it adequately covers the behavioral traits needed for agent decision-making, though it could explicitly state it does not modify resources.
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 only two sentences, front-loaded with the core purpose, and every sentence adds value without 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?
For a simple tool with one parameter and no output schema, the description is largely sufficient. It could be improved by briefly noting the return format (e.g., template content as a string), but the current text provides enough context for correct invocation.
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 baseline is 3. The description does not add extra meaning to the 'name' parameter beyond what the schema provides ('Template name'). No further semantic enrichment is 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?
The description clearly states the action ('Get the content') and the resource ('a specific template'), and it effectively distinguishes from siblings like 'list_templates' (which lists) and 'create_note_from_template' (which creates).
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 states when to use the tool ('see what a template contains before using it'), providing clear context and implied exclusions (e.g., not for listing or creating templates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if NoteDiscovery server is running and healthy. Use this to verify connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read-only check but doesn't detail response format or potential error states.
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?
Two concise sentences, front-loaded with purpose and usage guidance. No unnecessary information.
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?
Complete for a simple health check with no parameters or output schema. Could mention network dependency or response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description adds value by clarifying the purpose beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks server health and connectivity, which is distinct from sibling tools that modify or query 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?
States 'Use this to verify connectivity', providing clear context. Could mention when not to use, but health checks have no natural alternatives among siblings.
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 the knowledge base with their metadata (title, path, last modified date, size). Use this to get an overview of available notes or find notes by browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of notes to return. Useful for large vaults. If not specified, returns all notes. | |
| offset | No | Number of notes to skip. Use with limit for pagination. |
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 mentions the returned metadata but does not discuss default behavior (all notes returned) or pagination details. The schema covers pagination, but the description adds little beyond that.
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, front-loaded with the action and then the use case. It is concise and efficient, though slightly more structure could improve readability.
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 output schema, the description helpfully lists the returned metadata. However, it does not mention default behavior, pagination, or differentiate from siblings like 'get_notes_by_tag'. Adequate for a simple listing tool 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?
Schema coverage is 100% with clear parameter descriptions for limit and offset. The tool description does not add any extra 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 specifies the verb 'list' and the resource 'all notes in the knowledge base', and states the metadata returned (title, path, last modified date, size). This distinguishes it from siblings like 'search_notes' and 'get_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?
The description provides usage context: 'Use this to get an overview of available notes or find notes by browsing.' It does not explicitly mention when not to use it or alternatives, but the purpose is clearly indicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags used across notes with the count of notes for each tag. Use this to understand how notes are organized and find topics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully describes a safe, read-only operation returning tags with counts. No surprises.
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?
Two clear, front-loaded sentences. First sentence core action, second usage context. No fluff.
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?
Complete for a parameterless tool: tells what it does, what it returns (tags with counts), and why to use it. No output schema, but description fills 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?
No parameters exist, schema coverage is 100%. Description adds no parameter details, but baseline for 0 params is 4.
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 states specific verb 'List' and resource 'tags', with additional detail about count of notes per tag, distinguishing it from siblings like get_notes_by_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use case: 'understand how notes are organized and find topics'. No explicit when-not-to-use, but clear context given no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available note templates. Templates provide pre-formatted structures for common note types.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it lists templates. It does not disclose any behavioral traits such as auth requirements, performance characteristics, or whether it returns full template objects or just metadata.
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 long, with the first sentence conveying the primary action and the second adding context. No extraneous information.
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 tool with no parameters and no output schema, the description is adequate but does not clarify what information is returned in the list (e.g., template names, IDs) or how templates are organized.
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 details. Baseline score of 4 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 lists available note templates, which distinguishes it from siblings like get_template. However, it could be more specific about the scope (e.g., all user templates vs. system templates).
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 like get_template. An agent might not know to use list_templates to discover templates before creating notes from them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move or rename a note to a different path. Use this to reorganize notes or rename them.
| Name | Required | Description | Default |
|---|---|---|---|
| new_path | Yes | New path for the note (can be in a different folder) | |
| old_path | Yes | Current path of the note |
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 side effects (e.g., whether the old note is deleted) or permissions required. Only basic action is 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?
Two sentences, no wasted words. Front-loaded with action and use case.
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 tool with two string params and no output schema, the description is adequate but minimal. It lacks details on behavior after move (e.g., old note status).
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 adds no extra semantics beyond the schema's parameter descriptions.
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 function: move or rename a note. The verb 'move' and 'rename' are specific and distinct from siblings like create_note or delete_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?
The description says to use for reorganizing or renaming, but does not provide explicit when-not-to-use or alternatives. It is implied for these use cases but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through all notes using full-text search. Returns matching notes with snippets showing where the match was found. Use this to find notes by content, keywords, or phrases.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Useful for large vaults. If not specified, returns all matches. | |
| query | Yes | Search query. Can be keywords, phrases, or natural language. | |
| offset | No | Number of results to skip. Use with limit for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description covers return format (snippets) and purpose. Does not disclose behavior like case sensitivity, indexing, or performance for large vaults. Adequate but not comprehensive.
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?
Three concise sentences, no fluff, well-structured. All information is relevant and front-loaded.
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 output schema, description adequately covers purpose, parameters, and return format (snippets). Lacks mention of pagination behavior with offset/limit, but schema covers that. Fairly complete for a search tool.
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 schema already explains parameters fully. Description adds minor clarification for 'query' (can be natural language) but does not add significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb (search) and resource (notes) with method (full-text search) and outcome (returns matching notes with snippets). Clearly distinguishes from sibling tools like list_notes or get_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?
Explicitly states when to use: 'Use this to find notes by content, keywords, or phrases.' However, does not provide when-not-to-use or mention alternatives like list_notes for navigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: note creation and update (create_note, append_to_note, create_note_from_template), deletion, retrieval, search, listing, tags, backlinks, graph, templates, folders, configuration, and health check. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_note, get_note, list_notes, search_notes). The naming is predictable and easy to understand.
With 18 tools, the server covers all essential note-taking operations without being bloated. The count is well-scoped for a complete knowledge management system.
The tool surface covers full CRUD (create, read, update, delete), search, tagging, backlinks, graph visualization, templates, folder management, and server configuration. There are no obvious gaps for typical note-taking workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gamosoft/NoteDiscovery'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
