CrossPaste
Official
β¨ Features
π Real-time Sharing: Instantly share pasteboard content across devices, seamlessly.
π₯οΈ Unified Cross-platform: Consistent interface on Mac, Windows, and Linux. No need to change habits.
π Rich Type Support: Handle various pasteboard types: Text, Color, URL, HTML, RTF, Image, File.
π End-to-End Encryption: Using asymmetric encryption to fully protect your data security.
π LAN-only Serverless: Local storage, serverless architecture. Privacy protection, in your control.
π§Ή Smart Space Management: Auto-cleanup options manage pasteboard storage without manual effort.
π Built-in OCR: Extract text from images locally β no network calls, your screenshots never leave the device.
π€ MCP Server: Expose your pasteboard history to AI assistants (Claude, etc.) via the Model Context Protocol.
π Chrome Extension: Sync clipboard with the browser β copy on a web page, paste on any device.
β¨οΈ Command-Line: Copy, paste, and search your history from the terminal and scripts. See the CLI guide.
Related MCP server: Claude Paste MCP
π Getting Started with Development
clone the repository
git clone https://github.com/CrossPaste/crosspaste-desktop.gitCompile and run the application
cd crosspaste-desktop ./gradlew app:run
First start will download JBR / gradle dependencies.
If you encounter the following error:
FAILURE: Build failed with an exception.
* What went wrong:
java.net.SocketException: Connection reset
> java.net.SocketException: Connection resetyou might need a VPN to download these dependencies.
To configure a proxy for gradle, add the following settings to gradle.properties, and adjust the parameters to match your proxy configuration:
systemProp.https.proxyHost=localhost
systemProp.https.proxyPort=8080
systemProp.https.proxyUser=userid
systemProp.https.proxyPassword=password
systemProp.http.nonProxyHosts=*.nonproxyrepos.com|localhostAdditionally, a series of technical blogs about CrossPaste is being published (approximately one article per week). If you're interested in developing cross-platform applications, you're welcome to read them.
π Building the Chrome Extension
The Chrome extension lives in web/ and is built via Gradle. Node.js (>= 18) is required β the npmInstall task will fetch dependencies on first build.
Build the extension
./gradlew :web:buildThe unpacked extension is emitted to
web/dist/.Load it into Chrome
Open
chrome://extensions/Enable Developer mode in the top-right corner
Click Load unpacked and select the
web/dist/directory
The extension auto-discovers a CrossPaste desktop app running on the same machine and syncs clipboard content with it. To iterate on extension code, run npm run dev inside web/ for a fast Vite dev loop, then reload the extension in Chrome. The extension imports a Kotlin/JS core library produced by ./gradlew :core:jsBrowserProductionLibraryDistribution (also run as part of :web:build) β re-run that task whenever you change core/ sources.
πΊοΈ Roadmap
CrossPaste is continuously evolving! v2.2 brings a full command-line mode β copy, paste, and search your history straight from the terminal. Here's what we're working on next:
Plugin system β let the community extend CrossPaste with custom paste types and integrations
This is just a small part of our plans. Want to learn more details and long-term plans? Check out our full roadmap.
π FAQ
Here are some FAQs that have been collected. If you have other questions, please create an issue to let us know.
π€ Support the project
π Star this repository: This is the easiest way to support CrossPaste and costs nothing.
πͺ² Report bugs: Report any bugs you find on the issue tracker.
π Translate: Help translate and polish CrossPaste into your language.
π Contribute: Code, comment on issues, and any contributions that can help the project are welcome.
π Sponsor: Support financially via GitHub Sponsors to help with ongoing development and maintenance.
π Contributors
π Sponsors
Available Tools
5 toolsadd_to_clipboardA
Add content to the clipboard history. Supported types: text, url, html, rtf, color, file, image. For file/image, content should be the absolute file path. For color, content can be hex (#FF0000), rgb(), rgba(), hsl(), hsla(), or CSS color name.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Content type: 'text' (default), 'url', 'html', 'rtf', 'color', 'file', 'image' | |
| content | Yes | The content to add. Text/URL/HTML/RTF as string, color as color value (e.g. #FF0000), file/image as absolute file path |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses input format constraints well, including file paths and color representations. However, it does not explain what side effects adding to clipboard history has, such as whether it also changes the system clipboard or only appends to history.
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 front-load the core action and resource, then efficiently provide type-specific usage details. No redundant or filler language is present.
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?
For a simple two-parameter tool with no output schema and no annotations, the description covers all necessary input semantics and format nuances. It is slightly incomplete in that it does not mention return values or post-conditions, but those are not essential for successful invocation.
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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by detailing valid color formats (hex, rgb(), rgba(), hsl(), hsla(), CSS name) and emphasizing absolute file paths for file/image types, which are not fully enumerated in the 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?
The description clearly states the action ('Add content') and resource ('clipboard history'), and enumerates the supported content types. This distinguishes it from sibling tools like search_clipboard, get_paste_item, and get_clipboard_stats, which are read/search operations.
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?
The description provides clear context for what content types are supported and gives format requirements for file/image and color inputs. It does not explicitly contrast with sibling tools, but its write-oriented purpose is obvious alongside read/search siblings, so the intended usage is easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_clipboard_statsA
Get clipboard statistics: total count and size by type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. The verb 'Get' implies a read-only operation, but side effects, permissions, and rate limits are not explicitly addressed. It is reasonably clear but not fully transparent.
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?
The description is a single, focused sentence. It is front-loaded with the action and resource, followed by the key output details, with no unnecessary words.
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?
There is no output schema, and the description gives a useful high-level summary of the return values: total count and size by type. However, it does not specify the exact output format, units for size, or the shape of the 'by type' grouping, so it is not fully complete.
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?
The tool has zero parameters, so there is nothing to document. The schema coverage is vacuously complete, and no parameter explanations are needed.
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?
The description clearly states the tool's purpose: retrieving clipboard statistics. It specifies the resource (clipboard) and the exact scope (total count and size by type), which distinguishes it from siblings like search_clipboard, list_tags, and add_to_clipboard.
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?
The description does not explain when to use this tool versus alternatives. It does not mention that list_tags or search_clipboard should be used for different needs, or provide any decision guidance beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paste_itemA
Get the full content of a specific clipboard item by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The paste item ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It communicates that the operation is a read ('Get') and that the result is the item's full content, but it does not disclose error behavior, permissions, or response formatting. This is minimal but non-zero behavioral information.
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?
The description is a single front-loaded sentence that states the action, target, and selection criterion without wasted words. Every part contributes to understanding.
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?
For a simple one-parameter read tool, the description plus schema gives an agent enough to invoke it correctly with a valid ID. It would be more complete with explicit error/not-found behavior or a note on when to prefer search_clipboard, but those are not critical for basic invocation.
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?
The input schema already describes the single parameter ('The paste item ID') with 100% coverage. The description only restates that lookup is by ID and adds no additional type, format, or constraint details beyond the 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?
The description uses a specific verb ('Get') and resource ('full content of a specific clipboard item'), with a clear retrieval-by-ID scope. This distinguishes it from sibling tools like search_clipboard or get_clipboard_stats.
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?
The description implies the tool is for retrieving a known clipboard item by ID, but it does not explicitly state when to use it over search_clipboard or mention any exclusions. An agent can infer the use case but receives no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tagsA
List all clipboard tags for organizing paste items.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List all' communicates that this is a read-only aggregation of tags, but it does not disclose return format, ordering, or behavior with untagged items. Some essential behavior is conveyed, but the description is thin.
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?
One concise sentence states the action, object, and purpose with no redundant wording. The key verb and resource appear immediately.
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?
For a parameterless list operation with no output schema, the description is largely sufficient: an agent can infer the call is safe and returns clipboard tags. It would benefit from specifying the return type (e.g., array of tag strings), but the low complexity keeps the gap minor.
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?
There are no parameters, so the input schema is complete by definition. The description adds no parameter details, but none are needed; the baseline for zero-parameter tools applies.
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?
The description uses a specific verb ('List') with a clear resource ('all clipboard tags') and a purpose ('organizing paste items'). It is immediately distinguishable from siblings like get_paste_item, search_clipboard, and add_to_clipboard because it targets tags rather than items or stats.
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?
The phrase 'for organizing paste items' gives context for why tags exist, but it does not explicitly state when to choose this tool over siblings or when not to use it. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_clipboardC
Search clipboard history. Returns a list of paste items matching the query.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag name (e.g. 'Favorite') | |
| type | No | Filter by paste type: text, link, image, rtf, html, color, file | |
| limit | No | Maximum number of results (default: 20, max: 100) | |
| query | No | Search keywords (optional, empty returns recent items) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the search action and result type; it does not mention read-only behavior, default limits, sorting, or empty-query behavior. The schema covers some parameter behavior, but the description itself adds little beyond the name.
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?
The description is two short sentences with no filler and the core action is front-loaded. However, the second sentence largely restates the first, adding only the return type.
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?
With no output schema, no annotations, and overlapping sibling tools, the description omits usage distinctions and behavioral details needed for confident tool selection. The parameter schema helps, but the description alone is not sufficient to know when this tool should be preferred over alternatives.
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 description coverage is 100%, so the schema already documents all four parameters. The description only generically references 'the query' and adds no parameter-specific meaning, so the baseline score of 3 is appropriate.
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?
The description clearly identifies the verb (search), the resource (clipboard history), and the return type (list of paste items). It is distinguishable from siblings like get_paste_item and add_to_clipboard by implication, though it does not explicitly name alternatives.
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?
There is no guidance on when to use this tool versus get_paste_item, list_tags, or add_to_clipboard. It also does not mention that query is optional or that an empty query returns recent items; usage context is only implied by the tool name.
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. Dates show when Glama detected each change.
5 tool updates
v2.2.0- First observed
add_to_clipboard - First observed
get_clipboard_stats - First observed
get_paste_item - First observed
list_tags - First observed
search_clipboard
TDQS
Each tool has a clear, distinct purpose: searching, retrieving by ID, getting stats, listing tags, and adding new clipboard entries. No overlap or ambiguity.
All tool names follow a consistent verb-noun pattern (search, get, get, list, add) with clear object references. Minor variation like 'clipboard' vs 'paste_item' is acceptable but still coherent.
Five tools is a well-scoped set for a clipboard manager, covering core actions without unnecessary duplication or bloat.
The tool set covers search, retrieval, addition, stats, and tag listingβcore clipboard operations. It lacks explicit delete/update actions, which are not typical for clipboard history but could be considered a minor gap.
Maintenance
Related MCP Connectors
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
- mcpOAuthai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that gives Claude and other AI assistants access to your Maccy clipboard history, allowing search, retrieval, and management of copied content through natural conversation.9-
- FlicenseAqualityDmaintenanceA Windows-native MCP server that enables users to paste images, Excel tables, rich text, and plain text directly into Claude via a dedicated popup interface. It supports multi-item management and format conversion to streamline sharing complex clipboard data with the model.1-
- AlicenseAqualityBmaintenanceMCP server that reads and writes the system clipboard β tables, text, code, JSON, URLs, images, and more. Preserves spreadsheet structure (rows/columns) that is lost when pasting into Claude directly.45Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA standalone clipboard history MCP server for macOS that monitors clipboard in real-time, stores history locally in SQLite, and exposes it to any MCP-compatible AI assistant.5MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CrossPaste/crosspaste-desktop'
If you have feedback or need assistance with the MCP directory API, please join our Discord server