Skip to main content
Glama

Note Post MCP

GitHub

The Universal MCP Server exposes tools for automated posting and draft saving to note.com. It reads Markdown files containing titles, body text, and tags, then publishes them to your note.com account using Playwright automation.

Installation

Prerequisites

  • Node.js 18+

  • A note.com account

  • note-state.json authentication state file (obtained via npm run login)

  • Set NOTE_POST_MCP_STATE_PATH in your environment (optional, defaults to ~/.note-state.json)

Install from GitHub

git clone https://github.com/Go-555/note-post-mcp.git
cd note-post-mcp
npm install
npm run build

Install Playwright Browser

npm run install-browser

This installs the Chromium browser required for automation.

Get an authentication state file

Run the login script to authenticate with note.com:

npm run login

A browser window will open. Log in to note.com, then press Enter in the terminal. This creates a ~/.note-state.json file containing your authentication state. Store this file securely and reference it via NOTE_POST_MCP_STATE_PATH or pass it as a parameter.

Or install from npm (if published)

npm install -g note-post-mcp

Related MCP server: Local Knowledge Desk

Setup: Claude Code (CLI)

Use this one-liner (replace with your real values):

claude mcp add Note Post MCP -s user -e NOTE_POST_MCP_STATE_PATH="/path/to/note-state.json" -- npx @gonuts555/note-post-mcp@latest

To remove:

claude mcp remove Note Post MCP

Setup: Cursor

Create .cursor/mcp.json in your client (do not commit it here):

{
  "mcpServers": {
    "note-post-mcp": {
      "command": "npx",
      "args": ["@gonuts555/note-post-mcp@latest"],
      "env": {
        "NOTE_POST_MCP_STATE_PATH": "/path/to/note-state.json"
      },
      "autoStart": true
    }
  }
}

Other Clients and Agents

Install via URI or CLI:

code --add-mcp '{"name":"note-post-mcp","command":"npx","args":["@gonuts555/note-post-mcp@latest"],"env":{"NOTE_POST_MCP_STATE_PATH":"/path/to/note-state.json"}}'

Add to your Claude Desktop configuration file (claude_desktop_config.json):

{
  "mcpServers": {
    "note-post-mcp": {
      "command": "npx",
      "args": ["@gonuts555/note-post-mcp@latest"],
      "env": {
        "NOTE_POST_MCP_STATE_PATH": "/path/to/note-state.json"
      }
    }
  }
}
  • Command: npx

  • Args: ["@gonuts555/note-post-mcp@latest"]

  • Env: NOTE_POST_MCP_STATE_PATH=/path/to/note-state.json

  • Type: STDIO

  • Command: npx

  • Args: @gonuts555/note-post-mcp@latest

  • Enabled: true

Example ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "note-post-mcp": {
      "type": "local",
      "command": ["npx", "@gonuts555/note-post-mcp@latest"],
      "enabled": true,
      "env": {
        "NOTE_POST_MCP_STATE_PATH": "/path/to/note-state.json"
      }
    }
  }
}

Add a new MCP and paste the standard JSON config from above.

Add the following to your Windsurf MCP configuration:

{
  "note-post-mcp": {
    "command": "npx",
    "args": ["@gonuts555/note-post-mcp@latest"],
    "env": {
      "NOTE_POST_MCP_STATE_PATH": "/path/to/note-state.json"
    }
  }
}

Setup: Codex (TOML)

Add the following to your Codex TOML configuration.

Example (Serena):

[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]

This server (minimal):

[mcp_servers.note-post-mcp]
command = "npx"
args = ["@gonuts555/note-post-mcp@latest"]
# Optional environment variables:
# NOTE_POST_MCP_STATE_PATH = "/path/to/note-state.json"
# NOTE_POST_MCP_TIMEOUT = "180000"
# MCP_NAME = "note-post-mcp"

Configuration (Env)

  • NOTE_POST_MCP_STATE_PATH: Path to the note.com authentication state file (default: ~/.note-state.json)

  • NOTE_POST_MCP_TIMEOUT: Timeout in milliseconds for browser operations (default: 180000)

  • MCP_NAME: Server name override (default: note-post-mcp)

Available Tools

publish_note

Publishes an article to note.com from a Markdown file.

  • Inputs:

    • markdown_path (string, required): Path to the Markdown file containing title, body, and tags

    • thumbnail_path (string, optional): Path to the thumbnail image file

    • state_path (string, optional): Path to the note.com authentication state file

    • screenshot_dir (string, optional): Directory to save screenshots

    • timeout (number, optional): Timeout in milliseconds

  • Outputs: JSON object with:

    • success (boolean): Whether the operation succeeded

    • url (string): URL of the published article

    • screenshot (string): Path to the screenshot

    • message (string): Success message

save_draft

Saves a draft article to note.com from a Markdown file.

  • Inputs:

    • markdown_path (string, required): Path to the Markdown file containing title, body, and tags

    • thumbnail_path (string, optional): Path to the thumbnail image file

    • state_path (string, optional): Path to the note.com authentication state file

    • screenshot_dir (string, optional): Directory to save screenshots

    • timeout (number, optional): Timeout in milliseconds

  • Outputs: JSON object with:

    • success (boolean): Whether the operation succeeded

    • url (string): URL of the draft editor page

    • screenshot (string): Path to the screenshot

    • message (string): Success message

Markdown File Format

Your Markdown file should follow this format:

---
title: Your Article Title
tags:
  - tag1
  - tag2
---

Your article body content goes here.

You can include URLs and they will be automatically expanded by note.com.

Alternatively, you can use array notation for tags:

---
title: Your Article Title
tags: [tag1, tag2]
---

Your article body content goes here.

Or use a simple # heading for the title if no front matter is present:

# Your Article Title

Your article body content goes here.

Body Content Details

The body content supports the following Markdown elements:

Front Matter Format:

  • All lines after the closing --- of the front matter are treated as body content

  • Trailing blank lines are automatically trimmed

Heading Format:

  • The first line starting with # is treated as the title (not included in the body)

  • Headings with ## or ### are treated as part of the body content

Code Blocks:

  • Must have a closing fence (```)

  • Language specification is preserved

  • Entire code blocks are pasted as a unit

Image Insertion:

  • Use relative paths from the Markdown file: ![description](./images/sample.png)

  • Supports PNG, JPEG, and GIF formats

  • Local image files are automatically uploaded

Lists and Quotes:

  • Bullet lists (-) and numbered lists (1.) are automatically continued by note.com

  • Block quotes (>) are also automatically continued

  • Markdown symbols are processed automatically after the first line

Horizontal Rules:

  • --- in the body content is correctly processed as a horizontal rule

  • Blank lines immediately following horizontal rules are automatically skipped

URL Single Lines:

  • URLs on their own line are automatically expanded into link cards by note.com

  • YouTube and other embeds are also automatically processed

Example invocation (MCP tool call)

{
  "name": "publish_note",
  "arguments": {
    "markdown_path": "/path/to/article.md",
    "thumbnail_path": "/path/to/thumbnail.png",
    "state_path": "/path/to/note-state.json"
  }
}

For saving a draft:

{
  "name": "save_draft",
  "arguments": {
    "markdown_path": "/path/to/draft.md"
  }
}

Troubleshooting

  • Authentication errors: Ensure your note-state.json file is valid and up-to-date. You may need to regenerate it if your session has expired.

  • Ensure Node 18+: Run node -v to verify your Node.js version.

  • Build errors: Run npm install and npm run build to ensure all dependencies are installed and TypeScript is compiled.

  • Local runs: After building, test locally with npx note-post-mcp (it will wait for MCP messages on stdin).

  • Inspect publish artifacts: Run npm pack --dry-run to see what files will be included in the published package.

  • Timeout issues: If operations are timing out, increase NOTE_POST_MCP_TIMEOUT or pass a larger timeout parameter.

  • Playwright browser not installed: Run npm run install-browser or npx playwright install chromium to install the required browser.

References

Name Consistency & Troubleshooting

  • Always use CANONICAL_ID (note-post-mcp) for identifiers and keys.

  • Use CANONICAL_DISPLAY (Note Post MCP) only for UI labels.

  • Do not mix different names across clients.

Consistency Matrix

  • npm package name → note-post-mcp

  • Binary name → note-post-mcp

  • MCP server name (SDK metadata) → note-post-mcp

  • Env default MCP_NAME → note-post-mcp

  • Client registry key → note-post-mcp

  • UI label → Note Post MCP

Conflict Cleanup

  • Remove any old entries with different names and re-add with note-post-mcp.

  • Ensure global .mcp.json or client registries only use note-post-mcp for keys.

  • Cursor: Configure in the UI only. This project does not include .cursor/mcp.json.

Example

  • Correct: "mcpServers": { "note-post-mcp": { "command": "npx", "args": ["@gonuts555/note-post-mcp@latest"] } }

  • Incorrect: Using different keys like "NotePost" or "note_post" (will conflict with note-post-mcp)

License

MIT

Available Tools

2 tools
publish_noteA

note.comに記事を公開します。Markdownファイルからタイトル、本文、タグを読み取り、自動的に投稿します。

ParametersJSON Schema
NameRequiredDescriptionDefault
timeoutNoタイムアウト(ミリ秒、デフォルト: 180000)
state_pathNonote.comの認証状態ファイルのパス(デフォルト: ~/.note-state.json)
markdown_pathYesMarkdownファイルのパス(タイトル、本文、タグを含む)
screenshot_dirNoスクリーンショット保存ディレクトリ(オプション)
thumbnail_pathNoサムネイル画像のパス(オプション)

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries full burden. It only mentions reading from Markdown and automatically posting, but fails to disclose that authentication state is required (indicated by state_path), that screenshots may be taken, or that publishing is typically a one-way action. This leaves the agent unaware of prerequisites and 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is a single clear sentence that gets straight to the point without any filler, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters, no output schema, and no annotations. The description only covers the core publishing action and does not address authentication, handling of optional parameters, return values, or error conditions, leaving significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, so baseline is 3. The description adds context for markdown_path by specifying it contains title, body, and tags, but provides no additional semantics for state_path, screenshot_dir, thumbnail_path, or timeout beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it publishes an article to note.com by reading title, body, and tags from a Markdown file. This distinguishes it from the sibling save_draft, which is about saving rather than publishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly describes the tool's function of publishing from a Markdown file, providing context for when this tool is appropriate. However, it does not explicitly mention save_draft or list conditions for when not to use this tool, so it lacks explicit exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_draftB

note.comに下書きを保存します。Markdownファイルからタイトル、本文、タグを読み取り、下書きとして保存します。

ParametersJSON Schema
NameRequiredDescriptionDefault
timeoutNoタイムアウト(ミリ秒、デフォルト: 180000)
state_pathNonote.comの認証状態ファイルのパス(デフォルト: ~/.note-state.json)
markdown_pathYesMarkdownファイルのパス(タイトル、本文、タグを含む)
screenshot_dirNoスクリーンショット保存ディレクトリ(オプション)
thumbnail_pathNoサムネイル画像のパス(オプション)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behaviors. It only states the core action and does not mention authentication requirements, side effects such as overwriting existing drafts, or failure behaviors. This is insufficient for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two short sentences that directly convey the purpose without unnecessary detail. It is well-structured and front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has five parameters, no output schema, and no annotations, so the description must compensate by explaining return behavior, prerequisites, and edge cases. It provides none, leaving the agent without information on what the tool returns (e.g., success/failure, draft ID) or what is required for it to work (e.g., authentication). This is a significant gap for a write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so baseline is 3. The description mentions reading title, body, and tags from Markdown, which aligns with the markdown_path parameter definition but does not add significant extra meaning beyond what the schema already states. Other parameters (timeout, state_path, etc.) are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: saving a draft to note.com by reading content from a Markdown file. It specifies the resource (note.com), the action (save draft), and the input source (Markdown), which distinguishes it from the sibling tool 'publish_note' that likely publishes rather than saves drafts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a draft needs to be saved without publishing, but it does not explicitly mention when to use this tool versus the sibling 'publish_note' or any exclusions. No alternative tools or conditions are referenced, so guidance is only implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.7
    • First observedpublish_note
    • First observedsave_draft

TDQS

A3.8/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one publishes a note, the other saves a draft. There is no overlap in their actions, and their descriptions make the difference explicit.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern: publish_note and save_draft. The naming style is uniform and predictable, despite the second tool using 'draft' instead of 'note'.

Tool Count4/5

With only 2 tools, the server is slightly under the typical 3-15 range, but the scope is narrow and focused on posting content to note.com, so the count feels reasonable rather than overly thin.

Completeness4/5

The server covers the two primary content-creation actions: publishing and saving drafts. Minor gaps exist (e.g., no update or delete), but for the stated purpose of publishing from Markdown files, the surface is largely complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Go-555/note-post-mcp-v2'

If you have feedback or need assistance with the MCP directory API, please join our Discord server