A read-only MCP server that detects and retrieves "read later" quote retweets from X (Twitter), designed for integration with knowledge management pipelines (e.g., Claude → Notion).
get_quoted_posts: Retrieve quote retweets posted since the last confirmed cursor position, including the quoted post's text, author, creation date, URL, and media — without advancing the cursor.
max_results (1–100, default 20): control how many posts are fetched
since_id: manually override the cursor to rewind the fetch start position (useful for recovering missed posts)
commit_cursor: Advance the cursor only after downstream processing (e.g., saving to Notion) has succeeded, by providing the last successfully processed post_id. If never called (e.g., due to failure), the cursor stays in place so the same posts can be re-fetched, preventing data loss.
Cursor state is stored locally in ~/.atodeyomu-mcp/cursor.json, enabling incremental (diff-only) fetching via since_id to minimize costs. The server performs no write operations to X (no posting, liking, or retweeting) and handles OAuth 2.0 authentication with automatic token refresh.
Allows saving summarized X (Twitter) quote posts to a Notion database for knowledge management.
Click on "Deploy 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., "@atodeyomu-mcp fetch my recent quote retweets"
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.
X (Twitter) で「あとで読む」目的の 引用リツイート（引用ポスト） を検出する、読み取り専用の MCP サーバーです。引用ポストとその引用元（本文・メディア・著者）をまとめて取得し、Claude（Cowork）→ Notion の知識管理パイプラインから利用することを想定しています。
提供するツールは get_quoted_posts（前回以降の引用ポストを取得）・commit_cursor（取得位置を確定）・fetch_article（引用元が貼った記事 URL を解決して本文を抽出）の 3 つです。X への投稿・いいね・RT などの書き込みは一切行いません（fetch_article も記事の読み取りのみ）。前回どこまで取得したかはローカル（~/.atodeyomu-mcp/cursor.json）に記録し、since_id で差分だけを取得するため、Notion 照合のコストを抑えられます。
動作確認の詳細手順は docs/VERIFICATION.md、Cowork スケジュールタスクで Notion に記録するまでの手順は docs/COWORK_PIPELINE.md を参照してください。設計の詳細は docs/DESIGN.md、フロー図つきの仕様は docs/SPEC.md にあります。
Node.js 20 以上（npx が使えること）
X Developer アカウント（無料プランで可）
Claude（Cowork / デスクトップアプリ）
npx で実行するため、リポジトリの clone やビルドは不要です。
Related MCP server: X MCP Server
developer.x.com でプロジェクトとアプリを作成します。
アプリの User authentication settings を開き、次のように設定します。
App permissions: Read
Type of App: Web App, Automated App or Bot（Confidential client）
Callback URI / Redirect URL: http://127.0.0.1:8787/callback
Website URL: 任意の URL（例: GitHub リポジトリ URL）
Keys and tokens から OAuth 2.0 Client ID と Client Secret を控えます。
スコープは
tweet.readusers.readoffline.accessの 3 つだけを使います。
トークンを取得する認可を一度だけ実行します。控えた Client ID / Secret をフラグで渡します。
npx -y atodeyomu-mcp auth --client-id 控えたClientID --client-secret 控えたClientSecretターミナルに表示された認可 URL をブラウザで開きます。
X で承認すると http://127.0.0.1:8787/callback にリダイレクトされ、access / refresh token を取得します。
トークンは ~/.atodeyomu-mcp/tokens.json に chmod 600 で保存されます。
以降、トークンは MCP サーバーが自動でリフレッシュします。再認可が必要になるのは refresh token が失効したときだけです（その場合は同じコマンドを再実行）。
Claude（Cowork / デスクトップアプリ）の MCP 設定ファイルに登録します。場所は次のとおりです。
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
このファイルの mcpServers に次を追記します（他のキーは消さないこと）。CLIENT_ID / CLIENT_SECRET は env で渡します（サーバーがトークンを自動リフレッシュする際に必要です）。
{
"mcpServers": {
"atodeyomu": {
"command": "npx",
"args": ["-y", "atodeyomu-mcp@latest"],
"env": {
"CLIENT_ID": "控えたClientID",
"CLIENT_SECRET": "控えたClientSecret"
}
}
}
}保存後、Claude（Cowork）アプリを再起動すると atodeyomu が接続されます。
@latestを付けると、アプリ再起動のたびに最新版を取得します（npx はキャッシュするため、付けないと古い版を使い続けます）。バージョンを固定したい場合はatodeyomu-mcp@1.0.0のように指定してください。いま動いている版は
npx -y atodeyomu-mcp --version、npm 上の最新版はnpm view atodeyomu-mcp versionで確認できます。
この MCP 設定ファイルには秘密情報（Client ID / Secret）が平文で入ります。共有・コミットしないでください。
Claude Code CLI など他の MCP クライアントを使う場合は、上の
atodeyomuエントリ（command/args/env）を各クライアントの MCP 設定に記述してください（中身は同じです）。
登録後、Claude（Cowork）から 3 つのツールを呼び出せます。基本の流れは「get_quoted_posts で差分を取得 →（引用元に記事 URL があれば fetch_article で本文を取得）→ 要約して Notion に保存 → 成功したら commit_cursor で取得位置を確定」です。
get_quoted_posts前回確定した位置以降の引用ポストを返します。この時点では取得位置を進めません。
入力
パラメータ | 型 | 必須 | デフォルト | 説明 |
| number | 任意 | なし | 1〜50。指定すると 古い順（id 昇順）に最大 N 件だけ返る（MCP が内部で全ページを取得して絞り込む）。 |
| number | 任意 | 20 | 1〜100（ |
| string | 任意 | カーソル値 | 取りこぼし時に取得開始位置を手動で巻き戻すための上書き |
| string | 任意 | なし | 前回のレスポンスの |
出力（例）
{
"posts": [
{
"id": "1899...",
"text": "これあとで読む",
"created_at": "2026-06-20T09:12:00.000Z",
"url": "https://x.com/your_name/status/1899...",
"quoted_post": {
"id": "1898...",
"text": "引用元の本文 ...",
"created_at": "2026-06-19T22:00:00.000Z",
"author_username": "someone",
"url": "https://x.com/someone/status/1898...",
"media": [{ "url": "https://pbs.twimg.com/media/xxx.jpg", "type": "photo" }]
}
}
],
"newest_seen_id": "1899...",
"next_token": null,
"has_more": false
}前回以降の直近 max_results 件のうち、引用ポストだけが posts に返ります。「あとで読む」というキーワードでの絞り込みや要約は、呼び出し側（Cowork のスキル/タスク）で行う設計です。has_more は「返した分の先にまだ未処理の引用ポストが残っているか」を示します。
limit を指定すると、MCP が内部で全ページを取得したうえで引用ポストを古い順（id 昇順）に並べ、先頭 N 件だけを返します。差分が溜まっていても、呼び出し側は 1 回呼ぶだけで「処理すべき古い N 件」と has_more を受け取れます（差分全件をコンテキストに載せずに済む）。想定フローは、古い順に処理してから commit_cursor を呼ぶこと——全件処理でき has_more が false なら newest_seen_id で、has_more が true なら返ってきた posts の最後（最も新しい）の id で確定し、残りは次回に回します。
limit を指定しない従来モードでは単一ページが返り、next_token が値を持つ場合はまだ続きがあるということなので、その値を pagination_token に渡して呼び直すとページ送りできます。全ページ分の posts を合算し、commit_cursor には1回目（pagination_token を指定しない呼び出し）の newest_seen_id を渡します（2回目以降は過去方向へのページ送りのため、より新しい id を含みません）。
fetch_article引用元ポストが貼っている記事 URL を解決し、リンク先の本文テキストを抽出して返します。quoted_post.text に含まれる t.co 短縮 URL をそのまま渡せば、MCP がリダイレクトを追って最終記事 URL に解決し、本文を取り出します。返すのは抽出済み本文までで、要約は呼び出し側で行います。
入力
パラメータ | 型 | 必須 | 説明 |
| string | 必須 | 記事の URL。 |
出力（例）
{
"final_url": "https://zenn.dev/someone/articles/xxxx",
"title": "記事タイトル",
"text": "抽出された記事本文 ...",
"status": "ok"
}status は結果の種別です。ok 以外のときは text が空文字になります。
status | 意味 |
| 記事本文を抽出できた（ |
| リダイレクト先が X の別ポストだった（引用元がさらに別ポストを引用しているケース）。本文は取得しない |
| リダイレクト先が X ネイティブ記事（ |
| 取得できたが記事本文として抽出できなかった（画像・動画のみ、非 HTML 等） |
| ネットワークエラー・非 HTTP・ペイウォール・タイムアウト等 |
ok 以外は「記事が取れなかった」だけでエラーではありません。呼び出し側は引用コメントと引用元本文からの要約にフォールバックする想定です。記事の読み取り（GET）のみで、X や外部サイトへの書き込みは行いません。
commit_cursorNotion への保存が成功したあとに呼び、取得位置を進めます。
パラメータ | 型 | 必須 | 説明 |
| string | 必須 | ここまで安全に保存できた最後の post id |
全件成功なら get_quoted_posts が返した newest_seen_id を、一部だけ保存できた場合はその最後の id を渡します。次回の get_quoted_posts はその id 以降から再開します。途中で失敗して commit_cursor を呼ばなければ取得位置は据え置かれ、次回また同じ差分を取り直せるので取りこぼしが起きません。
X 上で、適当な投稿に「あとで読む」とコメントを付けて 引用ポスト します。
上記の MCP 設定に登録した状態で Claude（Cowork）アプリを起動します。
Claude（Cowork）に get_quoted_posts を呼ぶよう指示します（例:「直近の引用ポストを取得して」）。
手順 1 の引用ポストが、引用元の本文・メディアまで含めて返ってくれば成功です。
続けて、返ってきた newest_seen_id で commit_cursor を呼び、~/.atodeyomu-mcp/cursor.json が更新されることを確認します。次回 get_quoted_posts を呼ぶと、その位置以降の差分だけが返ります。
症状 | 対処 |
| refresh token が失効しています。 |
トークン期限切れ後にリフレッシュで失敗する | MCP 設定ファイル（ |
レート制限のエラー | メッセージ中の |
コールバックが届かない | Developer Portal の Callback URI が |
Client ID / Secret は MCP 設定ファイル（claude_desktop_config.json）の env に平文で入ります。この設定ファイルとトークン（~/.atodeyomu-mcp/tokens.json）は秘密情報です。コミット・共有しないでください。
資格情報（Client ID / Secret）は、サーバー起動時は MCP 設定ファイルの env、認可時は --client-id / --client-secret フラグで渡します。
トークンファイルは chmod 600 で保存されます。
カーソル（~/.atodeyomu-mcp/cursor.json）は秘密情報ではありませんが、トークンと同じディレクトリで管理されます。取得位置をリセットしたい場合はこのファイルを削除してください。次回呼び出しは since_id なしになるため、まずタイムラインの直近 max_results 件（既定20・最大100）が返りますが、レスポンスの next_token を pagination_token に渡して呼び直せば、それより古い投稿も複数回のページ送りで遡って取得できます。
本サーバーは X に対して読み取り専用で、書き込み権限は要求しません（ローカルのカーソルファイルのみ書き込みます）。
This project is unofficial, community-maintained, and not affiliated with X Corp. Use at your own risk. "X" and "Twitter" are trademarks of their respective owners.
下流処理（Notion 保存など）の成功を確認した後に呼び、取得位置カーソルを確定する。X API は呼ばない。
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ここまで安全に保存済みである最後の post id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions it does not call X API, which is a behavioral trait, but does not disclose other side effects or state changes. Minimal compensation for missing annotations.
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 in Japanese, front-loaded with the purpose, no redundant 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?
Simple tool with one parameter and no output schema. Description sufficiently explains the context, but lacks details on return value or error handling.
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 parameter description already explains the meaning. Description adds context about usage but does not extend parameter semantics 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 clearly states the action ('commit cursor') and resource ('acquisition position cursor'), and explicitly distinguishes that it does not call X API, differentiating from sibling tool get_quoted_posts.
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 call (after confirming downstream success) and what it does not do, but lacks explicit alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
前回確定したカーソル以降の引用ポスト（あとで読む用の引用リツイート）と引用元コンテンツを取得する。カーソルは進めない。
| Name | Required | Description | Default |
|---|---|---|---|
| since_id | No | この id 以降を取得する。指定時はカーソルより優先される | |
| max_results | No | 取得件数（既定20、最大100） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states a critical behavioral trait: the cursor is not advanced. It also indicates this is for 'reading later', adding context beyond 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?
Description is a single, clear sentence that front-loads the key action. No unnecessary words, but could be slightly more structured (e.g., separate clauses for clarity).
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 only 2 parameters, the description is reasonably complete. It explains the core functionality and a key behavioral nuance. However, it could mention behavior when no cursor is set or what the return format looks like.
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 descriptions already cover 100% of parameters with clear explanations (e.g., since_id overrides cursor). The tool description does not add significant new information about parameters beyond what schema provides.
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 the tool retrieves quoted posts and source content after a previously confirmed cursor, and explicitly notes the cursor is not advanced. This distinguishes it from the sibling tool 'commit_cursor' which likely advances the cursor.
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?
Description implies usage for reading later without advancing cursor, but does not explicitly state when to use or avoid this tool, nor mention alternatives beyond the sibling tool name.
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.
v1.0.0commit_cursorget_quoted_postsScored across 2 tools
The two tools have completely distinct purposes: one confirms cursor progression after downstream success, the other retrieves new quoted posts. No overlap or ambiguity.
Both tool names follow a consistent verb_noun snake_case pattern ('commit_cursor', 'get_quoted_posts'), making them predictable and clear.
With only 2 tools, the server feels minimal. While it may be sufficient for a focused task, it borders on being too thin compared to typical well-scoped servers (3-15 tools).
The tool set covers the core workflow of retrieving new posts and committing progress. No obvious missing operations for the stated purpose, though additional features like resetting a cursor could be useful.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
