de en es ja ko ru zh

plsreadme

Name: plsreadme
Author: FacundoLucci

by FacundoLucci

Overview Schema Source Related Servers Discussions Admin

TypeScript

課題

README、PRD、会議メモ、APIドキュメントなどをマークダウンで作成した際、マークダウンレンダラーを持っていない人やGitHubを使わない人に共有する必要がある場合、ブラウザで開けるクリーンなリンクが必要です。

plsreadme は、あらゆるマークダウンをワンステップで永続的かつ美しくレンダリングされたWebページに変換します。アカウント作成やサインアップは不要。摩擦ゼロです。

Related MCP server: slideless-mcp

✨ 機能

インスタント共有 — マークダウンを貼り付けるかファイルをアップロードして、plsrd.me リンクを取得
美しいレンダリング — クリーンなタイポグラフィ、ダークモード、モバイル対応
インラインコメント — 読者は任意の段落をクリックしてフィードバックを残せます
レビューモード（現在 vs タイムライン） — 複数バージョンのドキュメントでは、デフォルトで現在のドラフトへのフィードバックを表示し、ワンクリックで完全なタイムライン履歴にアクセス可能
AI自動フォーマット — 生テキストを投げれば、クリーンなマークダウンとして出力
MCPサーバー — Claude、Cursor、VS Code、または任意のMCPクライアントから直接ドキュメントを共有
OpenClawスキル — AIエージェントワークフロー向けに ClawHub で利用可能
ショートリンク — すべてのドキュメントにコンパクトな plsrd.me/v/xxx URLを発行
Rawアクセス — 共有リンクから元の .md ファイルをダウンロード可能
バージョンタイムライン + 安全な復元 — /v/:id/versions + /v/:id/history + アーカイブ優先の復元APIによる迅速なロールバック
Clerk認証基盤 — GitHub/Googleサインイン連携 + Clerkホスト型メールフォールバック + バックエンド認証検証ユーティリティ
所有権モデル（フェーズ2） — 匿名フローを維持しつつ、ドキュメントをClerkユーザー（owner_user_id）に紐付け可能
マイリンクダッシュボード（フェーズ3） — 認証済みユーザー向けの /my-links ページ（検索・並び替え・ページネーション・クイックコピー/オープン機能付き）
レガシーリンクの請求（フェーズ4） — サインイン済みユーザーが元の admin_token を証明することで、古い匿名リンクを自分のものとして請求可能
ゼロコンフィグのウェブサイトデモ — ブラウザで試すのにアカウントやAPIキーは不要

🚀 クイックスタート

ウェブ

plsreadme.com にアクセスし、マークダウンを貼り付けて共有ボタンをクリックしてください。

認証パスとロールアウト状況

推奨順序:

まずブラウザで試す — 最速のデモパス。MCP設定不要。
クライアントサポートが確認できたら、ホスト型リモートMCPとブラウザログインを使用する。
インタラクティブなログインが利用できない場合は、APIキー / ローカルMCPフォールバックを使用する。

現在のロールアウト状況:

ジャーニー	今日のステータス	所有権ルール	ソースタグ
匿名ウェブサイトデモ	ブラウザ検証デモフローで利用可能	ユーザーが後で保存/請求するまで `owner_user_id = NULL`	`web_demo`
サインイン済みウェブサイト作成	利用可能	サインインしたClerkユーザーを所有者として作成	`web_signed_in`
ブラウザログイン付きホスト型リモートMCP	対応クライアントで利用可能	ブラウザログイン後、サインインユーザーの所有ドキュメントを作成	`mcp_remote_login`
APIキー付きホスト型リモートMCP	互換性フォールバックとして利用可能	APIキー所有者の所有ドキュメントを作成	`mcp_remote_api_key`
APIキー付きローカルnpm MCP	ローカルstdio設定で推奨	APIキー所有者の所有ドキュメントを作成	`mcp_local_api_key`
ローカルnpm MCP匿名フォールバック	明示的なオプトインでのみ利用可能	後で請求/保存されない限り匿名のまま	`mcp_local_anonymous`

ホスト型リモートMCPのロールアウトに関する注意点:

https://plsreadme.com/mcp
https://plsreadme.com/sse

これらのホスト型リモートMCPルートは、コード内のOAuth保護されたブラウザログイン（/authorize、/oauth/token、/oauth/register を含む）の背後で稼働しています。

運用上の注意点:

D1の doc_create_events は、ウェブ、ホスト型MCP、ローカルMCPフロー全体における正規の作成属性テーブルです。
docs.raw_view_count はすべてのレンダリングヒットを追跡し、docs.view_count は人間による閲覧と推定されるものに限定されます。
本番環境のクエリセットと対応手順については docs/runbooks/auth-surface-monitoring.md を参照してください。
アクセストークンの有効期限は約 1時間 です。
リフレッシュトークンの有効期限は約 30日 です。
同じクライアントを再接続すると、古い権限は置き換えられます。
ウェブサイトからサインアウトしても、既存のエディター権限は自動的に取り消されません。
このリポジトリは、OAUTH_KV という名前のCloudflare Workers KVバインディングに接続されています。

クライアントでブラウザログインが利用できない場合は、/my-links から個人用APIキーを作成し、ホスト型リモートヘッダーフォールバックまたはローカルの npx -y plsreadme-mcp パッケージを使用してください。

ウェブサイトデモの信頼モデル:

/api/create-link での匿名ウェブサイト作成には、短期間のブラウザ検証権限が必要です。
サインイン済みのウェブサイト作成ではその権限をスキップし、摩擦を最小限に抑えます。
作成後のUIは アカウントに保存、エディターを接続、リンクをコピー に分岐します。

API

curl -X POST https://plsreadme.com/api/render \
  -H "Content-Type: application/json" \
  -d '{"markdown": "# Hello World\n\nThis is my doc."}'

{
  "id": "abc123def456",
  "url": "https://plsreadme.com/v/abc123def456",
  "raw_url": "https://plsreadme.com/v/abc123def456/raw",
  "admin_token": "sk_..."
}

admin_token を保存してください。編集や削除に必要です：

# Update
curl -X PUT https://plsreadme.com/v/abc123def456 \
  -H "Authorization: Bearer sk_..." \
  -H "Content-Type: application/json" \
  -d '{"markdown": "# Updated content"}'

# Delete
curl -X DELETE https://plsreadme.com/v/abc123def456 \
  -H "Authorization: Bearer sk_..."

バージョンタイムライン + 安全な復元

AI反復サイクル中のリビジョンコンテキストを確認するには、タイムラインエンドポイントを使用します：

curl https://plsreadme.com/v/abc123def456/versions

{
  "id": "abc123def456",
  "current_version": 5,
  "total_versions": 5,
  "versions": [
    { "version": 5, "is_current": true, "raw_url": "https://plsreadme.com/v/abc123def456/raw" },
    { "version": 4, "is_current": false, "raw_url": "https://plsreadme.com/v/abc123def456/raw?version=4" }
  ]
}

AIの編集でドキュメントが退行した場合は、以前のスナップショットを復元します（アーカイブ優先、非破壊的）：

curl -X POST https://plsreadme.com/v/abc123def456/restore \
  -H "Authorization: Bearer sk_..." \
  -H "Content-Type: application/json" \
  -d '{"version": 4}'

復元は更新と同様にレート制限（現在、アクターキーあたり 60回/時間）が適用され、悪用を防止します。

認証済みClerkユーザーが所有するドキュメントの場合、更新・削除・復元には所有者セッションも必要です（ユーザー間での改ざん防止）。一方、匿名ドキュメントは admin_token のみで引き続き動作します。

レビューモードの使用上の注意（現在のドラフト優先、タイムラインはオンデマンド）

ドキュメントビューアーはコメントレビューコントロールを公開しています：

現在のドラフト — 最新のドキュメントバージョンに関連付けられたコメントのみを表示します（ドキュメントに複数のバージョンがある場合のデフォルト）。
タイムライン — バージョンを横断した完全なコメント履歴を表示します。

APIから直接同じモードを取得することも可能です：

# Latest-version comments only
curl "https://plsreadme.com/api/comments/abc123def456?view=current"

# Full timeline comments (default API behavior)
curl "https://plsreadme.com/api/comments/abc123def456?view=all"

ビューアーリンクは、共有可能なレビューコンテキストのためにURLにモードを保持します：

https://plsreadme.com/v/abc123def456?view=current
https://plsreadme.com/v/abc123def456?view=timeline

レガシーな匿名リンクをサインイン済みアカウントに請求するには：

curl -X POST https://plsreadme.com/api/auth/claim-link \
  -H "Authorization: Bearer <clerk-session-jwt>" \
  -H "Content-Type: application/json" \
  -d '{"id":"abc123def456","adminToken":"sk_..."}'

MCP (AIエディター)

現在の推奨事項：

クライアントがクリーンにサポートしている場合は、ブラウザログイン付きのホスト型リモートMCPを使用する
リモート認証が利用できない、またはクライアントで使いにくい場合は、個人用APIキーフォールバックを使用する
最も安全なstdioパスとして、PLSREADME_API_KEY を使用したローカルの plsreadme-mcp パッケージを使用する

エディターをplsreadmeに接続し、自然言語でドキュメントを共有しましょう：

*"このREADMEをplsreadmeリンクとして共有して" *"私のPRDを共有可能なページにして" *"この会議メモを読みやすいリンクにして"

`/versions` を使用したMCP/エージェントの自動レビューループ

反復的なAIライティングフロー（ドラフト → 批評 → 修正）では、エージェントは /v/:id/versions を信頼できる情報源として利用できます：

人間用の正規の読み取り可能URL (/v/:id) を維持する。
反復の間に /v/:id/versions をポーリングする。
current_version と最後にレビューされたバージョンを比較する。
変更されている場合、最新バージョンの raw_url を取得してレビューチェックを実行する。
品質が低下した場合は、必要に応じて管理者トークン + 所有者セッションで /v/:id/restore をトリガーする。

これにより、HTMLをスクレイピングすることなく、自動化された決定論的なリビジョントラッキングが可能になります。

完全なプレイブックについては docs/ai-iteration-versioning.md を参照してください。

🔌 MCP設定

クライアント互換性マトリックス

2026年4月5日現在：

クライアント	推奨パス	ブラウザログインサポート	APIキーフォールバック	注意点
Claude Code	ホスト型リモートMCP優先	ライブ検証済み	はい	最適なリモートフロー。`PLSREADME_API_KEY` を使用したローカルstdioも良好
Cursor	ホスト型リモートMCP優先	文書化済みだがビルド依存	はい	OAuthプロンプトが表示されない場合はヘッダーを使用
VS Code	利用可能な場合はホスト型リモートMCP	設定が存在し、ビルドによりロールアウトが異なる	はい	ログインUXがない場合は `type: "http"` とヘッダーフォールバックが機能
Windsurf	利用可能な場合はホスト型リモートMCP	文書化されたリモートサポート	はい	ブラウザ認証がまだ公開されていない場合は `serverUrl` + ヘッダーを使用
Claude Desktop	ローカルnpm MCP	リモートブラウザフローの検証なし	はい	stdio + `PLSREADME_API_KEY` を推奨
Raw HTTP / スクリプト	ホスト型リモートヘッダーモード	いいえ	はい	`Authorization: Bearer $PLSREADME_API_KEY` を直接送信

ホスト型リモートログイン（対応クライアント）

Claude Code:

claude mcp add --transport http plsreadme https://plsreadme.com/mcp

Cursor:

{
  "mcpServers": {
    "plsreadme": {
      "url": "https://plsreadme.com/mcp"
    }
  }
}

VS Code:

{
  "servers": {
    "plsreadme": {
      "type": "http",
      "url": "https://plsreadme.com/mcp"
    }
  }
}

Windsurf:

{
  "mcpServers": {
    "plsreadme": {
      "serverUrl": "https://plsreadme.com/mcp"
    }
  }
}

ライフサイクルの注意点：

アクセストークンのTTLは約 1時間 です。
リフレッシュトークンのTTLは約 30日 です。
同じクライアントを再接続すると、古い権限は置き換えられます。
サインアウトはウェブサイトのセッションを終了させますが、既存のエディター権限を自動的に取り消すことはありません。
ホスト型エディター権限の監査や取り消しには GET /api/auth/mcp-grants および DELETE /api/auth/mcp-grants/:grantId を使用してください。

クライアントがブラウザログインをサポートしている場合は、このパスを優先してください。最もクリーンな設定であり、所有ドキュメントがウェブサイトのアカウントに自動的に紐付けられます。

ホスト型リモートAPIキーフォールバック

まず https://plsreadme.com/my-links から個人用APIキーを作成し、以下のいずれかを使用してください：

Claude Code:

claude mcp add --transport http \
  --header "Authorization: Bearer $PLSREADME_API_KEY" \
  plsreadme-api https://plsreadme.com/mcp

Cursor:

{
  "mcpServers": {
    "plsreadme-api": {
      "url": "https://plsreadme.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:PLSREADME_API_KEY}"
      }
    }
  }
}

VS Code:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "plsreadme-api-key",
      "description": "plsreadme personal API key",
      "password": true
    }
  ],
  "servers": {
    "plsreadme-api": {
      "type": "http",
      "url": "https://plsreadme.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:plsreadme-api-key}"
      }
    }
  }
}

Windsurf:

{
  "mcpServers": {
    "plsreadme-api": {
      "serverUrl": "https://plsreadme.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:PLSREADME_API_KEY}"
      }
    }
  }
}

Rawリモートエンドポイントユーザー：

curl -i https://plsreadme.com/mcp \
  -H "Authorization: Bearer $PLSREADME_API_KEY"

ローカルnpmフォールバック

Claude Code:

claude mcp add --transport stdio \
  --env PLSREADME_API_KEY=$PLSREADME_API_KEY \
  plsreadme -- npx -y plsreadme-mcp

Cursor: ~/.cursor/mcp.json に追加：

{
  "mcpServers": {
    "plsreadme": {
      "command": "npx",
      "args": ["-y", "plsreadme-mcp"],
      "env": {
        "PLSREADME_API_KEY": "${env:PLSREADME_API_KEY}"
      }
    }
  }
}

VS Code: .vscode/mcp.json に追加：

{
  "inputs": [
    {
      "type": "promptString",
      "id": "plsreadme-api-key",
      "description": "plsreadme personal API key",
      "password": true
    }
  ],
  "servers": {
    "plsreadme": {
      "command": "npx",
      "args": ["-y", "plsreadme-mcp"],
      "env": {
        "PLSREADME_API_KEY": "${input:plsreadme-api-key}"
      }
    }
  }
}

Claude Desktop: claude_desktop_config.json に追加：

{
  "mcpServers": {
    "plsreadme": {
      "command": "npx",
      "args": ["-y", "plsreadme-mcp"],
      "env": {
        "PLSREADME_API_KEY": "<paste-your-personal-api-key>"
      }
    }
  }
}

Windsurf: ~/.codeium/windsurf/mcp_config.json に追加：

{
  "mcpServers": {
    "plsreadme": {
      "command": "npx",
      "args": ["-y", "plsreadme-mcp"],
      "env": {
        "PLSREADME_API_KEY": "${env:PLSREADME_API_KEY}"
      }
    }
  }
}

注意点：

ローカルstdioはデフォルトで PLSREADME_API_KEY を期待するため、新しいドキュメントは所有権が設定されます。
明示的なレガシー匿名モードは PLSREADME_ALLOW_ANONYMOUS=1 で引き続き存在します。
https://plsreadme.com/my-links からキーを作成してください。

既存の匿名MCP設定の移行

すでに plsreadme-mcp を匿名で使用していた場合：

/my-links から個人用APIキーを作成します。
MCPクライアント設定に PLSREADME_API_KEY を追加します。
PLSREADME_ALLOW_ANONYMOUS=1 は、古いワークフローの一時的な互換性維持のためだけに保持してください。
古い匿名リンクの admin_token をまだ持っている場合は、後で /api/auth/claim-link で請求してください。

移行ルールはシンプルです：

新しい自動作成/エディター作成はデフォルトで所有権が設定されるべきです。
匿名ローカルMCPは現在レガシー専用であり、明示的です。
ウェブサイトのデモパスは、エディター認証が厳格化されてもゼロ設定のままです。

add-m

Available Tools

5 tools

plsreadme_deleteA

Destructive

Delete a plsreadme document permanently.

Requires either the document ID or the original file path. Looks up the admin token from the local .plsreadme record file.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Document ID to delete.
`file_path`	No	Original file path (looks up the linked doc).

TDQS

A4.2/5.0

Behavior4/5

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

Annotations mark destructiveHint=true. The description adds that deletion is 'permanently' and reveals that the tool 'Looks up the admin token from the local .plsreadme record file,' which is a behavioral dependency beyond the annotations.

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 succinct sentences: first states the primary action, second provides key constraints. No unnecessary words or repetition. Every sentence adds value.

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 delete tool with no output schema, the description covers the core action, permanence, and a prerequisite. The token lookup detail is helpful. It could mention error handling or confirmation, but overall is adequate for an agent.

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 coverage is 100% with both parameters having descriptions. The description adds the critical constraint that 'Requires either the document ID or the original file path,' clarifying that they are alternatives, which the schema's optionality does not convey.

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 action: 'Delete a plsreadme document permanently.' The verb 'Delete' and the resource 'plsreadme document' are specific. The description distinguishes from siblings (list, share, update) as there is no other delete tool.

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 provides a usage prerequisite: requires either document ID or file path. However, it does not specify when not to use this tool or offer alternatives to alternatives to deletion. The guidance is minimal but present.

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

plsreadme_listA

Read-onlyIdempotent

List all plsreadme documents tracked in the local .plsreadme file.

Shows document IDs, titles, URLs, and source files.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the detail that it reads from a local file, which is useful but not essential beyond the annotations.

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 extremely concise with two sentences that front-load the core action. Every word serves a purpose, and there is no extraneous information.

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 list operation with no parameters and no output schema, the description adequately covers behavior (lists all documents) and return fields. It does not mention sorting or pagination, but given the tool's simplicity, this is acceptable.

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?

There are no parameters in the input schema, so the description does not need to add parameter details. Schema coverage is 100% by default, and the description provides no contradictory or missing information.

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 specifically states the action (list all documents), the resource (plsreadme documents tracked in the local .plsreadme file), and the output fields (IDs, titles, URLs, source files). It clearly distinguishes from sibling operations like delete, share, and update.

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

Usage Guidelines2/5

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 its siblings. There is no mention of prerequisites or alternatives, leaving the agent to infer context from the tool name alone.

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

plsreadme_share_fileB

Read-only

Share a local markdown file as a clean, readable web link on plsreadme.com.

Reads the file, uploads it, and returns a permanent shareable URL. If the file was previously shared, updates the existing link instead of creating a new one.

Tracks links in a local .plsreadme file for future edits and deletes.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to the markdown file to share (relative or absolute).

TDQS

B3.4/5.0

Behavior1/5

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

The description contradicts the annotation 'readOnlyHint=true' by stating it uploads the file and may update existing links, indicating a write operation. This is a serious inconsistency, so score 1 as per rules.

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?

Four concise sentences, no redundant information. The first sentence captures the primary purpose, and each subsequent sentence adds relevant detail without excess.

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 single-parameter tool with no output schema, the description adequately covers the main behavior: reading, uploading, updating if previously shared, and tracking links. It lacks details on error cases or URL format, but overall sufficient.

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 coverage is 100% and the parameter 'file_path' is well-described in the schema. The description adds context about reading and uploading the file, but does not significantly add meaning beyond the schema. Baseline 3 applies.

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 shares a local markdown file as a web link, with specific verb 'Share' and resource 'local markdown file'. It distinguishes from siblings like 'share_text' (which shares raw text) and 'update' (which updates existing links).

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 markdown file needs sharing, and mentions updating existing links. However, it does not explicitly exclude other use cases or provide guidance on when not to use this tool versus alternatives like 'share_text' or 'update'.

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

plsreadme_share_textA

Read-only

Share text as a clean, readable web link on plsreadme.com.

Accepts markdown or plain text. Plain text is auto-structured into markdown before upload. Returns a permanent shareable URL.

Tracks links in a local .plsreadme file for future edits and deletes.

ParametersJSON Schema

Name	Required	Description	Default
`markdown`	Yes	Content to share. Markdown preferred, but plain text accepted.
`title`	No	Optional title (auto-detected from first H1 if omitted).

TDQS

A3.8/5.0

Behavior1/5

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

Annotations set readOnlyHint=true, but the description describes creating a share link and tracking in a local file, which contradicts that. Description adds context about tracking but fails to resolve the contradiction.

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?

Three concise sentences with no wasted words, front-loaded with the main purpose.

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?

No output schema, but description mentions the return value (permanent URL) and tracking behavior, covering key aspects. Lacks mention of rate limits or authentication, but acceptable for a simple tool.

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 coverage is 100%, but description adds value by stating markdown is preferred but plain text accepted, and title is auto-detected if 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 clearly states the tool shares text as a clean web link, accepts markdown or plain text, and distinguishes from siblings like share_file which handles files.

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 explains when to use it (to share text) and implies alternatives by naming siblings, but lacks explicit when-not-to-use or exclusion criteria.

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

plsreadme_updateA

Idempotent

Update an existing plsreadme document with new content.

Requires either the document ID or the original file path. Looks up the admin token from the local .plsreadme record file.

ParametersJSON Schema

Name	Required	Description
`id`	No	Document ID to update.
`file_path`	No	Original file path (looks up the linked doc).
`markdown`	Yes	New markdown content.

TDQS

A4.4/5.0

Behavior4/5

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

Adds context beyond annotations: authentication via local file, alternative identifiers. Consistent with idempotentHint=true and readOnlyHint=false. No contradictions.

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 sentences, first states action, second details requirements. No redundant information, highly efficient.

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?

Covers action, required params, and identification method. Lacks error handling details or return type, but sufficient for a simple update tool with idempotent hint.

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 coverage is 100%, baseline 3. Description adds meaning by clarifying id and file_path are alternatives, not both required. Enhances understanding of parameter relationships.

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 verb 'Update' and the resource 'existing plsreadme document'. It distinguishes this tool from siblings (delete, list, share) by specifying content update.

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?

Provides guidance on required parameters (either id or file_path) and mentions a prerequisite (admin token lookup). Could explicitly state when to use vs alternatives, but siblings are distinct actions.

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.

5 tool updatesv1.0.1May 4, 2026
- Addedplsreadme_delete
- Addedplsreadme_list
- Addedplsreadme_share_file
- Addedplsreadme_share_text
- Addedplsreadme_update

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-04 00:35 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: delete, list, share file, share text, update. There is no ambiguity as descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow the consistent pattern 'plsreadme_verb' with verbs like delete, list, share_file, share_text, update. Naming is uniform and predictable.

Tool Count5/5

With 5 tools covering the core operations of sharing, listing, updating, and deleting documents, the count is well-scoped and appropriate for the service's purpose.

Completeness4/5

The tool set offers full CRUD-like coverage (create via share, read via list, update, delete) but lacks a direct 'get by ID' tool, though list provides IDs and URLs.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

artidrop A
ai.artidrop
Publish HTML, Markdown, and multi-file sites as shareable URLs instantly via MCP.
Content Management Systems Developer Tools
42
mkdshare.DEV A
io.github.PhilipAnd
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Content Management Systems Documentation Access Developer Tools
112
SlidelessOAuth
ai.slideless
List, share, upload, and manage Slideless HTML presentations from any MCP host.
Content Management Systems Workplace & Productivity
2
Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259

Related MCP Servers

rustypaste-mcp-server
File Systems Cloud Storage App Automation
rukh-debug
F
license
A
quality
D
maintenance
An MCP server that wraps the rustypaste API, allowing users to upload text, files, and URLs to a rustypaste instance. It supports features such as single-use links, file expiration, and URL shortening.
Updated 6 months ago (2026-03-06 03:44 UTC)
7
29 npm
-
slideless-mcpofficial
Content Management Systems Workplace & Productivity
slideless-ai
F
license
Not graded
quality
C
maintenance
MCP server that wraps the Slideless HTTP API as tools for listing, sharing, uploading, and managing HTML presentations from any MCP host without installing the CLI.
Updated 3 months ago (2026-06-08 20:16 UTC)
-
PasteAIofficial
Note Taking Content Management Systems
pasteai
A
license
A
quality
B
maintenance
An MCP server that lets AI publish markdown documents to a clean, themed web UI. One tool call creates a shareable doc.
Updated 2 months ago (2026-07-19 05:22 UTC)
8
4
MIT
wiki-mcp
Note Taking File Systems Knowledge & Memory
icarus-inte01
F
license
Not graded
quality
D
maintenance
MCP server for managing a personal markdown wiki. Provides search, navigation, read, write, delete, and move tools with automatic index.md management.
Updated 3 months ago (2026-06-16 15:23 UTC)
-

Appeared in Searches

Markdown MCP (Model Context Protocol) Server

課題

✨ 機能

🚀 クイックスタート

ウェブ

認証パスとロールアウト状況

API

バージョンタイムライン + 安全な復元

レビューモードの使用上の注意（現在のドラフト優先、タイムラインはオンデマンド）

MCP (AIエディター)

/versions を使用したMCP/エージェントの自動レビューループ

🔌 MCP設定

クライアント互換性マトリックス

ホスト型リモートログイン（対応クライアント）

ホスト型リモートAPIキーフォールバック

ローカルnpmフォールバック

既存の匿名MCP設定の移行

add-m

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

slideless-mcpofficial

PasteAIofficial

Appeared in Searches

`/versions` を使用したMCP/エージェントの自動レビューループ