Skip to main content
Glama
CrossPaste

CrossPaste

Official
by CrossPaste
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_to_clipboard

Append text, URLs, HTML, files, or images to CrossPaste's local clipboard history for later retrieval, without altering the system clipboard.

Instructions

Create a new item in the local clipboard history. This only appends to CrossPaste's history: it does not change the system clipboard and the item is not sent to other devices. Every call creates a new item, even for duplicate content, recorded with source 'MCP'. 'type' defaults to 'text'; supported types: text, url, html, rtf, color, file, image. For file/image, 'content' must be the absolute path of an existing file on this machine (images: png, jpg, jpeg, gif, bmp, webp, heic, heif, tiff, svg); the file is referenced by path, not copied. For color, 'content' may be #RGB, #RRGGBB, #RRGGBBAA, rgb(), rgba(), hsl(), hsla() or a CSS color name. html must contain extractable text and rtf must start with '{\rtf'. On success returns the new item's ID (usable with get_paste_item); on invalid input returns an error and nothing is stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoContent type: 'text' (default), 'url', 'html', 'rtf', 'color', 'file', 'image'. Unrecognized values are treated as 'text'.
contentYesThe content to store, interpreted according to 'type': plain text, a URL, an HTML or RTF document, a color value (e.g. #FF0000), or the absolute path of a file/image. Must not be blank.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.2.1
    • changedInput schema / properties / content / description
      Previous value: -"The content to add. Text/URL/HTML/RTF as string, color as color value (e.g. #FF0000), file/image as absolute file path"New value: +"The content to store, interpreted according to 'type': plain text, a URL, an HTML or RTF document, a color value (e.g. #FF0000), or the absolute path of a file/image. Must not be blank."
    • changedInput schema / properties / type / description
      Previous value: -"Content type: 'text' (default), 'url', 'html', 'rtf', 'color', 'file', 'image'"New value: +"Content type: 'text' (default), 'url', 'html', 'rtf', 'color', 'file', 'image'. Unrecognized values are treated as 'text'."
  2. First observedv2.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare the write/non-idempotent/non-destructive profile, and the description adds genuinely new behavioral facts: every call creates a new item even for duplicate content, the source is recorded as 'MCP', files are referenced by path rather than copied, and invalid input stores nothing. That is exactly the beyond-annotation context an agent needs.

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 with the purpose and the two key exclusions, then organized by parameter. It is long, but nearly every clause is a functional constraint rather than filler; only the extension enumeration is mildly list-heavy for a description block.

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?

With no output schema, the description correctly covers the return contract (new item ID usable with get_paste_item) and the error path (invalid input stores nothing). Combined with the type-specific rules, an agent has everything needed to call it correctly.

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?

Schema coverage is already 100%, so the baseline would be 3, but the description substantially exceeds it: per-type constraints (html must contain extractable text, rtf must start with '{\rtf'), the accepted image extensions, and the full color syntax list. These are validation rules the schema does not carry.

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?

Opens with a specific verb+resource ('Create a new item in the local clipboard history') and immediately scopes it against the obvious misreadings: does not touch the system clipboard and is not synced to other devices. An agent can distinguish this from get_paste_item and search_clipboard without reading 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 Guidelines4/5

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

Clear context for when this tool applies (appending to CrossPaste history, not system clipboard) and it names get_paste_item as the consumer of the returned ID. It lacks an explicit 'use this instead of X' routing statement against siblings like search_clipboard, but the exclusion of system-clipboard semantics removes the main ambiguity.

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

Deploy Server

Other Tools