Skip to main content
Glama
TaisukeAndo

note-mcp

by TaisukeAndo
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

note-mcp

自分の note.com アカウントに下書き記事を作成・更新するための MCP サーバーです。Claude Code や Claude Desktop などの MCPクライアントから、「noteに下書きを作って」といった依頼で記事を投稿できます。

note.com は記事投稿の公式APIを公開していません。本プロジェクトは、ブラウザの開発者ツールで 観測できる内部API（非公式）をセッションCookie経由で呼び出す実装です。 （参考: note.comの非公式API調査記事）

2つの実行方法

方法

使えるタイミング

セットアップ

① ローカル / Docker（stdio）

自分のPCが起動している間だけ

セットアップ（簡単）

② Cloudflare Workers（リモート）

PCの電源に関係なく常時

常時稼働させたい場合（要Cloudflareアカウント。mainへのpushでGitHub Actionsが自動デプロイ）

/schedule のようなクラウド上のスケジュール実行から呼び出したい場合、①のstdio版は 「Claude Codeがその場でローカルにサブプロセスを起動する」方式のため使えません （PCが起動していても、クラウド側のエージェントからはローカルのDockerに到達できません）。 その場合は②のCloudflare Workers版で常時稼働のURLを用意してください。

Related MCP server: notepm-mcp-server

⚠️ 免責事項

  • 非公式のAPIを利用しています。 note.com の仕様変更により、予告なく動作しなくなる 可能性があります。

  • note.com の利用規約に抵触しないか、利用者ご自身の責任で判断してください。

  • 本ソフトウェアは無保証で提供されます（LICENSE 参照）。作者は本ソフトウェアの 利用によって生じたいかなる損害についても責任を負いません。

  • 公開・タグ付け機能（note_publish_draft / タグ引数）は未確認のAPIに基づく実験的機能です。 下書きの作成・更新のみが動作確認済みです。詳しくは 既知の制限 を参照してください。

🔒 セキュリティについて

このリポジトリ・配布Dockerイメージ・Cloudflare Workersのコードには、個人の認証情報 （note.comのセッションCookie等）は一切含まれていません。 利用者ご自身のセッションCookieを、 ①は実行時の環境変数、②はCloudflare Secretsとして渡す必要があります （.env / .dev.vars はテンプレート（.env.example / .dev.vars.example）のみを コミット対象とし、実際の値を入れたファイルは .gitignore で除外されます）。 ②は/mcpエンドポイント自体もOAuth（Dynamic Client Registration対応）で保護されており、 ブラウザでのログイン（MCP_ACCESS_TOKENをパスワードとして入力）を経ないと接続できません。

必要なもの

  • Docker（推奨。環境を問わず動かせます）

  • または Node.js 22以上（Dockerを使わずローカル実行する場合。wranglerがNode 22以上を要求するため）

  • note.com のアカウント（ログイン済みのブラウザ）

セットアップ（① ローカル / Docker）

1. Cookieの取得方法

  1. ブラウザで note.com にログインする。

  2. 開発者ツールを開く（Chromeの場合: F12 または右クリック→「検証」）。

  3. 「Application」タブ（Firefoxは「Storage」タブ）→ 左側の「Cookies」→ https://note.com を選択。

  4. 一覧から _note_session_v5 という名前の行を探し、「Value」列の値をコピーする。

この値は note.com へのログインセッションそのものです。第三者と共有しないでください。 有効期限が切れたら（下書き作成が失敗し始めたら）、同じ手順で取得し直してください。

2. .env の作成

git clone <このリポジトリのURL>
cd note-mcp
cp .env.example .env

.env を開き、手順1で取得した値を入れる:

NOTE_SESSION_COOKIE=（コピーした値）

3. Dockerイメージのビルド

docker build -t note-mcp .

4. Claude Codeへの登録（ユーザースコープ）

claude mcp add note-mcp --scope user -- \
  docker run -i --rm --env-file /絶対パス/note-mcp/.env note-mcp

--scope user で登録すると、どのプロジェクトを開いているときでも note_create_draft などのツールが使えるようになります。

登録できているかは claude mcp list で確認できます。

使えるツール

ツール名

内容

状態

note_create_draft

タイトル・本文（・タグ）を指定して新規下書きを作成

✅ 動作確認済み（下書き作成・保存）

note_update_draft

既存の下書き（IDで指定）のタイトル・本文（・タグ）を更新

✅ 動作確認済み（下書き保存部分）

note_get_draft

下書きの現在の内容を取得（デバッグ用）

🧪 実験的（未確認）

note_publish_draft

下書きを公開する。confirm:true が無いと実行されない

🧪 実験的（未確認・不可逆操作）

各ツールの tags 引数

タグ付けを試みる

🧪 実験的（未確認。失敗しても記事本体は保存される）

本文はプレーンテキストを渡すと1行1段落として保存されます。簡易的に **太字** と [表示文字](URL) にも対応していますが、note.com の本文HTML仕様は 非公開のため、複雑なMarkdown装飾までは保証しません。

常時稼働させたい場合（Cloudflare Workers）

PCを起動していなくても（/schedule のクラウドスケジュール実行や、スマホ・ブラウザの claude.aiからも）使えるようにしたい場合は、①のstdio版とは別に、Cloudflare Workers上に 常時稼働のMCPサーバーをデプロイできます。ツールの中身（src/register-tools.ts）は 共通で、通信方式だけがstdioからHTTP（Streamable HTTP）に変わり、認証はOAuth 2.1 （Dynamic Client Registration対応。@cloudflare/workers-oauth-provider使用）に なります。claude.aiのカスタムコネクタはOAuthを前提にしているため、この方式にすることで Claude Code・claude.ai（Web/Desktop/モバイル）のどちらからも同じ手順で接続できます。

必要なもの: Cloudflareアカウント（無料枠で可）

1. Cloudflareにログイン

npm install
npx wrangler login

2. KVネームスペースを作成

OAuthの認可コード・トークン・DCRで登録されたクライアント情報を保存するために使う （@cloudflare/workers-oauth-providerが内部で使用）。このリポジトリをforkした場合は 自分のアカウントで作り直す必要がある。

npx wrangler kv namespace create OAUTH_KV

表示されたidをwrangler.jsoncのkv_namespacesに反映する（フォーク元のIDのままだと 他人のネームスペースを指してしまい失敗する）。

3. シークレットを設定

note.comのセッションCookie（取得方法は①と同じ）に加えて、 ログイン用のパスワードも作る。これは、Claude Code・claude.aiがOAuthで接続する際に ブラウザのログイン画面（/authorize）で入力する「このMCPサーバーの持ち主本人であることの 証明」用の合言葉（note.com自体のパスワードやCookieとは別物）。

# ランダムな値を生成（例）
openssl rand -hex 32

npx wrangler secret put NOTE_SESSION_COOKIE
npx wrangler secret put MCP_ACCESS_TOKEN   # 上で生成した値を貼り付ける。ログインパスワードとして使う

どちらもCloudflare側に暗号化して保存され、リポジトリやDockerイメージには一切残らない。

4. デプロイ

方法A（推奨）: GitHub Actions経由で自動デプロイ

mainブランチにsrc/等の変更がpushされるたびに、GitHub Actions （.github/workflows/deploy.yml）が自動で wrangler deployを実行する構成になっています。

  1. このリポジトリをご自身のGitHubアカウントにpush（fork/新規リポジトリ作成）する。

  2. Cloudflareダッシュボード → 右上のアイコン →「My Profile」→「API Tokens」→ 「Create Token」→ テンプレート「Edit Cloudflare Workers」でAPIトークンを発行する。

  3. Cloudflareダッシュボードのトップページ右側に表示されている「Account ID」を控える。

  4. GitHubリポジトリの Settings → Secrets and variables → Actions → 「New repository secret」で以下を登録する:

    • CLOUDFLARE_API_TOKEN（手順2の値）

    • CLOUDFLARE_ACCOUNT_ID（手順3の値）

  5. mainブランチにpushする（初回は空コミットでもよい）と、Actionsタブでデプロイが 実行される。

以降はmainにマージするだけで自動的に最新版がデプロイされます。 .github/workflows/ci.yml はPull Requestの時点で ビルド・テスト・型チェックのみ行い（Cloudflareの認証情報は使わないため、フォークからの PRでも安全に実行できる）、実際のデプロイはmainへのマージ後に限定しています。

より厳格に運用したい場合は、GitHubリポジトリの Settings → Environments で production という名前のEnvironmentを作り、Required reviewers（承認者）を 設定すると、デプロイ実行前に人の承認を挟めます。

方法B: ローカルから手動デプロイ

npm run deploy:worker

どちらの方法でも、成功すると https://note-mcp.<あなたのサブドメイン>.workers.dev が発行される（同一Workerなので、方法Aと方法Bを併用しても問題ない）。

5. 接続する

OAuth対応にしたことで、Claude Code・claude.ai（Web/Desktop/モバイル）のどちらからも 同じMCPサーバーに接続できる。初回はブラウザでログイン画面が開き、手順3で設定した MCP_ACCESS_TOKENをパスワードとして入力する（以後はトークンが自動更新されるため、 毎回入力する必要はない）。

Claude Codeの場合:

claude mcp add note-mcp-remote --scope user --transport http \
  https://note-mcp.<あなたのサブドメイン>.workers.dev/mcp

-Hでのヘッダー指定は不要（OAuthに統一したため）。ローカル/Docker版（①）と名前が 被らないよう note-mcp-remote 等の別名にすると、両方を併用する場合にも混乱しない。 接続時にブラウザが開かない場合は claude mcp login note-mcp-remote を実行する。

claude.aiの場合:

  1. Customize → Connectors → 「Add custom connector」

  2. MCPサーバーのURL（https://note-mcp.<あなたのサブドメイン>.workers.dev/mcp）を入力

  3. 保存すると自動的にOAuthのログイン画面へリダイレクトされるので、MCP_ACCESS_TOKENを パスワードとして入力して「許可する」

Advanced settings（OAuth Client ID/Secret）の入力は不要（Dynamic Client Registrationで claude.ai側が自動的にクライアント登録するため）。

ローカルでWorkerの動作確認をする場合

cp .dev.vars.example .dev.vars   # NOTE_SESSION_COOKIE / MCP_ACCESS_TOKEN を設定（コミット対象外）
npm run dev:worker               # wrangler dev。Cloudflareへのデプロイはせずローカルで起動

既知の制限

  • 非公式API: note.com が公式に提供しているAPIではなく、ブラウザの通信を観察して 発見したエンドポイントを利用しています。仕様変更でいつ動作しなくなってもおかしくありません。

  • 公開機能は未確認: 記事を実際に公開するAPIエンドポイントは特定できていません。 note_publish_draft は候補となるエンドポイントを複数試しますが、失敗する可能性が高いです。 失敗した場合は、実際にブラウザで「公開に進む」ボタンを押した際の通信をDevToolsの Networkタブで確認し、src/note-client.ts の publishDraft 内の候補エンドポイントを 実際のリクエストに合わせて書き換えてください。

  • タグ付けも未確認: 同様に、実際の通信を確認しながら updateHashtags を調整してください。

  • セッションCookieの有効期限: 切れた場合は取得し直して、①は .env、②は npx wrangler secret put NOTE_SESSION_COOKIE で再設定してください。

  • OAuthは単一ユーザー専用の簡易実装: /authorizeのログイン画面はユーザーごとの アカウント管理をせず、MCP_ACCESS_TOKENと一致するパスワードなら誰でもログインできる 設計です（このMCPサーバーの持ち主1人だけが使う前提のため）。複数人での利用や、 より厳密なアクセス制御が必要な場合はCloudflare Access等の追加を検討してください。

ローカル開発（Dockerを使わない場合）

npm install
cp .env.example .env   # NOTE_SESSION_COOKIE を設定
npm run build
npm start

本文変換ロジック（src/text-to-html.ts）の単体テスト（外部通信なし）:

npm run test:text-to-html

ライセンス

MIT

Available Tools

4 tools
note_create_draftA

note.comに新しい下書き記事を作成する。公開はされない（下書きのまま保存される）。本文はプレーンテキスト、または簡易Markdown（太字、文字）を1行1段落として渡す。tags を指定した場合はタグ付けも試みるが、note.com側のAPI仕様が未確認のため失敗することがある（その場合も記事自体の作成は成功する）。

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYes記事の本文。改行区切りで段落になる。簡易Markdown対応
tagsNo設定したいタグ（省略可・動作未保証の実験的機能）
titleYes記事のタイトル

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full disclosure burden and delivers thoroughly: it details the draft-only behavior, the one-line-per-paragraph body format, supported Markdown syntax, and the experimental tag feature with its failure caveat. This is exemplary transparency.

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 a compact two-sentence block that front-loads the core action and includes only useful behavioral details. There is no filler or redundant repetition of schema fields.

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

Completeness4/5

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

For a 3-parameter create operation with no output schema and no annotations, the description covers the essential invocation context: purpose, non-publication, body formatting, and tag uncertainty. The only notable omission is any mention of the return value or subsequent handling of the created draft, but this is minor for invocation.

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

Parameters4/5

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

Schema description coverage is 100%, but the description adds meaningful detail beyond the schema: exact Markdown examples and the paragraph-per-line rule for body, plus the caveat that tags may fail. This elevates the value beyond the baseline 3.

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 opens with a specific verb and resource ('create a new draft article on note.com') and clarifies it is saved as a non-published draft. This immediately distinguishes the tool from sibling tools like note_publish_draft and note_update_draft.

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?

The description clearly signals this tool is for new drafts and explicitly states it does not publish ('公開はされない'), which contextually routes away from publish/update siblings. However, it does not name the sibling alternatives or state exactly when to use them, so explicit when-not guidance is missing.

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

note_get_draftA

下書き記事の現在の内容を取得する（動作確認・デバッグ用）。note.com側のAPI仕様が未確認のため、取得自体が失敗する可能性がある実験的機能。

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesnote ID

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly implies a read-only operation via '取得する' and explicitly discloses that the tool is experimental and may fail because the API spec is unconfirmed. It could add more detail about return values or error behavior, but the key behavioral caveat is present.

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 a single, compact sentence that front-loads the main action and then adds a relevant experimental warning. Every phrase earns its place, with no redundant filler.

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

Completeness4/5

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

For a simple one-parameter tool with no output schema, the description states the purpose, the target resource, and the risk of failure. It does not describe the exact return shape, but for a debug-oriented retrieval tool the essential operational context is provided.

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 input schema covers the only parameter 'id' at 100% with a description 'note ID'. The description does not add extra meaning beyond the schema, but none is strictly needed for a single, well-specified parameter. Baseline 3 is appropriate.

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 uses a specific verb and resource: '取得する' (retrieve) the current content of a draft. This clearly distinguishes it from the sibling tools note_create_draft, note_update_draft, and note_publish_draft, which are all mutations.

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?

The description provides clear context: it is intended for operation checks and debugging, and it explicitly warns that retrieval may fail due to unconfirmed note.com API specifications. It does not name alternatives or explicitly state when not to use it, but the context is sufficient.

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

note_publish_draftA

下書き記事を公開する。【不可逆・対外公開を伴う操作】記事が誰でも閲覧可能な状態になる。note.com側の公開APIは未確認のため動作未保証の実験的機能。confirm:true を指定しない限り実行されない。

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesnote ID
confirmNotrue を指定した場合のみ実際に公開を実行する

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral disclosure. It explicitly warns that the action is irreversible and publicly exposes the article, states that it is experimental and unverified on note.com's API, and explains that execution requires confirm:true. This is strong transparency for a destructive operation.

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 compact and every sentence earns its place: the operation, the irreversible/public consequence, the experimental status, and the required confirmation flag. Warnings are front-loaded, making the risk profile immediately visible.

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

Completeness5/5

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

For a low-complexity, two-parameter tool with no output schema and no annotations, the description is sufficiently complete. It tells the agent what the tool does, why it is risky, that it is not guaranteed to work, and what condition must be met before it will execute.

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 input schema already covers both parameters, including a description for id and the confirm parameter's role. The description restates the confirmation condition but does not add meaningful parameter-level details beyond what the schema provides, so it stays at the baseline for full schema coverage.

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 states the exact operation ('下書き記事を公開する') and clarifies the real-world effect ('記事が誰でも閲覧可能な状態になる'). This clearly distinguishes it from the sibling draft-management tools, which cover create, update, and get, not publishing.

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 when to use the tool: when you intend to publish a draft and accept its public/irreversible consequences. However, it does not explicitly contrast it with alternatives like note_update_draft or note_get_draft, nor does it state when not to use it.

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

note_update_draftA

既存の下書き記事（IDで指定）のタイトル・本文を上書き保存する。公開状態は変更しない。

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesnote_create_draft で取得した note ID
bodyYes記事の本文。改行区切りで段落になる。簡易Markdown対応
tagsNo設定したいタグ（省略可・動作未保証の実験的機能）
titleYes記事のタイトル

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations available, the description carries the burden and discloses two meaningful traits: the operation is an overwrite (上書き保存), and it preserves publication status. This gives the agent a clear safety-relevant behavioral picture, though it does not cover side effects on omitted optional tags or the response shape.

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?

Two short sentences with no filler: the first names the operation and target, the second states the crucial invariant. The most important information is front-loaded.

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

Completeness3/5

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

For a write operation with no annotations and no output schema, the description covers purpose and the publication-status invariant, but leaves ambiguity about optional tag handling and does not indicate what the tool returns. These gaps are modest because the schema is fully described and the use case is simple.

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 description coverage is 100%, so the input schema already documents id, title, body, and tags. The description reinforces that title and body are overwritten, but adds no new detail about how the optional tags parameter behaves when omitted.

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 specifies the exact verb and resource: overwrite-saving the title/body of an existing draft identified by ID, and adds a key boundary ('公開状態は変更しない'). This clearly distinguishes it from note_create_draft, note_get_draft, and note_publish_draft.

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 frames the tool as working on an existing draft (既存の下書き) and explicitly states it will not change publication status, which tells the agent when this tool is appropriate and when to look elsewhere. However, it does not name the alternative sibling tools explicitly, so the routing guidance is implied rather than fully explicit.

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. 4 tool updatesv0.1.0
    • First observednote_create_draft
    • First observednote_get_draft
    • First observednote_publish_draft
    • First observednote_update_draft
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool performs a distinctly different action in the draft lifecycle: create, update, get, and publish. There is no meaningful overlap, and the irreversible publish operation is clearly separated by the confirm:true requirement.

Naming Consistency5/5

All tool names follow the same note_<verb>_<object> pattern with consistent snake_case. The naming is predictable and makes the function of each tool immediately clear.

Tool Count5/5

Four tools is a well-scoped size for a focused draft-management server. Each tool covers a necessary step in the core draft workflow without unnecessary bloat.

Completeness3/5

The server covers create, read, update, and publish for drafts, but there is no delete or list operation, which are notable gaps in a draft-management workflow. The experimental nature of several tools also makes some operations unreliable.

Maintenance

ActivityMaintained
ResponsivenessSyncing

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/TaisukeAndo/note-mcp'

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