de en es ja ko ru zh

plsreadme

Name: plsreadme
Author: FacundoLucci

by FacundoLucci

Overview Schema Source Related Servers Discussions Admin

TypeScript

Das Problem

Du hast eine README, ein PRD, Besprechungsnotizen oder eine API-Dokumentation in Markdown geschrieben. Jetzt musst du sie mit jemandem teilen, der keinen Markdown-Renderer hat, GitHub nicht nutzt oder einfach einen sauberen Link benötigt, den er im Browser öffnen kann.

plsreadme verwandelt jedes Markdown in einem Schritt in eine dauerhafte, schön gerenderte Webseite. Keine Konten. Keine Registrierungen. Keine Reibungsverluste.

Related MCP server: slideless-mcp

✨ Funktionen

Sofortiges Teilen — Markdown einfügen oder Datei hochladen, einen plsrd.me-Link erhalten
Schönes Rendering — Saubere Typografie, Dark Mode, mobil-responsiv
Inline-Kommentare — Leser können auf jeden Absatz klicken und Feedback hinterlassen
Review-Modus (Aktuell vs. Zeitstrahl) — Dokumente mit mehreren Versionen zeigen standardmäßig Feedback zum aktuellen Entwurf mit Ein-Klick-Zugriff auf die vollständige Zeitstrahl-Historie
KI-Auto-Formatierung — Wirf rohen Text hinein; er kommt als sauberes Markdown heraus
MCP-Server — Teile Dokumente direkt aus Claude, Cursor, VS Code oder jedem MCP-Client
OpenClaw-Skill — Verfügbar auf ClawHub für KI-Agenten-Workflows
Kurz-Links — Jedes Dokument erhält eine kompakte plsrd.me/v/xxx-URL
Raw-Zugriff — Lade die ursprüngliche .md-Datei von jedem geteilten Link herunter
Versions-Zeitstrahl + sichere Wiederherstellung — /v/:id/versions + /v/:id/history + Archiv-zuerst-Wiederherstellungs-API für schnelles Rollback
Clerk-Auth-Grundlage — GitHub/Google-Anmeldung + Clerk-gehostetes E-Mail-Fallback + Backend-Auth-Verifizierungs-Utilities
Eigentumsmodell (Phase 2) — Dokumente können mit einem Clerk-Benutzer (owner_user_id) verknüpft werden, während anonyme Abläufe erhalten bleiben
Meine Links-Dashboard (Phase 3) — Authentifizierte /my-links-Seite mit Suche/Sortierung/Paginierung und Aktionen zum schnellen Kopieren/Öffnen
Beanspruchung von Legacy-Links (Phase 4) — Angemeldete Benutzer können ältere anonyme Links beanspruchen, indem sie das ursprüngliche admin_token nachweisen
Zero-Config-Website-Demo — Kein Konto oder API-Schlüssel erforderlich, um es im Browser auszuprobieren

🚀 Schnellstart

Web

Gehe zu plsreadme.com, füge dein Markdown ein, klicke auf Teilen.

Auth-Pfade und Rollout-Status

Empfohlene Reihenfolge:

Zuerst im Browser ausprobieren — schnellster Demo-Pfad, keine MCP-Einrichtung erforderlich.
Gehostetes Remote-MCP mit Browser-Login verwenden, wenn die Client-Unterstützung verifiziert ist.
API-Schlüssel / lokales MCP-Fallback verwenden, wenn interaktives Login nicht verfügbar ist.

Aktueller Rollout-Status:

Reise	Status heute	Eigentumsregel
Anonyme Website-Demo	Jetzt verfügbar über browser-verifizierten Demo-Ablauf	`owner_user_id = NULL`, bis der Benutzer das Dokument später speichert/beansprucht
Angemeldete Website-Erstellung	Jetzt verfügbar	Dokument wird mit dem angemeldeten Clerk-Benutzer als Eigentümer erstellt
Gehostetes Remote-MCP mit Browser-Login	Jetzt verfügbar in unterstützten Clients	erstellt Dokumente im Besitz des angemeldeten Benutzers nach Browser-Login
Gehostetes Remote-MCP mit API-Schlüssel	Jetzt verfügbar als Kompatibilitäts-Fallback	erstellt Dokumente im Besitz des API-Schlüssel-Eigentümers
Lokales npm-MCP mit API-Schlüssel	Jetzt verfügbar und empfohlen für lokale stdio-Setups	erstellt Dokumente im Besitz des API-Schlüssel-Eigentümers
Lokales npm-MCP anonymes Fallback	Nur noch mit explizitem Opt-in verfügbar	bleibt anonym, sofern nicht später beansprucht/gespeichert

Hinweise zum gehosteten Remote-MCP-Rollout:

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

Diese gehosteten Remote-MCP-Routen sind im Code hinter einem OAuth-geschützten Browser-Login live, einschließlich /authorize, /oauth/token und /oauth/register.

Betriebliche Hinweise:

D1 doc_create_events ist die kanonische Tabelle für die Erstellungszuordnung über Web-, gehostete MCP- und lokale MCP-Abläufe hinweg.
docs.raw_view_count verfolgt jeden Render-Aufruf, während docs.view_count für wahrscheinlich menschliche Aufrufe reserviert ist.
Siehe docs/runbooks/auth-surface-monitoring.md für das Produktions-Abfrageset und die Reaktionsschritte.
Zugriffstokens halten etwa 1 Stunde
Refresh-Tokens halten etwa 30 Tage
Das erneute Verbinden desselben Clients ersetzt die ältere Berechtigung
Das Abmelden von der Website widerruft nicht von selbst eine bestehende Editor-Berechtigung
Dieses Repo ist jetzt mit einer dedizierten Cloudflare Workers KV-Bindung namens OAUTH_KV verbunden

Wenn das Browser-Login in deinem Client nicht verfügbar ist, erstelle einen persönlichen API-Schlüssel unter /my-links und verwende entweder das gehostete Remote-Header-Fallback oder das lokale npx -y plsreadme-mcp-Paket.

Vertrauensmodell der Website-Demo heute:

Anonyme Website-Erstellungen unter /api/create-link erfordern eine kurzlebige Browser-Verifizierungsberechtigung
Angemeldete Website-Erstellungen überspringen diese Berechtigung und bleiben reibungsarm
Die UI nach der Erstellung verzweigt jetzt in In meinem Konto speichern, Editor verbinden und Link kopieren

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_..."
}

Speichere das admin_token — du wirst es zum Bearbeiten oder Löschen benötigen:

# 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_..."

Versions-Zeitstrahl + sichere Wiederherstellung

Verwende den Zeitstrahl-Endpunkt, um den Revisionskontext während KI-Iterationszyklen zu überprüfen:

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" }
  ]
}

Wenn eine KI-Bearbeitung das Dokument verschlechtert, stelle einen früheren Schnappschuss wieder her (Archiv-zuerst, nicht destruktiv):

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

Die Wiederherstellung ist ähnlich wie Aktualisierungen ratenbegrenzt (derzeit 60/Stunde pro Akteur-Schlüssel), um Missbrauch zu reduzieren.

Für Dokumente, die einem authentifizierten Clerk-Benutzer gehören, erfordern Aktualisieren/Löschen/Wiederherstellen auch diese Eigentümer-Sitzung (um eine Mutation durch andere Benutzer zu verhindern), während anonyme Dokumente weiterhin nur mit admin_token funktionieren.

Hinweise zur Verwendung des Review-Modus (Zuerst aktueller Entwurf, Zeitstrahl auf Anfrage)

Der Dokumenten-Viewer bietet jetzt Kontrollen für die Kommentarüberprüfung:

Aktueller Entwurf — zeigt nur Kommentare, die mit der neuesten Dokumentversion verknüpft sind (Standard, wenn ein Dokument mehrere Versionen hat).
Zeitstrahl — zeigt die vollständige Kommentarhistorie über alle Versionen hinweg.

Du kannst dieselben Modi direkt über die API abrufen:

# 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"

Viewer-Links behalten den Modus in der URL für teilbaren Review-Kontext bei:

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

Um einen Legacy-Anonym-Link in dein angemeldetes Konto zu beanspruchen:

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 (KI-Editoren)

Aktuelle Empfehlung heute:

Verwende gehostetes Remote-MCP mit Browser-Login, wenn dein Client dies sauber unterstützt
Verwende das persönliche API-Schlüssel-Fallback, wenn Remote-Auth nicht verfügbar oder umständlich in diesem Client ist
Verwende das lokale plsreadme-mcp-Paket mit PLSREADME_API_KEY für den sichersten stdio-Pfad

Verbinde deinen Editor mit plsreadme und teile Dokumente mit natürlicher Sprache:

"Teile diese README als plsreadme-Link" "Verwandle mein PRD in eine teilbare Seite" "Mache diese Besprechungsnotizen zu einem lesbaren Link"

MCP/Agenten-Auto-Review-Schleife mit `/versions`

Für iterative KI-Schreibabläufe (Entwurf → Kritik → Überarbeitung) können Agenten /v/:id/versions als Quelle der Wahrheit nutzen:

Behalte die kanonische lesbare URL (/v/:id) für Menschen bei.
Polle /v/:id/versions zwischen den Iterationen.
Vergleiche current_version mit der zuletzt überprüften Version.
Wenn geändert, rufe raw_url für die neueste Version ab und führe Review-Prüfungen durch.
Wenn die Qualität nachlässt, löse optional /v/:id/restore mit Admin-Token + Eigentümer-Sitzung aus.

Dies ermöglicht eine deterministische Revisionsverfolgung durch Automatisierung, ohne HTML zu scrapen.

Siehe docs/ai-iteration-versioning.md für ein vollständiges Playbook.

🔌 MCP-Einrichtung

Client-Kompatibilitätsmatrix

Stand: 5. April 2026:

Client	Empfohlener Pfad	Browser-Login-Unterstützung	API-Schlüssel-Fallback	Hinweise
Claude Code	zuerst gehostetes Remote-MCP	verifiziert live	ja	am besten unterstützter Remote-Ablauf; lokales stdio mit `PLSREADME_API_KEY` funktioniert ebenfalls gut
Cursor	zuerst gehostetes Remote-MCP	dokumentiert, aber in der Praxis build-abhängig	ja	verwende Header, wenn dein Build den OAuth-Prompt nicht anzeigt
VS Code	gehostetes Remote-MCP wenn verfügbar	Konfiguration existiert, Rollout variiert je nach Build	ja	`type: "http"` plus Header-Fallback funktioniert, wenn Login-UX fehlt
Windsurf	gehostetes Remote-MCP wenn verfügbar	dokumentierte Remote-Unterstützung	ja	verwende `serverUrl` + Header, wenn Browser-Auth noch nicht exponiert ist
Claude Desktop	lokales npm-MCP	keine verifizierte Remote-Browser-Ablauf hier	ja	bevorzuge stdio + `PLSREADME_API_KEY`
Raw HTTP / Skripte	gehosteter Remote-Header-Modus	nein	ja	sende `Authorization: Bearer $PLSREADME_API_KEY` direkt

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"
    }
  }
}

Lebenszyklus-Hinweise:

Zugriffstoken-TTL beträgt etwa 1 Stunde
Refresh-Token-TTL beträgt etwa 30 Tage
Das erneute Verbinden desselben Clients ersetzt die ältere Berechtigung
Abmelden beendet die Website-Sitzung, widerruft aber nicht automatisch eine bestehende Editor-Berechtigung
Verwende GET /api/auth/mcp-grants und DELETE /api/auth/mcp-grants/:grantId, um gehostete Editor-Berechtigungen zu prüfen oder zu widerrufen

Wenn dein Client Browser-Login unterstützt, bevorzuge diesen Pfad. Es ist die sauberste Einrichtung und hält Dokumente im Besitz automatisch mit deinem Website-Konto verknüpft.

Gehostetes Remote-API-Schlüssel-Fallback

Erstelle zuerst einen persönlichen API-Schlüssel unter https://plsreadme.com/my-links, dann verwende einen dieser Wege:

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-Remote-Endpunkt-Benutzer:

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

Lokales npm-Fallback

Claude Code:

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

Cursor: Füge zu ~/.cursor/mcp.json hinzu:

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

VS Code: Füge zu .vscode/mcp.json hinzu:

{
  "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: Füge zu claude_desktop_config.json hinzu:

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

Windsurf: Füge zu ~/.codeium/windsurf/mcp_config.json hinzu:

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

Hinweise:

lokales stdio erwartet jetzt standardmäßig PLSREADME_API_KEY, damit neue Dokumente im Besitz sind
expliziter Legacy-Anonym-Modus existiert weiterhin mit PLSREADME_ALLOW_ANONYMOUS=1
erstelle deinen Schlüssel unter https://plsreadme.com/my-links

Migration bestehender anonymer MCP-Setups

Wenn du plsreadme-mcp bereits anonym genutzt hast:

Erstelle einen persönlichen API-Schlüssel unter /my-links.
Füge PLSREADME_API_KEY zu deiner MCP-Client-Konfiguration hinzu.
Behalte PLSREADME_ALLOW_ANONYMOUS=1 nur als temporäre Kompatibilitätskrücke für alte Workflows bei.
Beanspruche ältere anonyme Links später mit /api/auth/claim-link, falls du noch deren admin_token hast.

Die Migrationsregel ist einfach:

neue

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

Das Problem

✨ Funktionen

🚀 Schnellstart

Web

Auth-Pfade und Rollout-Status

API

Versions-Zeitstrahl + sichere Wiederherstellung

Hinweise zur Verwendung des Review-Modus (Zuerst aktueller Entwurf, Zeitstrahl auf Anfrage)

MCP (KI-Editoren)

MCP/Agenten-Auto-Review-Schleife mit /versions

🔌 MCP-Einrichtung

Client-Kompatibilitätsmatrix

Gehostetes Remote-Login (unterstützte Clients)

Gehostetes Remote-API-Schlüssel-Fallback

Lokales npm-Fallback

Migration bestehender anonymer MCP-Setups

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

slideless-mcpofficial

PasteAIofficial

Appeared in Searches

MCP/Agenten-Auto-Review-Schleife mit `/versions`