Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ANDROID_SERIALYesThe serial of the Android device to control, as shown by `adb devices`.
TYPESAFE_AI_APIYesYour TypeSafe API key.

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
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
device_doB

One tool for any single real phone action. Jev first picks which ONE atomic kind this goal wants -- open an app, tap, long-press, type, swipe, scroll-to-find, press a key, toggle a service, set DND, take a screenshot, or read a system service (the same ACTION_KINDS the CLI toolkit uses) -- then runs exactly that one real action and returns its result. include_screenshot=True also attaches a real screenshot of the resulting screen -- off by default since an image costs real context; ask for one at a checkpoint, not after every single step in a sequence. Never plans or chains more than one action; sequencing multiple goals is still the calling agent's job.

device_screenshotA

Take a screenshot of the current screen and return the actual image -- never gated (read-only), no goal needed, no candidates to narrow.

device_approveA

Resolve a pending action from any device_* tool. decision is "approve" or "deny". An optional command overrides the proposed command (e.g. a human-corrected variant), matching PLAN.md's device_approve(thread_id, decision, command?) signature. include_screenshot=True attaches a real screenshot, same off-by-default tradeoff as device_do.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: device_do executes atomic actions, device_screenshot captures the screen, and device_approve resolves pending approvals. No overlap or ambiguity between them, even though device_do covers many sub-actions internally.

Naming Consistency4/5

All tools share the 'device_' prefix, creating a clear namespace. However, the verb part is inconsistent: 'do' is vague, 'screenshot' is a noun-as-verb, and 'approve' is a verb. The pattern is recognizable but not perfectly uniform.

Tool Count4/5

Three tools is on the thin side for a device control server, but the design intentionally consolidates all atomic actions into device_do, making the count reasonable. Each tool has a distinct role and earns its place.

Completeness4/5

The surface covers core device interactions (actions, screenshots, approval resolution) without obvious dead ends. Minor gaps exist, such as no explicit listing of available action kinds or device status, but these are workable given the CLI-toolkit reference.

Maintenance

ActivityMaintained
ResponsivenessNo issues