Skip to main content
Glama
Sign In
OpenCU

OpenCU

by Daily-AC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

paste

Inserts text, Markdown, or HTML into the focused app field, supports Unicode and multiline content, verifies the result, and restores the clipboard unless another app changed it.

Instructions

Paste text, Markdown, or HTML into the focused field (Windows and Linux: plain text only). Prefer this for Unicode or multiline text. Verify focus and the resulting value. Restores the previous clipboard unless another app changed it during the operation. Returns the updated accessibility state after the action; a separate text-only get_app_state is normally unnecessary. Request a new screenshot before later coordinate input.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app": "<app>",
      "text": "<text>",
      "format": "<format>"
    },
    "name": "paste"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesApp name or full app path; macOS bundle ID; macOS and Windows pid:<pid>; Windows process name, window title fragment, or Start-menu shortcut name; Linux desktop entry name, executable name or window title fragment
textYes
scopeNomacOS and Windows: element index from the latest returned state. Read only its retained subtree, renumbered from [1], including after actions. If it disappears, return the whole window with a notice. Linux returns INVALID_ARGUMENT.
formatYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint=false and openWorldHint=true, the description discloses platform-specific behavior (Windows/Linux lose md/html), clipboard side effects with a restore caveat, and the post-action accessibility state return. These are non-obvious traits an agent could not derive from annotations or schema.

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-loads the action, then formats, then platform caveat, then verification and return behavior. Dense but every sentence carries operational information; the clipboard-restore caveat and screenshot rule are the only near-parenthetical items.

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

Completeness4/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 supplies the return value ('updated accessibility state') and the platform and clipboard side effects. The remaining gap is the undocumented scope parameter, which an agent needs to use subtree-scoped pasting correctly.

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% (app and scope described, text and format bare). The description explains what the text payload may contain and maps to the format enum, but says nothing about scope, whose element-index semantics are the least intuitive parameter. Baseline 3 fits given the schema does most of the work.

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?

States a specific verb and resource ('Paste ... into the focused field'), names the accepted payload formats, and implicitly separates itself from type_text by recommending itself for Unicode/multiline content. An agent can choose it over type_text or set_value without opening the 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?

Gives clear usage conditions ('Prefer this for Unicode or multiline text'), a prerequisite ('Verify focus and the resulting value'), and a follow-up rule ('Request a new screenshot before later coordinate input'). It also dismisses an alternative ('a separate text-only get_app_state is normally unnecessary'), though it never states explicit when-not-to-use cases.

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