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., "@wiznote-mcp search for meeting notes from last week"
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.
Use WizNote as your doc source of truth in Claude-driven development.
English | 简体中文
wiznote is a public, privacy-safe Claude skill and Python helper set for developers who want a lightweight documentation workflow: private WizNote deployment, repo-local mirrors, and Claude-friendly operations in one package.
It is built for personal developers and small teams doing vibe coding, where plans, notes, specs, and implementation context need to stay close to the code without introducing a heavy documentation platform.
Private by default — connect to your own WizNote deployment instead of moving docs into a public SaaS workspace
Claude-friendly workflow — pair the same doc system with Claude Code and adjacent desktop, web, or IDE-centered repo workflows
Cross-end continuity — write or sync on one surface, continue from another, and keep the same documentation source of truth
Built for personal or small-team vibe coding — keep docs, plans, and implementation notes tightly coupled to the codebase
Repo mirrors included — keep WizNote as canonical while preserving code-adjacent Markdown copies in docs/wiznote-mirror/...
This package is derived from a private internal workflow, but all user-specific paths, hosts, credentials, and organization-specific folder mappings have been removed.
Related MCP server: Evernote MCP Server
Added a local stdio MCP adapter for existing WizServer deployments.
Added tools for folder creation, note search/read, and note create/update workflows.
Added the wiznote-mcp package entrypoint and generic MCP configuration docs.
Full history: docs/releases/release-notes.md
SKILL.md — the Claude Code skill definition
wiznote_cli.py — login, list, download, create, and update note helpers
wiznote_helper.py — category validation, mirror-path generation, and HTML body extraction helpers
wiznote_mcp.py — local stdio MCP adapter that calls an existing WizServer HTTP API
tests/ — pytest coverage for the publicized helper and CLI behavior
Log in to a WizNote server with explicit credentials or environment variables
Use WizNote through a local MCP server without running another Docker container
List notes under a configurable category root
Create WizNote folders/categories
Search notes
Download note HTML
Create new notes from generated HTML
Update existing notes
Mirror notes into docs/wiznote-mirror/... safely
Validate category paths so sync stays inside your chosen root
Support Unicode note titles for mirror filenames
Python 3.11+ recommended
A reachable WizNote server
Optional Python packages depending on your workflow:
markdown for Markdown → HTML conversion
pytest for running the included tests
Copy this directory to your Claude skills directory:
mkdir -p ~/.claude/skills
cp -R ./wiznote ~/.claude/skills/wiznoteYou can also keep wiznote/ inside your repo and import the Python files directly in your own scripts.
Set these environment variables:
export WIZNOTE_BASE_URL="https://notes.example.com"
export WIZNOTE_USER="you@example.com"
export WIZNOTE_PASSWORD="your-password"You also need two runtime values in your scripts:
category_root — the top-level WizNote category you want to sync under, for example /team/docs/
repo_root — the local repository root used for mirror output
wiznote_mcp.py is a stdio MCP server. It does not require a separate Docker container and does not modify your existing WizServer deployment. The MCP process connects directly to the existing WizServer HTTP API.
Example MCP configuration:
{
"mcpServers": {
"wiznote": {
"command": "python3",
"args": [
"/path/to/wiznote/wiznote_mcp.py",
"--base-url",
"http://127.0.0.1:18080",
"--username",
"you@example.com",
"--password",
"your-password"
]
}
}
}If your MCP client keeps secrets in environment variables, omit the arguments and set WIZNOTE_BASE_URL, WIZNOTE_USER, and WIZNOTE_PASSWORD instead.
Available MCP tools:
wiz_create_folder — create a WizNote category/folder
wiz_list_notes — list notes in a category/folder
wiz_search_notes — search notes
wiz_get_note — read note metadata and HTML body
wiz_create_note — create a note from HTML or basic Markdown
wiz_update_note — update an existing note from HTML or basic Markdown
The MCP adapter writes through WizServer APIs only. It does not write directly to MySQL or /wiz/storage, so WizServer still owns permissions, versions, object data, and indexing.
from pathlib import Path
import sys
SKILL_DIR = Path("/path/to/wiznote")
sys.path.insert(0, str(SKILL_DIR))
import wiznote_cli as cli
import wiznote_helper as helpercreds = cli.load_credentials()
login = cli.login(creds)Or pass credentials explicitly:
creds = cli.load_credentials(
base_url="https://notes.example.com",
user="you@example.com",
password="your-password",
)
login = cli.login(creds)category_root = helper.normalize_category_root("/team/docs/")
category = helper.resolve_category(category_root, "plans/")payload = cli.fetch_note_list(
base_url=login.kb_server,
kb_guid=login.kb_guid,
token=login.token,
category=category,
)html = "<h1>Project Design</h1><p>...</p>"
result = cli.create_note(
base_url=login.kb_server,
kb_guid=login.kb_guid,
token=login.token,
title="Project Design",
category=category,
html=html,
)mirror_path = helper.mirror_output_path(
repo_root=Path("/path/to/repo"),
category_root=category_root,
category=category,
title="Project Design",
)Configure credentials
Normalize the category root
Log in once and reuse the session
Resolve the exact target category
List notes before writing
Convert Markdown to HTML
Create or update the note in WizNote first
Refresh the local mirror second
Re-list the category to verify the write
create_note(...) and save_note(...) expect HTML, not raw Markdown.
Example:
python3 -m pip install markdownimport markdown
html = markdown.markdown(text, extensions=["extra", "fenced_code", "tables", "sane_lists"])python3 -m pip install pytest
pytest wiznote/testsThis public version intentionally avoids:
hardcoded home directories
private server addresses
usernames or passwords
organization-specific project folder mappings
If you fork or modify it, keep your published copy free of private infrastructure details.
wiznote/
├── README.md
├── README.zh-CN.md
├── SKILL.md
├── wiznote_cli.py
├── wiznote_helper.py
├── wiznote_mcp.py
└── tests/
├── conftest.py
├── test_cli.py
└── test_helper.pyMIT. See LICENSE.
Create a WizNote category/folder path.
| Name | Required | Description | Default |
|---|---|---|---|
| kbGuid | No | ||
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Create', which implies mutation, but fails to disclose idempotency, side effects, or error conditions (e.g., if folder already exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but at the cost of completeness. Lacks structure such as separate sections or bullet points; every word is present but insufficient.
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 minimal description for a 2-parameter tool, the agent lacks critical context for correct invocation. Severely underdescribed.
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 description does not explain parameters. 'kbGuid' and 'category' are undefined; agent cannot infer their meaning or format.
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 verb 'Create' and resource 'WizNote category/folder path', distinguishing from sibling tools that deal with notes. However, 'category/folder path' is somewhat ambiguous and could be more precise.
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, no prerequisites or exclusions. The sibling tools are mostly for notes, implying it's for folders, but that's implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a note from HTML or Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | ||
| title | Yes | ||
| kbGuid | No | ||
| category | Yes | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks information on behavioral traits such as whether the tool overwrites existing notes, authorization requirements, or rate limits. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it may be too brief, sacrificing essential detail for 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?
Given the tool has 5 parameters and no output schema or annotations, the description is incomplete. It fails to explain key aspects like parameter usage, return values, or constraints (e.g., mutual exclusivity of html and markdown).
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 minimal parameter information. It mentions HTML and Markdown but does not explain the purpose of parameters like kbGuid, category, or the relationship between html and markdown.
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 resource (note) and specifies input formats (HTML or Markdown). It distinguishes the tool from siblings like wiz_create_folder and wiz_get_note by the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., wiz_update_note, wiz_search_notes). It does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read note metadata and HTML body.
| Name | Required | Description | Default |
|---|---|---|---|
| kbGuid | No | ||
| docGuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only mentions that the tool reads data. It does not confirm safe/read-only behavior, idempotency, or any side effects. The term 'read' weakly implies non-destructiveness, but lacks explicit authorization or error-context disclosure.
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?
While the description is short, it sacrifices informativeness for brevity. It does not earn its place as the sole explanatory text for a two-parameter tool; essential details are omitted.
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 should hint at return structure or context like metadata fields. It also fails to differentiate retrieval of a single note from listing/searching, and omits parameter explanations. Overall, it is under-specified for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It fails to mention either 'docGuid' or 'kbGuid', leaving their roles completely undocumented. The agent cannot infer what each parameter represents or how to use them correctly.
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 ('Read') and the resource ('note metadata and HTML body'), distinguishing it from sibling tools that create, list, search, or update notes. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wiz_search_notes or wiz_list_notes. The description simply states what it does, leaving the agent to infer appropriate usage without any contextual help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes in a WizNote category/folder.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| start | No | ||
| kbGuid | No | ||
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should thoroughly disclose behavior, but it only states the basic action. It does not mention pagination, ordering, or limitations implied by parameters like count and start.
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, front-loaded with the key action. It is not verbose, but could include more detail without losing conciseness.
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 4 parameters and no output schema or annotations, the description is insufficient. It does not explain pagination behavior, return format, or the role of kbGuid.
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 fails to explain the purpose of count, start, kbGuid, or category beyond the obvious.
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 'list' and the resource 'notes in a WizNote category/folder', indicating a specific action. However, it does not distinguish from sibling tools like wiz_search_notes, lacking differentiation.
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 wiz_search_notes or wiz_get_note. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes in a WizNote knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| query | Yes | ||
| start | No | ||
| kbGuid | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits like whether it returns full notes, snippets, or supports pagination. The schema hints at pagination via count and start, but these are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and concise but sacrifices necessary detail. It could have added parameter or behavior explanation without much length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient for proper tool understanding. It lacks explanation of pagination, return format, and the effect of optional parameters like kbGuid.
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%, yet the description adds no parameter explanations. While 'query' is self-explanatory, 'count', 'start', and 'kbGuid' are undocumented, leaving ambiguity for the agent.
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' and the resource 'notes' in a specific context. It distinguishes from sibling tools like create, list, get, and update. However, it lacks specificity on search type (e.g., full-text, title).
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 search versus sibling tools like wiz_list_notes or wiz_get_note. Without exclusions, the agent may misuse it for simple listing or retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing note from HTML or Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | ||
| title | Yes | ||
| kbGuid | No | ||
| docGuid | Yes | ||
| category | Yes | ||
| markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It states 'update' but gives no details on mutation effects, required permissions, or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but lacks essential information. Conciseness without completeness is not valuable.
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 6 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain how to use the tool or what the response contains.
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 only hints at 'html' and 'markdown' parameters but does not explain 'title', 'kbGuid', 'docGuid', or 'category'. Most parameters remain undefined.
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 specifies a clear verb 'Update' and resource 'existing note', distinguishing it from create/get/search sibling tools. However, it could be more explicit about the two content sources (HTML or Markdown) being alternative input formats.
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 like wiz_create_note or wiz_get_note. The description does not mention prerequisites or contexts where update is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0wiz_create_folderwiz_create_notewiz_get_notewiz_list_noteswiz_search_noteswiz_update_noteEach tool targets a unique operation: folder creation, note CRUD (except delete), listing, and searching. No overlaps in purposes.
All tools follow a consistent pattern: 'wiz_' prefix + verb_noun (e.g., create_folder, get_note). No mixing of conventions.
6 tools is well-scoped for a note-taking service, covering essential operations without unnecessary bloat.
Covers core note CRUD (create, read, update), listing, and search. Missing delete note and folder listing, but these are minor gaps for basic workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
Create, search and manage Knowtis collaborative notes from AI assistants.
AI access to your aNotepad online notes: read, search, write, and organize via 22 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/735140144/wiznote-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
