Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
read_screenA

Read what is on the phone screen as a list of UI elements with ids, text, and tap coordinates. Call this first and after every action to see the result. Element ids are only valid until the next read_screen.

tapA

Tap an element (by id from the last read_screen) or a screen coordinate in pixels.

long_pressA

Press and hold an element (by id from the last read_screen) or a screen coordinate in pixels, for about 0.7 s. Use it for what apps put behind a long press: a message's or item's menu (reply, copy, delete, react), selecting items or text, moving icons. Use tap for normal taps. Returns "Long-pressed" and where; call read_screen to see the menu or selection it opened.

type_textA

Type into the focused text field (or the given element). Replaces its content unless append is true. Set submit to press the keyboard's enter/send action afterwards.

scrollA

Scroll a list or page by about a third of its height or width, to reach content that isn't on screen yet: 'down' shows what's further down (like reading on), 'up' goes back, 'left'/'right' for carousels and tabs. Without element it scrolls the middle of the screen; give the id of a scrollable element (marked scroll in read_screen) to scroll just that list. Returns "Scrolled"; call read_screen to see what came into view. For a precise drag, use swipe.

swipeA

Drag a finger in a straight line from (x1, y1) to (x2, y2), in screen pixels. Use it for gestures scroll doesn't cover: moving a slider, swiping a card or a message aside, pulling down to refresh, dragging on a map. A very short swipe counts as a tap. Returns "Swiped"; call read_screen to see the result.

pressA

Press one of Android's system buttons: back (leave the current screen or close a dialog or the keyboard), home (go to the home screen), recents (the recent apps list), notifications (pull down the notification shade), quick_settings (open Quick Settings). To switch apps, open_app is faster than home and recents. Returns "Pressed" or "Could not press".

open_appA

Open an installed app by its name (e.g. 'Messenger') or package name.

list_appsA

List launchable apps with their package names.

open_urlA

Open a link on the phone the way tapping it would: https:// pages open in the user's browser or in the app that handles them (a YouTube link in YouTube), and deep links open their app (mailto: an email draft, tel: the dialer with the number, geo: or a maps link a map, market:// the Play Store). Nothing is sent or called by opening a link. For public web pages you only need to read, the browser_* tools work without taking over the screen. Returns "Opened"; call read_screen to see it.

screenshotA

Take a screenshot (JPEG). Use only when read_screen is not enough (images, games, canvas UIs). The reply says how to convert image coordinates to screen pixels.

waitA

Wait for the UI to settle, up to 10000 ms.

confirmA

Ask the user to approve an action in the Buddy bubble and wait for the answer. REQUIRED before sending messages, posting, buying, deleting, or changing settings. Show the exact text or action. Returns APPROVED, DENIED, or CHANGES REQUESTED with what the user wants changed: then make those changes and call confirm again.

askA

Ask the user a question in the Buddy bubble and wait for the answer: 2 to 4 answer buttons, and the user can always type their own answer instead. Use it when you need the user to choose or decide (which reply, which item, which time) instead of guessing. With highlight, it also hands a step over to the user (a password or code, their details in a form, a file picker, a captcha): e.g. "Type your password, then tap Done" with options ["Done", "I can't"] and the field in highlight. Returns ANSWER with the option picked, ANSWER (typed) with the user's own words, or NO ANSWER. It is not an approval: still call confirm before anything outward-facing.

point_outA

Show the user where to look or what to do on the screen: a box, circle or arrow with a short label around up to 6 elements, drawn over the app without blocking their touches. When the user does what a mark points at (taps that button, flips that switch, fills in that field and moves on), it turns green and goes. With wait=true the call returns only then (DONE: what they did) or when they don't (GONE, LEFT, NOT DONE): use it to guide the user step by step through something they want to learn to do themselves, one step per call, instead of doing it for them. Marks follow their element as the screen scrolls, and go when it's gone, when the app changes, when you use another phone action, or after seconds. Call with no marks to remove them.

notifyA

Show a short status line in the Buddy bubble without stopping.

reply_notificationA

Answer the notification that started this chat through its own reply field, without opening the app. Only in chats started by one of the user's notification rules, when the notification has a reply field. Buddy shows the user an approval card with the text first, unless you called confirm with it just before.

install_apkA

(Needs Linux tools) Open Android's installer for an APK built in Buddy's Linux, e.g. /root/.buddy/work/myapp/build/app.apk, or served by another app on this phone at a local URL (http://127.0.0.1:/app.apk, e.g. from Termux). The user taps Install/Update themselves; call wait_for_install next.

update_buddyA

Check whether a newer Buddy is out (the official GitHub release) and what's new; with install=true, download it and open Android's installer. Use it when the user asks to update Buddy or whether there's a new version. Only the user can tap Update.

wait_for_installA

After opening the Android installer for an APK, wait until the user has tapped Install/Update and confirmed. Returns as soon as the package is installed (at least min_version_code if given), or early if the installer is no longer on screen, or after the timeout. Use this instead of shell polling loops.

browser_openA

Open a web page in Buddy's background browser (a separate browser the user can watch in this chat; it doesn't use the phone's screen). Returns the page as text, like browser_read.

browser_readA

Read the whole page in the background browser as text. Items you can use are numbered, e.g. [12] button "Add to cart"; the numbers stay valid until the page changes. Long pages come in parts: pass from to read on.

browser_clickA

Tap an item on the page by its number from browser_read (a link, button, checkbox, …).

browser_typeA

Type into a text field by its number from browser_read (replaces its text unless append is true), or pick an option of a select by its text. Set submit to press Enter afterwards.

browser_scrollA

Scroll the page in the background browser (loads more on endless pages).

browser_screenshotA

A picture of what the background browser shows, for images, maps or layouts browser_read can't describe.

browser_backA

Go back to the previous page in the current tab of the background browser, like a browser's back button. If the page warns that leaving loses unsaved changes, Buddy stays the first time and says so. Returns where the tab is now, or that there's no previous page; then call browser_read.

browser_tabsA

Manage the background browser's tabs (this chat's own): with no arguments, list them as numbered lines with title and address, the current one marked; with switch_to, make that tab current (the browser_* tools act on the current tab); with close, close it. Tabs open with browser_open new_tab or when a page opens a link in a new tab.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 28 tools

Disambiguation4/5

Most tools are clearly scoped: phone UI actions, background-browser actions, app launching, and user interaction are distinct. The main ambiguity is between parallel phone and browser tools (tap vs browser_click, type_text vs browser_type, scroll vs browser_scroll, screenshot vs browser_screenshot), though descriptions clarify which surface each acts on.

Naming Consistency4/5

The set uses snake_case throughout and a predictable browser_* prefix for background-browser operations. There are minor deviations such as noun-like names (screenshot, browser_tabs, browser_screenshot) among mostly verb-based names, but the pattern remains readable.

Tool Count3/5

At 28 tools this is heavy, but the domain is broad: phone screen automation, background browser control, app launching, approvals, notifications, and installs. Many tools earn their place, yet the parallel phone/browser surfaces suggest some consolidation could reduce surface area.

Completeness4/5

The surface covers core Android interaction, browser control, app launching, user confirmation, and install/update flows well. Some gaps remain, such as clipboard access, richer notification listing/management, and app uninstall/force-stop operations, but agents can work around most of these.

Maintenance

ActivityMaintained
ResponsivenessResponsive