Skip to main content
Glama
fixed-width

glass

by fixed-width
OverviewSchemaRelated ServersScoreDiscussions
Rust

glass_capabilities

Check which GUI operations (input, clipboard, multi-touch, etc.) are supported on a backend before acting, avoiding unsupported errors. Reports live status and required setup steps.

Instructions

Report which operations (input, multi-touch, clipboard, accessibility, window move/resize) can be performed right now on a backend, and any setup a blocked one needs — so you can check before acting instead of hitting an Unsupported error. Each operation reports a live status (supported, degraded — works now at reduced fidelity, note says what's lost; requires_setup — a setup step is missing, note says what; or unsupported — this backend never does it) plus the tools it gates, so a degraded or blocked operation names exactly which tool calls to expect trouble from. Pass backend to query a specific backend by name; omit for the active one. Static — no session required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
backendNoWhich backend to report: `x11`, `wayland`, `windows`, `macos`, `android`, or `ios`. Omit for the active/default backend (`GLASS_BACKEND`, else the host default). A valid name for a backend not built into this binary reports `available: false`.

Tool Definition Quality

A4.3/5.0
Behavior4/5

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

Discloses live status reporting, return format (status, note, tools), and that it is static with no session required. No annotation contradictions.

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-loaded purpose, each sentence adds value. Slightly lengthy but packed with necessary detail.

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?

Thorough given simple schema and no annotations. Covers return format, parameter usage, and motivation. No output schema needed.

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?

Adds value beyond schema by explaining when to pass backend vs omit. Schema coverage is 100%, so baseline is 3; description elevates it.

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?

Clearly states the tool reports which operations can be performed on a backend and any setup needed. Distinguishes from sibling action tools by focusing on capability checking.

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?

Explicitly advises using this tool before acting to avoid errors. Missing explicit when-not-to-use but purpose is well-contextualized.

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

Install Server

Other Tools

Latest Blog Posts

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/fixed-width/glass'

If you have feedback or need assistance with the MCP directory API, please join our Discord server