Skip to main content
Glama

glass_start

Launch a native GUI app and get its window geometry. Use optional title/class hints to locate the right window when several appear or the app hands off to another process.

Instructions

Build, launch, and locate a native GUI app; returns its window geometry. Choose a backend with the backend param (defaults to the host). The accessibility tools are enabled by default; pass a11y:false to skip the accessibility bus for canvas/pixel-only apps. Optional window_hint ({ title?, class? }) picks the right window when several appear, or locates one the launched process hands off to another process.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory for both `build` and the launched app; omit to inherit the server's own.
envNoExtra environment variables, as a `{ "KEY": "VALUE" }` object. They reach the launched app on the desktop backends and on `ios`; on `android` they configure the `build` command on the host only, since an app launched by `am start` is forked from zygote and never sees the shell's environment.
runYesWhat to launch, then its arguments. `run[0]` is the executable on a desktop backend, an `.app` path or bundle id on `ios`, and a `package/.Activity` component — optionally with an `.apk` to install first — on `android`. `run[1..]` are the app's own arguments; `android` has no argument vector to put them in and returns an error rather than ignoring them.
a11yNoSpawn a private accessibility (AT-SPI) bus so `glass_a11y_snapshot` / `marks` / `set_value` / `click_element` / `wait_for_element` work against this app. **On by default** — the accessibility path is the cheap, low-token way to drive a UI, so it is available unless you opt out. Pass `false` to skip the bus for canvas/pixel-only apps (it spawns extra processes). Effective on Linux only; other backends read accessibility ambiently and ignore this flag.
buildNoOptional shell command to run (in `cwd`) before launching.
backendNoBackend to launch under: `"x11"` or `"wayland"` (Linux), `"windows"` (on a Windows host), `"macos"` (on a macOS host), `"android"` (an AVD emulator, any host), or `"ios"` (an iOS Simulator, macOS host). Omit for the server default (`GLASS_BACKEND`, else `windows` on Windows, `macos` on macOS, else x11).
sandboxNoContainment level for the launched app: `"default"` (filesystem/process containment, network on), `"strict"` (also no network), or `"off"` (no containment). Omit for the server default (`GLASS_SANDBOX`, else `default`). An operator-set floor (`GLASS_SANDBOX_FLOOR`) may raise an omitted level, and refuses an explicit level requested below it.
timeout_msNoHow long to wait for the app's window to appear before failing the launch (default 10000ms). Does not bound `build`.
window_hintNoOptional `{ title?, class? }` to disambiguate which window is the app's when more than one appears, or to find a window the launched process hands off to an unrelated process. Omit to take the first window owned by the launched process or a descendant it can follow.
Behavior4/5

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

With no annotations, the description must disclose side effects and behavior. It discloses the a11y default and how to opt out, window_hint behavior, and the fact that it returns window geometry. However, it does not mention potential side effects of the build command or sandbox defaults, which are only in the schema.

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?

Four sentences, front-loaded with the primary action, then key decision points. No fluff or redundancy.

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?

The description covers the main purpose, backend choice, a11y opt-out, and window disambiguation, which addresses the most complex aspects. However, without an output schema, it does not specify the structure of the returned window geometry; overall it is sufficient for a well-documented schema.

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 100%, so the baseline is 3. The description repeats key parameters like backend, a11y, and window_hint but does not add meaningful information beyond the schema's detailed descriptions; it mainly summarizes them.

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?

The description states a specific verb+resource: 'Build, launch, and locate a native GUI app' and mentions it returns window geometry. This clearly differentiates from sibling tools like glass_stop or glass_screenshot, which operate on an already-launched app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the tool to start a GUI app, but it does not explicitly state when to use it over alternatives or when not to use it. It mentions backend and a11y configuration, but no exclusions or alternative tool references.

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