Skip to main content
Glama
BogdanStamenovic

use-computer-mcp

clipboard

Destructive

Retrieve the current copied text or replace it with new text to manage the desktop's copy-paste buffer.

Instructions

Read or replace the clipboard text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoset: new clipboard text
actionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations declare destructiveHint=true, which aligns with the 'replace' operation overwriting clipboard contents. The description adds the read/write distinction that the schema enum implies, but it does not disclose further side effects, such as the clipboard affecting other applications. With destructive hint already present, the added value is modest but acceptable.

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

Conciseness5/5

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

One short sentence, front-loaded with the verb and resource, with zero filler. The brevity is well suited to a simple two-action tool.

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?

There is no output schema, so the description carries the burden of explaining results. 'Read' implies returning clipboard text, but the return format is not explicit, and there is no mention of what 'set' returns. For a simple tool with a destructive annotation, this is a minor but real gap.

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 description coverage is 50%: 'text' is documented as 'set: new clipboard text', while 'action' only has an enum. The description adds semantic meaning by mapping get→read and set→replace, helping the agent understand the action parameter. However, it does not clarify that text is ignored for get or required for set, so compensation is partial.

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 uses specific verbs 'read' and 'replace' tied to the 'clipboard text' resource, and these map directly to the get/set actions in the schema. It does not explicitly name a sibling alternative, but no sibling tool appears to handle clipboard operations, so ambiguity is low.

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 guidance about when to use this tool versus alternatives like computer, form_input, or session. No exclusions, prerequisites, or context cues are provided beyond the action enum, leaving the agent to infer use cases.

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