Skip to main content
Glama

clipboard

Read or write Windows system paste-buffer text. Writes replace existing content and verify delivery by reading it back.

Instructions

Read or write the Windows clipboard. action='read' returns current text content (empty string if non-text). action='write' replaces clipboard with given text and verifies delivery by reading the clipboard back and comparing the bytes (UTF-16LE) for exact equality. Caveats: Non-text clipboard payloads (images, files) return empty string on read. Reading text larger than about 8MB (roughly 4 million characters, far above anything this tool can write) is refused immediately rather than copied. Calls give up after 4s (read) / 5s (write) — the usual cause is that the application owning the clipboard has stopped responding, which blocks the clipboard for every application on the machine, so retrying does not help until it recovers or is closed. A write that gives up leaves the clipboard in an indeterminate state (it may still complete once that application recovers), unlike code:'ClipboardWriteNotDelivered' where the write is known not to have landed — re-read before relying on the contents. Overwrites existing clipboard content on write. action='write' delivery-verification failure returns code:'ClipboardWriteNotDelivered' — typical causes: a third-party clipboard manager intercepts SetClipboardData, DLP / endpoint protection blocks the payload, RDP / Citrix clipboard transcoding strips the text, or another process clears the clipboard between Set and the read-back. Recovery: retry the write, or fall back to keyboard(action='type', use_clipboard=false) for short text. On builds without the native addon (backend:'powershell') writes are additionally capped at about 12000 characters and return code:'ClipboardWriteTooLargeForFallback' above it. Diagnostics: every response reports backend:'native'|'powershell' — the implementation that served the call. A successful write adds postCloseChecked: whether the read that catches a clipboard manager swapping the payload actually ran (native uses a separate second read; powershell's single read-back is that read), plus postCloseSkipReason when it did not run. On backend:'native' only, a successful write also reports sequenceAfterWrite (a Windows clipboard sequence number, for diagnosis only — the delivery verdict is always the byte comparison) and, when the post-close read alone confirmed the write, inSessionReadable:false. Examples: clipboard({action:'write', text:'hello'}) → write+verify; clipboard({action:'read'}) → returns current text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoText to place on the clipboard
actionYesAction selector — one of: read, write. Per-action required fields are enforced at call time (see the tool description); this flat schema lists every action's fields as optional.
includeNoOptional response-shape opt-in. `['envelope']` returns the self-documenting envelope (`_version` / `data` / `as_of` / `confidence`). `['raw']` forces raw shape (overrides DESKTOP_TOUCH_ENVELOPE=1 server default). Default behaviour is raw shape (compat with existing clients).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.1
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv1.12.0
  3. Removedv1.10.4
  4. Addedv1.9.2
  5. Removedv1.8.0
  6. Addedv1.6.0
  7. Removedv1.5.1
  8. Addedv1.5.0
  9. Removedv1.4.3
  10. Addedv1.4.2
  11. Removedv1.4.0
  12. Changed1 schema field changedv1.2.1
    • changedInput schema / oneOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "action": {
      -        "const": "read"
      -      }
      -    },
      -    "required": [
      -      "action"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "action": {
      -        "const": "write"
      -      },
      -      "text": {
      -        "description": "Text to place on the clipboard",
      -        "maxLength": 100000,
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "text"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "action": {
      +        "const": "read"
      +      },
      +      "include": {
      +        "description": "Optional response-shape opt-in. `['envelope']` returns the self-documenting envelope (`_version` / `data` / `as_of` / `confidence`). `['raw']` forces raw shape (overrides DESKTOP_TOUCH_ENVELOPE=1 server default). Default behaviour is raw shape (compat with existing clients).",
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "action"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "action": {
      +        "const": "write"
      +      },
      +      "include": {
      +        "description": "Optional response-shape opt-in. `['envelope']` returns the self-documenting envelope (`_version` / `data` / `as_of` / `confidence`). `['raw']` forces raw shape (overrides DESKTOP_TOUCH_ENVELOPE=1 server default). Default behaviour is raw shape (compat with existing clients).",
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      },
      +      "text": {
      +        "description": "Text to place on the clipboard",
      +        "maxLength": 100000,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "action",
      +      "text"
      +    ],
      +    "type": "object"
      +  }
      +]
  13. Addedv1.0.3

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the entire behavioral burden and does so thoroughly: byte-level (UTF-16LE) write verification, 4s/5s timeouts and why retrying is futile, indeterminate vs known-failed write states, distinct error codes, non-text payload behavior, and the backend-specific 12000-char fallback cap. This is exactly the context an agent needs to interpret results and avoid blind retries.

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

Conciseness3/5

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

The first two sentences are well front-loaded, but the body becomes a very long run-on covering diagnostics like sequenceAfterWrite, postCloseChecked, and inSessionReadable that are closer to release notes than call guidance. For a 2-action, 3-parameter tool this is over-sized even though most individual clauses are substantive.

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?

No output schema exists, yet the description fully specifies return shapes, per-response fields (backend, postCloseChecked, sequenceAfterWrite), and error codes, plus caveats and recovery. Nothing an agent needs to call this correctly or interpret its result is missing.

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%, so baseline is 3, but the description adds semantics the schema does not: what action='read' actually returns (empty string for non-text/oversize), that write replaces existing content, and that effective text limits differ by backend (12000 chars on powershell vs the schema's nominal 100000 maxLength). That extra meaning lifts it above baseline.

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: 'Read or write the Windows clipboard,' then immediately disambiguates the two modes by their observable effect (read returns text, write replaces and verifies). An agent can distinguish this from the keyboard sibling purely from the description.

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?

Gives explicit recovery routing — retry the write or fall back to keyboard(action='type', use_clipboard=false) for short text — and specifies when reads of oversize text are refused. It is strong on failure-path guidance, though it never states the general condition for preferring clipboard over other input methods in the first place.

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