Skip to main content
Glama

write_clipboard

Places specified text on the system clipboard for pasting into other apps. Use it when an agent needs to copy text for manual or automated reuse.

Instructions

Write text to the system clipboard.

Input Schema

NameRequiredDescriptionDefault
textYes
backgroundNoDeliver in the background to the captured window's process (native apps only). Default false = foreground.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • removedInput schema / title
      Removed value: -"TypeParams"
  2. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and falls short. It does not say whether the write overwrites or appends to existing clipboard content, what happens on failure or when the clipboard is unavailable, or whether it works in headless/non-native contexts.

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?

A single short, front-loaded sentence with zero waste. It is efficient, though the brevity edges toward under-specification for a tool with a non-obvious background flag.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, no-output-schema tool, the description is minimal but workable. It leaves key behaviors (clipboard replacement semantics, background flag impact from the caller's perspective, failure modes) to inference, which is a modest gap for an operation that mutates shared system state.

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 50%: the background parameter is documented in the schema (background flow / native apps only), but the required text parameter has no description. The description's 'write text' implicitly maps to it but adds no format, length, or encoding detail beyond what the schema already implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb+resource pair: write to the system clipboard. It is unambiguous about what the tool does. However, it offers no differentiation from the sibling read_clipboard, so an agent gets no explicit routing signal beyond the obvious naming.

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?

There is no when-to-use guidance and no mention of alternatives or the sibling read_clipboard. Usage can be inferred from the name, but the description provides nothing explicit about context, prerequisites, or exclusions.

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