mcp-clipboard

Overview Schema Source Related Servers Discussions Admin

clipboard_copy_markdown

DestructiveIdempotent

Copy markdown to the clipboard as formatted rich text for pasting into Slack, Gmail, or Notion, while keeping plain markdown for text editors.

Instructions

Render markdown to HTML and place both formats on the system clipboard so the user can paste rich text into apps that prefer formatted content (Slack, Gmail, Notion, Word, Google Docs, Discord) AND plain markdown into apps that prefer source (text editors, terminals).

WHEN TO CALL THIS TOOL:

Call this tool when the user wants formatted output to paste into a rich-text target — bulleted lists, headings, links, code, bold/italic emphasis. Examples: "summarize these emails as a list and copy it", "copy this as formatted text", "put this on my clipboard so I can paste it into Slack with formatting", "give me a markdown bullet list and copy it."

For plain text without formatting intent, use clipboard_copy instead.

Args: text: Markdown source. Standard CommonMark syntax (headings, lists, emphasis, code blocks, links, etc.) is rendered to HTML. Raw HTML tags in the source are escaped, not passed through — if you need to write hand-crafted HTML, call clipboard_copy with mime_type="text/html" instead.

Returns: A confirmation message with the input character count and the rendered HTML byte count.

Platform behavior: - macOS and Windows: both text/html and text/plain (the markdown source) land on the clipboard atomically. Each paste target picks the format it prefers — Slack/Gmail/Notion get the rendered HTML; vim/terminal/text editors get the markdown source. - Wayland: wl-copy is single-MIME-per-invocation, so only text/html is set explicitly. However, wl-copy auto-advertises text/plain (and the X-style aliases UTF8_STRING/STRING/TEXT) for UTF-8 content, and the bytes returned for those targets are the rendered HTML markup — NOT the markdown source. A vim user pasting after this tool runs will see <h1>Title</h1>... etc. To get the markdown source on the clipboard, call clipboard_copy with the markdown source directly. - X11: xclip -target text/html -i does NOT auto-advertise additional targets, so apps that only read text/plain see an empty clipboard. Same workaround: call clipboard_copy with the markdown source for a plain-text paste.

Input Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.6.2Oct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructive/readOnly/idempotent, and the description goes well beyond them: atomic dual-format placement on macOS/Windows, the Wayland single-MIME quirk where text/plain returns HTML markup instead of markdown source, and the X11 empty-clipboard failure mode. That is exactly the kind of platform-specific behavioral disclosure annotations cannot carry.

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

Conciseness4/5

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

Front-loaded and organized under clear headers, but the redirect to clipboard_copy is repeated in three separate sections (WHEN TO CALL, Args, and twice under Platform behavior), which adds bulk for a one-parameter tool. Content earns its place but could be tightened.

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?

An output schema exists, yet the description still sketches the return shape (confirmation with input character count and HTML byte count), and it covers platform variance, escaping semantics, and the correct alternative tool. Nothing an agent needs to invoke or recover from this call correctly is missing.

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

Parameters5/5

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

With 0% schema coverage on the single parameter, the description compensates fully: it defines 'text' as CommonMark source, specifies what syntax is supported, and warns that raw HTML is escaped rather than passed through, routing users to clipboard_copy with mime_type=text/html for hand-written HTML.

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 a specific verb+resource (render markdown to HTML, place both formats on the clipboard) and explicitly distinguishes itself from the sibling clipboard_copy by target app type. An agent can select it without opening any schema.

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

Usage Guidelines5/5

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

The 'WHEN TO CALL THIS TOOL' block gives explicit trigger conditions with example utterances, an exclusion ('For plain text without formatting intent, use clipboard_copy instead'), and a further fallback for hand-crafted HTML. Nothing is left to inference.

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

Deploy Server